Производительность при объединении определенных стилей страницы И глобального стиля на одной странице

Моя главная цель — загрузить несколько страниц как можно быстрее. Для этого я хочу воспользоваться как кешем, так и одной «специальной техникой», которая в качестве запасного варианта опирается на стандартный кеш.

Структура

На бэкэнде у меня есть следующая структура. В public_html есть главная страница и несколько подстраниц, каждая из которых имеет определенные правила css, отличающиеся друг от друга. Создание всех свернутых файлов выполняется с помощью скрипта, так что особой сложности здесь нет. Для простоты предположим, что это структура, хотя она и сложнее:

/public_html
  /index.php
  /style.css    ~50kb
  /min.css      ~100kb
  /subjects
    /index.php
    /style.css      ~20kb
    /min.css        ~10kb
  /books
    /index.php  
    /style.css      ~20kb
    /min.css        ~10kb
  ...

Первый запрос

Итак, когда пользователь впервые заходит на подстраницу, он получит этот html-код:

<!DOCTYPE html>
<html>
  <head>
    <link href="/subjects/min.css" rel="stylesheet" type="text/css">
  </head>
  <body>
    All the body here
    <link href="/min.css" rel="stylesheet" type="text/css">
  </body>

Как видите, пользователь загружает весь CSS-код, необходимый для этой страницы, в шапку в небольшом файле. Обратите внимание, что /subjects/min.css НАМНОГО меньше, чем /min.css, что ускорит загрузку первого запроса. Затем, после полной загрузки html и css, начнется загрузка /min.css. Этот файл содержит все стили подстраниц.

Обратите внимание, что уместно поместить <link> в тег <body>, и даже если это не сработает, проблем нет, поскольку стиль страницы уже загружен. Почему я загружаю это здесь? Продолжай читать:

Следующие запросы

Для второго и последующих запросов в этом сеансе пользователь получит этот HTML-код:

<!DOCTYPE html>
<html>
  <head>
    <link href="/min.css" rel="stylesheet" type="text/css">
  </head>
  <body>
    All the body here
  </body>

/min.css уже должен быть кэширован с первого запроса. Однако, если по какой-либо причине это не так, теперь будет загружаться полностью свернутый стиль, как на любом обычном веб-сайте. Это будет запасной вариант.

Это действующая схема? Почему я не видел ничего подобного раньше? Содержит ли это какую-либо логическую ошибку?

Вот основные проблемы, которые я вижу, недостаточно сильные по сравнению с преимуществами:

  • Это добавляет дополнительную сложность коду.
  • Дополнительный запрос после того, как все уже загружено, необходимо сделать. Это добавит небольшую нагрузку на сервер, однако это статический файл.

Примечания к комментариям:

  1. Браузер будет делать меньше запросов. Это правда, таким образом браузер делает один дополнительный запрос. Однако это после загрузки html и css, так что это не сильно повлияет на html.

  2. Кэш. Да, я делаю все возможное, чтобы поймать файл. Однако можно было бы возразить против кеша <link>, если он находится внутри <body>, потому что я не знаю, ведет ли он себя по-другому в отношении кеша, я только предположил, что да в вопросе.


person Francisco Presencia    schedule 12.02.2014    source источник
comment
Если вы загрузите целый минимизированный файл css/js с длительным сроком действия, следующий запрос загрузит этот файл, и вам не нужно перезагружать минимальные части css.   -  person markcial    schedule 15.02.2014
comment
на самом деле есть два ключевых аспекта этого вопроса, которые в основном делают его недействительным. Первый — это кеширование, вы не будете отправлять полные файлы css по каждому запросу, а второй — профилирование. Я предполагаю, что ваше решение не является более производительным ни для клиента, ни для сервера. Получите себе приличный веб-профилировщик и измеряйте время, вместо того, чтобы полагаться на опыт случайных незнакомцев на сайте QA :)   -  person Andreas Grapentin    schedule 15.02.2014
comment
@AndreasGrapentin Да, я бы отправлял полный файл CSS по каждому запросу, в теле первого запроса и в заголовке последовательных запросов. Пожалуйста, прочитайте весь вопрос. Можете ли вы тогда назвать профилировщик, который подойдет для этой конкретной ситуации? Тот, который принимает файлы cookie сеанса и отправляет их в основном.   -  person Francisco Presencia    schedule 15.02.2014
comment
@markcial Я уже знаю это, я просто хочу, чтобы загрузка была быстрее, чем загрузка полностью свернутого файла css/js.   -  person Francisco Presencia    schedule 15.02.2014
comment
полностью свернутый файл, если настроены заголовки кеша, будет обслуживаться только один раз до истечения срока его действия, поэтому технически вы будете обслуживать файл только один раз за время его жизни.   -  person markcial    schedule 15.02.2014
comment
1. использование тега ссылки в теге body может не работать для более старых браузеров, это недействительно в HTML4, но нормально в HTML5, для кросс-браузерной поддержки это будет иметь проблемы 2. css подстраницы необходимо изменить при изменении основного css, затем для обслуживания , обновление основного css требует обновления всех подстраниц css, для большого количества страниц это будет болезненно   -  person Chris Lam    schedule 15.02.2014
comment
Не соглашусь по поводу льгот. Обслуживание кода может быть проблемой при таком подходе, потому что он не очень стандартный. Это своего рода излишество для других членов команды (если таковые имеются). Также это может принести некоторую полезную информацию зачем ставить таблицы стилей в голову. Я бы предложил просто использовать правильные заголовки кэша HTTP для достижения наилучшей производительности.   -  person arty    schedule 15.02.2014
comment
@ChrisLam Я перефразировал вопрос. Для 1 это уже предусмотрено даже для кросс-браузера, оно просто загрузится, как и любая обычная страница. Насчет 2 это делается автоматически с помощью небольшого скрипта.   -  person Francisco Presencia    schedule 16.02.2014
comment
@arty style.css будет таким же, разделенным на части. Пожалуйста, прочтите перефразированный вопрос, чтобы понять, почему я помещаю некоторые элементы стиля в конце тела.   -  person Francisco Presencia    schedule 16.02.2014
comment
@FranciscoPresencia Итак, до сих пор вы выполняли некоторое профилирование в этом подходе, подобное, о чем я думал раньше, я думаю, что основной причиной, по которой вы это делаете, может быть более быстрая загрузка css для разблокировки рендеринга html, однако css разрешено одновременно загружать, и обычно размер JavaScript намного меньше, поэтому я просто думаю, стоит ли это делать. Может быть позже я попробую сделать профилирование самостоятельно   -  person Chris Lam    schedule 16.02.2014


Ответы (4)


Да, то, что вы делаете, совершенно правильно и общепринято

CSS, возможно, плохой пример, но принцип тот же (кстати, загрузить последний через ajax)

Например, изображения.

Мы находимся на странице 1 нашего веб-сайта, и мы знаем, что в 99,999% случаев наши посетители будут переходить на страницу 2, и мы знаем, что на странице 2 у нас есть несколько больших изображений для показа, да, тогда мы можем загрузить их автоматически ПОСЛЕ страница 1 загружена - готовится, тогда сайт «чувствует» себя быстро, когда они перемещаются. Распространенный прием в мобильных веб-приложениях/сайтах/

Так что да:

Это тот же принцип для ЛЮБОГО типа файла, который вы можете захотеть «предварительно кэшировать» для последующих запросов.

  • Загрузите страницу
  • пока посетитель «читает» загруженную страницу, предварительно извлеките файлы/данные, которые, как вы ожидаете, они могут запросить в следующий раз. (изображения, страница 2 данных результатов, javascript и css). Они загружаются через ajax, чтобы не задерживать срабатывание события загрузки страницы — ключевое отличие от вашего примера

Однако, для достижения вашей цели разрешить загрузку страниц как можно быстрее

Выполнение этого или любого другого метода «упреждающей загрузки» минимально для «скорости доставки», если мы не обслуживаем статические файлы со статического сервера, домена без файлов cookie и, в конечном счете, из сети доставки контента.


Достижение цели, заключающейся в том, чтобы обеспечить максимально быструю загрузку страниц, заключается в том, чтобы статические файлы отображались иначе, чем ваш динамический контент (рендеринг php и т. д.).

1) Создайте субдомен для этих ресурсов (css, js, images/media) — static.yourdomain.com

2) Отключите файлы cookie, заголовки и настройте заголовки кеша специально для этого поддомена.

3) Рассмотрите возможность использования такой службы, как http://cdnify.com/ или www. .akamai.com.

Это шаги производительности и скорости для обслуживания статического контента. (надеюсь, не сосать яйца, просто напрямую связан с вопросом, и если кто-то не знаком с этим)

Методы упреждающей загрузки по-прежнему хороши, но они теперь больше связаны с предварительной загрузкой данных для удобства использования, чем для скорости.


Изменить/обновить:

Чтобы уточнить «скорость» и «скорость использования».

  • Скорость часто оценивается программным обеспечением, например, когда срабатывает событие «загрузка» страницы (поэтому важно загружать эти «упреждающие ресурсы» через ajax.

  • Воспринимаемая скорость (удобство использования) – это скорость, с которой пользователь может видеть контент и взаимодействовать с ним (даже если событие загрузки страницы может не сработать).


Изменить/обновить

В нескольких местах поста и в комментариях упоминалась загрузка этих дополнительных «упреждающих» ресурсов через javascript/ajax.

Причина в том, чтобы не задерживать срабатывание события загрузки страницы.

Многие инструменты тестирования скорости веб-сайта (yslow, google .. ) используют это событие «загрузка» для оценки скорости страницы.

Здесь мы задерживаем событие загрузки страницы.

<body>

... page content 

<link rel="stylesheet" href="/nextpage.css"  />
</body>

Здесь мы загружаем через javascript/в некоторых случаях Ajax (данные страницы) и не предотвращаем событие загрузки страницы

<body>
.. page content

  <script>

    window.onload = function () {

       var style   = document.createElement( 'link' );
       style.rel   = 'stylesheet';
       style.type  = 'text/css';
       style.href  = '/nextpage.css';
       document.getElementsByTagName( 'head' )[0].appendChild( style );

   };

   </script>

(это, в качестве бонуса, также решает проблемы совместимости с наличием тега <link> внутри <body>, как обсуждалось в других ваших темах)

person Rob Sedgwick    schedule 16.02.2014
comment
Как они больше связаны с удобством использования, чем со скоростью? В противном случае, можете ли вы привести пример, где используется техника упреждающей загрузки? Это похоже на то, что я делаю на моем личном веб-сайте francisco.io. Загружается главная страница, а описание каждого проекта загружается в фоновом режиме, поэтому при нажатии на любой проект описание уже загружается, но главная страница не занимает так много времени, как если бы загружалась сразу [примечание он находится в разработке, и многие описания все еще пусты]. - person Francisco Presencia; 16.02.2014
comment
Наиболее распространенным в отношении скорости будет «страница 2 результатов». Мы ищем и получаем страницу 1 или результаты, а в фоновом режиме мы «упреждающе загружаем страницу 2» — я думаю, удобство использования тесно связано со скоростью. Я хочу сказать, что то, что вы делаете, нормально/обычно, но с помощью статического домена можно добиться большей экономии скорости. - person Rob Sedgwick; 16.02.2014
comment
Другой пример техники упреждающей загрузки — та часть, где я говорю об изображениях. То, что вы делаете с CSS, — это «техника упреждающей загрузки». - person Rob Sedgwick; 16.02.2014
comment
Хорошо, моя идея состоит в том, чтобы сделать это поверх лучших практик, уже существующих, таких как cdn, за исключением случаев, когда они прямо не согласны (например, загружать все заранее). Тем не менее, какой-либо источник для превентивной загрузки изображений? Все, я я нахожу действительно старым. - person Francisco Presencia; 16.02.2014
comment
Если вы посмотрите на информацию о скорости страницы Google, она рекомендует встроить CSS (единственный CSS, который вам нужен для этой страницы) — это форма того, что вы делаете. А затем «предварительно загрузить» позже (опять же через ajax), это хорошо. - person Rob Sedgwick; 16.02.2014
comment
Я нашел этот вопрос, который предлагает то же, что и вы. У меня только один вопрос, почему вы загружаете его через ajax, а не в конце тела html в моем случае? Обратите внимание, что основные правила min.css не должны конфликтовать с правилами конкретной подстраницы. - person Francisco Presencia; 16.02.2014
comment
Привет, Франциско, если мы не загрузим их через ajax, мы задержим срабатывание события загрузки страницы. Это остановит сообщение «готово» в строке состояния и уменьшит «скорость загрузки страницы» с сайтов тестирования скорости (yslow, google и т. д.). - person Rob Sedgwick; 16.02.2014
comment
Здесь приведен пример предварительной выборки ресурсов через ajax без задержки события загрузки страницы — phpied.com/preload-cssjavascript-без-выполнения - person Rob Sedgwick; 16.02.2014
comment
Это было в ссылке, которую я разместил: P Если бы вы могли добавить соответствующие фрагменты комментариев к своему основному ответу, я приму это. - person Francisco Presencia; 16.02.2014
comment
@RobSedgwick Ну, вы объясняете многие вещи, которые совершенно правильны в вашем ответе. И, как вы сами упомянули, все это может относиться к файлам изображений и Javascript, но уж точно не к файлам CSS!. И имхо тоже есть несколько вопросов...! Вы никогда не узнаете, на какую «следующую страницу» перейдет посетитель! Таким образом, высока вероятность того, что вы создаете ненужный трафик, который не понравится пользователям с тарифным планом. Кроме того, загрузка файла CSS в зависимости от JS, по крайней мере, далека от идеала. - person Netsurfer; 16.02.2014
comment
Конечно, @Netsurfer, я чувствовал, что вопрос был более риторическим о предварительной загрузке любого статического ресурса, согласитесь, что CSS, являющийся одним из этих ресурсов, является «плохим примером» - файлы CSS обычно имеют небольшой размер в размере, как упоминается в вашем замечательном ответе. - person Rob Sedgwick; 16.02.2014
comment
Что касается «никогда не разделять файлы CSS», то это зависит от выполняемой работы. Для более крупных веб-приложений обычно используются файлы CSS, которые не связаны между собой, но мы все же можем предпочесть «предварительную выборку». Наиболее распространенной является упрощенная страница входа. (см. сообщение o.v). Использование времени, которое пользователь тратит на «вход в систему», загружая материал в фоновом режиме для основного приложения. это приятное прикосновение. - person Rob Sedgwick; 23.02.2014

ОБНОВЛЕНИЕ:

Обратите внимание, что ответ, который автор вопроса пометил как принятый, не может быть рекомендован -
никогда не делайте этого!

Любая «предварительная загрузка» файлов CSS не имеет смысла, поскольку вы никогда не должны разбивать свой CSS на несколько файлов!

Мой оригинальный ответ:

Итак, каков ваш реальный вопрос в конце?

По моему скромному мнению, вы все делаете неправильно - извините!

Обычно автор намеревается

  • придать сайту единообразный внешний вид
  • поддерживать ремонтопригодность как можно проще
  • избегайте FOUC (flash нестилизованного контента)
  • минимизировать количество (HTTP) запросов
  • поддержка механизма кэширования для уменьшения пропускной способности/объема данных

просто упомянем некоторые из наиболее важных аспектов.

Все они игнорируются вашим подходом.

Поскольку вы используете элемент link внутри элемента body, я предполагаю, что вы используете HTML5. Потому что в других версиях HTML это было бы недопустимо.

Но и в HTML5 я бы не стал полагаться на это. Посмотрите на 2 версии:

  1. http://www.w3.org/html/wg/drafts/html/master/document-metadata.html#the-link-element
  2. http://www.w3.org/html/wg/drafts/html/CR/document-metadata.html#the-link-element

Сравните раздел (вверху) «Контексты, в которых этот элемент может использоваться:».

Поскольку информация из CSS больше всего нужна браузеру для отображения страницы, она должна быть загружена одной из первых.

Ознакомьтесь со статьей: "Как работают браузеры: за кулисами современных веб-браузеров" и особенно в разделе: "Двигатели рендеринга" .

Таким образом, загрузка другой таблицы стилей заставит браузер переделать всю работу, помимо дополнительного HTTP-запроса, который, в частности, при соединениях GSM может вызвать «проблемы» из-за большей задержки.

И если каждая страница вашего сайта действительно имеет такое количество индивидуальных стилевых правил, то я бы сказал, что это «ошибка дизайна».

Один из «принципов дизайна» звучит так: «Сколько нужно — как можно меньше!»

Другое (большое) преимущество использования только одной таблицы стилей заключается в том, что она кэшируется браузером после первой загрузки. И поскольку CSS сайта обычно не меняется слишком часто, это большое преимущество, которое намного перевешивает недостаток дополнительных КБ, загружаемых при первом посещении страницы (кстати, независимо от входа / целевой страницы)!

Вывод:
Я действительно не могу рекомендовать использовать ваш подход!

Поместите все ваши стили (нормализовать, базовый, медиа-запросы, печать) в один файл, который вы загружаете через <link> в <head> вашего документа.

Это лучшее, что ты можешь сделать.

person Netsurfer    schedule 15.02.2014
comment
Извините, но я думаю, что в исходном вопросе я неправильно сформулировал многие вещи. Я перефразировал тот же вопрос, чтобы сделать его более понятным. Я думаю, что единственный момент, который я упускаю, это minimize number of (HTTP) requests и, возможно, FOUC, который я пытаюсь полностью понять, как он применим к этому. Хотя я согласен с И если каждая страница вашего сайта действительно имеет такое количество индивидуальных правил стиля, то я бы сказал, что это недостаток дизайна, я думаю, что в данном случае это действительно необходимо. На странице есть /subjects, /books, /slides и т. д., каждый из которых отличается своим стилем. - person Francisco Presencia; 16.02.2014
comment
@FranciscoPresencia И даже после вашего обновления ответ остается прежним. Похоже, вы пытаетесь заново изобрести велосипед...! Нет лучшего и более быстрого способа, чем поместить все ваши стили в один файл. Держите его как можно меньше и убедитесь, что ваш сервер сжимает файл (Content-Encoding:gzip) перед доставкой. Поскольку механизм рендеринга браузера очень быстр по сравнению с передачей данных, разделение вашего CSS на несколько файлов имеет только недостатки! - person Netsurfer; 16.02.2014
comment
Вы делаете утверждение Нет лучшего и более быстрого способа, чем поместить все ваши стили в один файл, тогда как мой вопрос, по сути, является ли моим методом быстрее, чем поместить все стили в один файл? один файл? Я выступаю против того, что обычно делается, поэтому просто сказать, что я не делаю это так, как это обычно делается без причины, стоящей за этим, дает мне мало объяснений. В этом недостаток этих утверждений: минимизировать количество (HTTP) запросов и придать сайту единообразный внешний вид. Это обобщения, которые не применимы к моей цели и вопросу. - person Francisco Presencia; 16.02.2014
comment
@FranciscoPresencia Ваш метод может быть быстрее при первом (когда-либо) посещении вашего сайта! После первой загрузки его точно нет! Я думал, что писал это раньше. А также скорость зависит от очень многих разных обстоятельств, разных для каждого пользователя (например, тип соединения). Таким образом, чем медленнее соединение пользователя, тем медленнее ваш подход. И хотите верьте, хотите нет, но нет более быстрого способа, чем иметь один файл CSS, который доставляется сервером в формате gzip! Все ваши подходы по разбиению файла CSS для уменьшения размера файла не дадут желаемого эффекта...! - person Netsurfer; 16.02.2014
comment
@FranciscoPresencia И ответ, который вы приняли, не изменит эти факты. Обработка файлов CSS таким образом (предварительная загрузка, добавление элемента ссылки в тело с помощью JS и т. д.) сделает ситуацию еще хуже...! Почему бы вам вместо этого не сосредоточиться на оптимизации кода CSS? И обычно файл CSS для большого веб-сайта не будет больше по размеру, чем одно изображение. Так что imho вы пытаетесь оптимизировать не в том месте. - person Netsurfer; 16.02.2014
comment
@FranciscoPresencia А если вы используете кеш приложения HTML5 (что вы, безусловно, сделаете), то вы не улучшите ситуацию, разбив свой CSS на десятки отдельных файлов, так как весь кеш должен быть перезагружен, если один из его ресурсов изменился . - person Netsurfer; 16.02.2014
comment
не вижу как после первой загрузки не будет быстрее, так как основной min.css уже будет в кеше для следующих загрузок... предзагрузка по касательной к оптимизации; они оба могут сосуществовать, и каждый приносит пользу по-разному. Дело в том, что размер CSS меньше, чем изображение, это хорошо и верно, я также сосредоточусь на оптимизации изображений, где только смогу. Также я никогда не слышал о кэше приложений HTML5, я покопаюсь в это потому, что это кажется чрезвычайно полезным. - person Francisco Presencia; 19.02.2014
comment
Хотя я не согласен с вашим основным ответом, комментарии содержат много полезной информации. Жаль, что я не могу разделить награду. - person Francisco Presencia; 19.02.2014
comment
@FranciscoPresencia Когда вы говорите: я не понимаю, как после первой загрузки это не будет быстрее, так как основной min.css уже будет в кеше для следующих загрузок. Это в основном потому, что если у вас есть только один файл CSS, он также уже будет в кеше, и не нужно загружать второй или третий файл CSS. Также помните, что даже если файл кэширован, браузеру необходимо сделать запрос (по крайней мере, для ответа сервера «304 не изменено»). Таким образом, время ответа сервера и / или задержка (в GSM) по-прежнему имеют значение. Кроме того, сжатие GZIP более эффективно для одного большого файла! - person Netsurfer; 19.02.2014
comment
Хорошо, теперь я понимаю, что ты имеешь в виду. Во втором запросе будет только 1 файл. Таким образом, первый запрос будет быстрее, а второй такой же, как и при использовании традиционных методов. Как это недостаток? Про gzip я даже не подумал, хотя вроде это микрооптимизация, такая же, как и предзагрузка. Мне нужно провести несколько тестов для этой части. - person Francisco Presencia; 19.02.2014

Поскольку min.css содержит все правильно свернутые стили, просто используйте это


Почему ?

1.Браузер будет делать меньше запросов

2. Файл будет закэширован после 2-3 извлечений браузером. Значительное сокращение времени загрузки страницы!

3. Браузеру не нужно просматривать css конкретной страницы, что, в свою очередь, уменьшает время, необходимое для отображения страницы.

4.Легкая ремонтопригодность кода. Если вы хотите обновить css, просто добавьте префикс некоторой переменной запроса, чтобы браузер извлекал обновленный css.


Я думаю , вышеперечисленных причин достаточно для того, чтобы вы использовали только min.css

Кроме того, не забудьте установить действительно yyyyy длинную дату истечения срока действия кеша, если вы сделаете то, что я рекомендую.

Редактировать: поскольку ОП не понял пункт 2, я проясню себя и суть.

Браузер не будет кэшировать файл css при первой встрече, потому что он думает: «Эй, давайте не будем кэшировать это сразу. А если изменится? Я прослежу за тем, чтобы один и тот же css перезагружался как минимум 2 раза, чтобы воспользоваться преимуществами кэширования.

Нет смысла кэшировать css при первой загрузке. Потому что, если браузер сделает это, в системе пользователя будет огромное количество кеша. Таким образом, браузеры достаточно умны, чтобы кэшировать часто загружаемые и неизмененные файлы.

person Amit Joki    schedule 15.02.2014
comment
Пожалуйста, прочтите обновленный вопрос, я попытался прояснить его, хотя вопрос остается прежним. Я думаю, он ясно объяснит пункты 1 и 3. Что касается 4, код на бэкенде один и тот же, что бы ни случилось, затем скрипт извлекает его и минимизирует, так что его легко поддерживать. Объясните, пожалуйста, пункт 2? Я не понял предложения, возможно, это связано с тем, что я не владею английским языком, извините. - person Francisco Presencia; 16.02.2014

То, что вы описываете, представляет собой шаблон предварительной выборки/отложенной загрузки с ресурсами, загружаемыми в ожидании того, что они станут актуальными в будущем - например, базовая страница входа в систему с минимальным стилем, которая запускает загрузку css сайта в фоновом режиме.

Это уже делалось раньше, среди прочего, в модуле PageSpeed. На самом деле, это более агрессивно, но требует меньше усилий для разработки! Стандартная целевая страница (например, экран входа), использующая лишь небольшое подмножество стилей, может использовать преимущества prioritize_critical_css, который встраивает соответствующие правила в html и загружает css внизу страницы! В отличие от исходного сценария, когда необходимо выполнить два последовательных запроса, блокирующие рендеринг эффекты не имеющие таблицы стилей в голове смещаются. Это улучшение хорошо воспринимается посетителями, впервые зашедшими на сайт с мобильных устройств, которые подвержены более высокой задержке в сети и меньшему количеству разрешенных одновременных HTTP-запросов.

Естественным развитием этого будет ленивая загрузка спрайтов, веб-шрифтов и другого статического кэшируемого контента. Тем не менее, я склонен предположить, что преимущества хорошо структурированного отдельного css заключаются в следующем: your-problems.html" rel="nofollow">вероятно поверхностный, и вы, как правило, преуспели бы, собрав стили в один файл. Разница во времени загрузки между 5 и 50 килобайтным файлом не десятикратная, она ничтожна, так как сайт производительность больше не зависит от пропускной способности. В качестве примечания: вам никогда не придется беспокоиться об управлении зависимостями (т. е. не забывать включать правила, относящиеся к определенным элементам на вашей странице), что нелегко автоматизировать для html+css и становится довольно сложно для больших проектов.

Если вы сосредоточитесь на основном правиле статических ресурсов — агрессивном кэшировании — и не забудьте снять отпечатки ваших активов, чтобы развертывание не запуталось, у вас все отлично! И если вы обращаетесь к воспринимаемому исполнению с помощью хорошо поставленного пульсатора тут и там...

person Oleg    schedule 19.02.2014