Но я хочу обратить ваше внимание, в частности, на следующий фрагмент:
«...Учтите, что приостановка отображения относится только к тому, должен ли браузер задержать начальное отображение страницы на этом ресурсе. В любом случае CSS-ресурс все равно загружается браузером, пусть даже с меньшим уровнем приоритета для неблокирующих ресурсов».
Следует пояснить, что все привязанные файлы все равно будут загружены, браузер просто не будет сдерживать отображение страницы на экране, если они не подлежат немедленному применению.
Следовательно, современный браузер загружает адаптивную веб-страницу (посмотрите файл каталога example_02-03) с четырьмя разными таблицами стилей, привязанными с помощью различных медиазапросов (для применения разных стилей для различных диапазонов окон просмотра) с загрузкой всех четырех CSS-файлов, но, возможно, с начальным анализом до вывода страницы на экран только одного из них, применимого в сложившихся условиях.
Практические аспекты разделения медиазапросов
Несмотря на то что мы только что узнали о потенциальных преимуществах разделения медиазапросов, ощутимость преимуществ разделения различных стилей в медиазапросах с помещением их в отдельные файлы не всегда достаточно высока (если не брать в расчет персональные предпочтения и/или обособление кода).
В конце концов, использование отдельных файлов повышает количество HTTP-запросов, необходимых для отображения страницы, что, в свою очередь, может сделать страницу медленнее в некоторых других ситуациях. Ничто в Интернете легко не дается! Поэтому возникает вопрос вычисления общей производительности вашего сайта и тестирования каждого сценария на различных устройствах.
Моя исходная позиция по данному вопросу заключается в том, что если проект располагает достаточным временем для оптимизации производительности, то искать возможности прироста производительности именно в этом месте я стану в последнюю очередь. Сначала я захочу убедиться в том, что:
• сжаты все изображения;
• объединены и минимизированы все сценарии;
• средством gzip обработаны все ресурсы;
• все статическое содержимое кэшировано посредством CDN-сетей;
• удалены все избыточные CSS-правила.
Возможно, после этого я приступлю к решению вопроса о разбиении медиазапросов на отдельные файлы с целью повышения производительности.
совет
gzip является файловым форматом сжатия и восстановления. Обработку файлов CSS с существенным уменьшением размера файла при его передаче от сервера к устройству, где он восстанавливается до своего исходного формата, позволяет производить любой высококачественный сервер. Справку по gzip можно найти в «Википедии» по адресу http://en.wikipedia.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/. Суть в том, что я не верю, что вас будет тревожить размер файла, если вы предпочтете записывать медиазапросы непосредственно после стандартных стилей.
совет
Если вам хочется разрабатывать свои медиазапросы непосредственно после исходных правил, но при этом иметь все идентичные определения медиазапросов объединенными в один запрос, то для этого существует несколько рабочих инструментов (на момент написания данной книги соответствующие дополнительные модули были как у Grunt, так и у Gulp).
Метатег viewport
Для получения максимальной отдачи от медиазапросов хотелось бы, чтобы устройства с меньшими размерами экрана отображали веб-страницы в их исходном размере и не выводили их в окне шириной 980 пикселов, для которого вам пришлось бы масштабировать их в ту или иную сторону.
Когда в 2007 году компания Apple выпустила iPhone, она ввела собственный метатег под названием viewport, который теперь поддерживается Android и постоянно растущим количеством других платформ. Предназначением метатега viewport является предоставление веб-страницам способа связи с браузерами мобильных устройств для сообщения им предпочтительного способа вывода страницы на экран.
В обозримом будущем те веб-страницы, которые хотелось бы сделать адаптивными и успешно выводимыми на устройствах с малыми размерами экрана, будут вынуждены использовать этот метатег.
тестирование адаптивного дизайна на эмуляторах и симуляторах
Хотя замены для тестирования результатов разработки на реальных устройствах нет, существует ряд эмуляторов для Android и симуляторов для iOS. Для особо дотошных поясняю, что симулятор просто симулирует нужное устройство, а эмулятор фактически пытается интерпретировать исходный код устройства.
Android-эмулятор для Windows, Linux и Mac находится в свободном доступе для загрузки и установки по адресу http://developer.android.com/sdk/ и применяется в составе программного инструментария разработчика Android Software Development Kit (SDK).
Симулятор для iOS доступен только пользователям Mac OS X и поставляется как часть пакета Xcode, который можно свободно получить в Mac App Store.
У самих браузеров в их средствах разработки также имеются постоянно совершенствуемые инструменты для эмуляции мобильных устройств. Конкретные настройки на эмуляцию различных мобильных устройств и окон просмотра имеются как у Firefox, так и у Chrome.
Метатег viewport добавляется в <head>-теги кода HTML. Он может настраиваться на определенную ширину (которую, к примеру, можно выразить в пикселах) или содержать указание на масштаб, например 2.0 (удваивание текущего размера). Рассмотрим пример использования метатега viewport, настраивающего вывод в браузере в удвоенном по сравнению с исходным размере (200 %):
<meta name="viewport" content="initial-scale=2.0,width=device-width" />
Разобьем предыдущий метатег на части, чтобы понять, что происходит. Атрибут name="viewport" разъяснений не требует. Затем в разделе content="initial-scale=2.0 предписывается увеличить размер содержимого вдвое (значение 0.5 уполовинило бы размер, 3.0 — утроило его и т. д.), а раздел width=device-width говорит браузеру о том, что ширина страницы должна быть равна значению device-width.