Фрэйн . - HTML5 и CSS3. Разработка сайтов для любых браузеров и устройств. 2-е изд.

Привязка различных CSS-файлов с помощью медиазапросов

С точки зрения браузера CSS рассматривается как ресурс, приостанавливающий отображение. Браузеру нужно извлечь и проанализировать привязанные CSS-файлы до полного вывода страницы на экран.

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

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

Подробности по данной теме можно найти на страницах разработчиков компании Google: https://developers.google.com/web/fundamentals/performance/critical-rendering-path/render-blocking-css.

Но я хочу обратить ваше внимание, в частности, на следующий фрагмент:

«...Учтите, что приостановка отображения относится только к тому, должен ли браузер задержать начальное отображение страницы на этом ресурсе. В любом случае CSS-ресурс все равно загружается браузером, пусть даже с меньшим уровнем приоритета для неблокиру­ющих ресурсов».

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

Следовательно, современный браузер загружает адаптивную веб-страницу (посмотрите файл каталога example_02-03) с четырьмя разными таблицами стилей, привязанными с помощью различных медиазапросов (для применения разных стилей для различных диапазонов окон просмотра) с загрузкой всех четырех CSS-файлов, но, возможно, с начальным анализом до вывода страницы на экран только одного из них, применимого в сложившихся условиях.

Практические аспекты разделения медиазапросов

Несмотря на то что мы только что узнали о потенциальных преимуществах разделения медиазапросов, ощутимость преимуществ разделения различных стилей в медиазапросах с помещением их в отдельные файлы не всегда достаточно высока (если не брать в расчет персональные предпочтения и/или обособление кода).

В конце концов, использование отдельных файлов повышает количество HTTP-запросов, необходимых для отображения страницы, что, в свою очередь, может сделать страницу медленнее в некоторых других ситуациях. Ничто в Интернете легко не дается! Поэтому возникает вопрос вычисления общей производительности вашего сайта и тестирования каждого сценария на различных устройствах.

Моя исходная позиция по данному вопросу заключается в том, что если проект располагает достаточным временем для оптимизации производительности, то искать возможности прироста производительности именно в этом месте я стану в последнюю очередь. Сначала я захочу убедиться в том, что:

• сжаты все изображения;

• объединены и минимизированы все сценарии;

• средством gzip обработаны все ресурсы;

• все статическое содержимое кэшировано посредством CDN-сетей;

• удалены все избыточные CSS-правила.

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

совет

gzip является файловым форматом сжатия и восстановления. Обработку файлов CSS с существенным уменьшением размера файла при его передаче от сервера к устройству, где он восстанавливается до своего исходного формата, позволяет производить любой высококачественный сервер. Справку по gzip можно найти в «Википедии» по адресу http://en.wikipe­dia.org/wiki/Gzip.

Вложение медиазапросов путем их встраивания

При любых обстоятельствах, кроме самых крайних, я рекомендую добавлять медиазапросы в существующие таблицы стилей наряду с обычными правилами.

Если вам удается придерживаться этой рекомендации, возникает следующий вопрос: должны ли медиазапросы объявляться ниже связанного с ними селектора? Или же они должны разбиваться в конце на отдельные блоки кода для всех одинаковых медиазапросов? Если у вас возник такой вопрос, я этому весьма рад.

Как поступать — объединять медиазапросы или же записывать их там, где они пригодятся?

Я сторонник записи медиазапросов ниже исходных обычных определений. Если, к примеру, мне нужно изменить ширину двух элементов в разных местах таблицы стилей в зависимости от ширины окна просмотра, я делаю следующее:

.thing {

width: 50%;

}

@media screen and (min-width: 30rem) {

.thing {

width: 75%;

}

}

/* Здесь между рассматриваемыми фрагментами кода помещаются другие стили */

.thing2 {

width: 65%;

}

@media screen and (min-width: 30rem) {

.thing2 {

width: 75%;

}

}

Поначалу все это выглядит весьма странно. У нас есть два медиазапроса, и оба они имеют отношение к экранам с минимальной шириной 30 rem. Неужели повторение @media-объявления не считается многословием и расточительством? Наверное, мне следовало бы сгруппировать все идентичные медиазапросы в единый блок:

.thing {

width: 50%;

}

.thing2 {

width: 65%;

}

@media screen and (min-width: 30rem) {

.thing {

width: 75%;

}

.thing2 {

width: 75%;

}

}

Безусловно, это один из способов такой группировки. Но с точки зрения сопровождения кода он представляется мне более сложным. Правильного способа не существует, но я предпочитаю сначала определить одно правило для отдельного селектора и располагать определения любых изменений этого правила (например, изменения внутри медиазапросов) непосредственно после него. При этом мне не придется искать отдельные блоки кода, чтобы найти объявление, относящееся к конкретному селектору.

примечание

Еще более удобным может стать использование препроцессоров и постпроцессоров CSS, поскольку вариант правила, заключенный в медиазапрос, может быть вложен непосредственно в набор правил. В моей книге Sass and Compass for Designers этой теме посвящен целый раздел.

Казалось бы, вполне резонно выступить против вышеупомянутой технологии по причине ее многословия. Неужели один лишь размер файла может стать достаточной причиной для того, чтобы не записывать медиазапросы таким образом? В конце концов, никому не хочется иметь раздутый CSS-файл для обслуживания своих потребностей. Но нужно считаться с тем простым фактом, что gzip-сжатие, которому должны подвергаться все возможные ресурсы на вашем сервере, сокращает разницу до совершенно ничтожных величин. Ранее я провел соответствующие тесты, и если у вас появилось желание получить дополнительные сведения, можете обратиться по адресу http://benfrain.com/inline-or-combined-media-queries-in-sass-fight/. Суть в том, что я не верю, что вас будет тревожить размер файла, если вы предпочтете записывать медиазапросы непосредственно после стандартных стилей.