Как заставить адаптивные веб-сайты работать
Было время, когда вы могли уверенно отличить веб-страницу для настольных компьютеров от веб-страницы для мобильных устройств. На самом деле, настолько, что целая индустрия выросла вокруг перепрофилирования настольных сайтов для мобильных устройств.
Какое-то время вы были никем, если у вас не было отдельного мобильного сайта на отдельном домене. Затем все начало меняться.
Мобильные дисплеи улучшились до неузнаваемости. Мобильные браузеры тоже. Таблетки добавили еще один элемент в уравнение. Появился 4G. Дисплеи Retina предложили конечным пользователям новый уровень четкости.
Внезапно грань между десктопом и мобильным устройством стала размытой.
В то же время росло разнообразие размеров и разрешений настольных дисплеев.
И растущая головная боль для веб-дизайнеров.
Прошли те времена, когда вам нужно было обслуживать только несколько размеров окна просмотра. Все усложнялось.
К счастью, помощь была под рукой в виде медиа-запросов и концепции адаптивного дизайна.
Благодаря медиа-запросам стало возможным варьировать стили и макет — даже контент — в зависимости от ширины окна просмотра и разрешения экрана пользователя. Конечно, медиа-запросы ни в коем случае не являются единственным инструментом в наборе приемов адаптивного дизайнера, но справедливо сказать, что они составляют основу техники.
Это была отличная новость для мобильных устройств. Адаптивный дизайн означал, что вы могли эффективно показывать разные версии одного и того же сайта на разных устройствах. И все это без разработки отдельного мобильного сайта на другом домене.
Что насчет производительности?
Владельцы сайтов начинают понимать, что конечные пользователи заботятся о производительности. Ритейлеры, в частности, начинают осознавать, что сокращение времени загрузки на миллисекунды может превратиться в миллионы на балансе.
К счастью, адаптивные сайты предлагают одно явное преимущество в производительности по сравнению со своими специализированными мобильными собратьями: перенаправление на мобильный домен исключено.
Однако, несмотря на это, адаптивный дизайн умудрился завоевать репутацию из-за низкой производительности.
В некотором смысле это довольно несправедливо, но стоит обратить внимание на дополнительные проблемы с производительностью, которые адаптивный дизайн вызывает у неосторожных…
Картинки
Файлы изображений большие. И поскольку они большие, они часто виноваты в медленном времени загрузки. Поэтому они являются хорошей отправной точкой для тех, кто пытается оптимизировать производительность сайта.
К сожалению, одно из первых решений для быстрой доставки изображений не отличалось высокой производительностью.
Техника прекрасно проста. Просто используйте max-width: 100%, чтобы убедиться, что изображения масштабируются по ширине содержащего элемента:
img
{
max-width: 100%;
}По мере того, как контейнер сжимается, чтобы соответствовать меньшим окнам просмотра, любые изображения внутри будут уменьшаться вместе с ним. Легкий!
Но есть проблема. Размер изображения на экране может уменьшиться, но размер файла останется прежним. Это далеко не идеально с точки зрения производительности. Вы можете посылать по сети изображение размером 800 x 800 пикселей только для того, чтобы оно отображалось с разрешением 80 x 80 пикселей: другими словами, вы можете передавать сотни (или тысячи) ненужных байтов. Мало того, что загрузка изображения займет много времени, все эти избыточные байты могут истощить ценные данные конечного пользователя.
Однако это не единственный и даже не лучший способ доставки адаптивных изображений. Во-первых, изображение, которое работает с шириной 800 пикселей, не обязательно будет так же хорошо работать с различными частями этого размера.
Чтобы справиться с этим, вы можете использовать медиа-запрос для отображения разных версий изображения в зависимости от размера области просмотра с помощью медиа-запроса и display: none.
CSS:
@media (min-width: 601px) {
#croppedImage
{
display:none;
}
}
@media (max-width: 600px) {
#largeImage
{
display:none;
}
}HTML:
<img id="largeImage" width="400" height="400" alt="" src="images/largeImage.webp">
<img id="croppedImage" width="200" height="200" alt="" src="images/croppedImage.webp">Это позволяет отображать разные версии изображения, а не одно и то же изображение разных размеров. Однако это не сокращает количество байтов. На самом деле общий размер страницы будет больше, поскольку будут загружены все изображения, независимо от того, отображаются они или нет.
Лучшая альтернатива — если это практично — использовать фоновые изображения <divs>вместо <img>элементов. Это предпочтительнее, потому что изображения, на которые есть ссылки в CSS, загружаются только в том случае, если они используются (если они не являются URI данных):
@media (min-width: 601px) {
#largeImage
{
width:400px;
height:400px;
background-image:url(/images/largeImage.webp);
}
#croppedImage
{
display:none;
}
}
@media (max-width: 600px) {
#croppedImage
{
width:200px;
height:200px;
background-image:url(/images/croppedImage.webp);
}
#largeImage
{
display:none;
}
}Это хорошо работает: посетители загружают только те изображения, которые им нужны, и тогда, когда они им нужны. Проблема в том, что он неаккуратный, эффективно рассматривая контент как стиль. Таким образом, это потенциально создает проблемы с ремонтопригодностью, а также может привести к тому, что важные изображения будут игнорироваться поисковыми системами.
Вместо этого, почему бы не использовать SVG (масштабируемая векторная графика): формат изображения, который масштабируется по самой своей природе? Преимущество изображений SVG также в том, что они легко стилизуются с помощью CSS (см. этот отличный учебник о том, как сделать SVG отзывчивыми с помощью CSS). Это идеально подходит для значков и логотипов, но, к сожалению, вы не сможете использовать SVG для фотографий — для них вам придется прибегнуть к растровым форматам, таким как JPEG.
Другой вариант — использовать одно из нескольких решений JavaScript для доставки адаптивных изображений. Это популярный способ сделать это, но он добавляет еще один уровень сложности. Более того, поскольку JavaScript блокирует построение DOM, любое решение, использующее JavaScript, может задержать рендеринг. Так что, несмотря на то, что есть несколько очень умных плагинов, просто введя JavaScript в уравнение, вы в какой-то степени смиритесь с меньшим из двух зол.
До недавнего времени это были единственные варианты.
Теперь, однако, элементы <picture>and <source>, а также атрибуты srcset и size наконец-то приносят в сеть по-настоящему адаптивные изображения. Новая спецификация также начинает получать поддержку браузеров с полной поддержкой в Chrome и Opera и поддержкой переключения разрешения в Safari. Пока другие браузеры не догонят, есть отличный JavaScript -полифилл.
В этом дивном новом мире вы можете использовать srcset для составления списка изображений-кандидатов, из которых браузер может выбирать. Затем вы можете использовать медиа-запрос в атрибуте размеров, чтобы указать размер, в котором будет отображаться изображение. Используя <picture>элемент вместе с медиа-запросами внутри одного или нескольких элементов, вы можете указать разные диапазоны изображений для разных условий (например, для областей просмотра до определенной ширины используйте изображение a, b или c, а для больших областей просмотра используйте изображение х, у или г). Это полезно, если вам нужно предоставить обрезанную версию изображения для пользователей с маленькими экранами.
Подробное описание того, как использовать новый синтаксис, выходит за рамки этой статьи, но вы можете найти отличное руководство на alistapart.
Возможно, единственным недостатком этой новой спецификации является то, что она довольно многословна, что может означать раздувание HTML на страницах с большим количеством изображений. Однако преимущества значительно перевешивают недостатки.
Загрузка CSS, который вам (обязательно) не нужен
Хотя медиа-запросы позволяют применять различные правила CSS в зависимости от установленных вами критериев, никуда не деться от того факта, что конечным пользователям придется загружать все применимые CSS-стили. Это верно, даже если вы поместите свой CSS в отдельные файлы и поместите свой медиа-запрос в <link>элемент.
Например, будут загружены обе следующие таблицы стилей, независимо от ширины области просмотра:
<link rel="stylesheet" media="(max-width: 600px)" href="css/style1.css">
<link rel="stylesheet" media="(min-width: 601px)" href="css/style2.css">Это не ошибка браузера. Критерии, используемые в медиа-запросах, часто относятся к вещам, которые меняются во время посещения страницы. Например, посетитель может решить изменить размер окна браузера или повернуть свой планшет/мобильное устройство. Результирующее изменение отображения должно быть плавным, и запуск запроса на другой файл CSS был бы далек от идеала. Это особенно актуально для мобильных устройств, которые стараются закрыть радиосвязь при первой же возможности, чтобы сохранить заряд батареи. Потенциально необходимость переустанавливать эту связь при изменении размера области просмотра может плохо сказаться на времени автономной работы.
Тем не менее, Chrome старается разумно обрабатывать эти разные файлы. Хотя все файлы будут загружены, только тот, у которого в данный момент есть соответствующий медиа-запрос, заблокирует рендеринг. Любые другие будут загружаться с более низким приоритетом.
К сожалению, другие браузеры не так любезны. В Firefox, например, неиспользуемые файлы CSS не только блокируют рендеринг — они также блокируют загрузку других объектов на странице.
Диаграмма водопада ниже иллюстрирует этот момент. Изображения на этой странице не начинают загружаться до тех пор, пока неиспользуемый файл CSS не будет загружен полностью:
Вы можете обойти это, используя JavaScript для условной загрузки CSS, но, как мы уже видели, JavaScript имеет свои собственные издержки производительности.
Что все это значит для производительности адаптивного сайта по сравнению с мобильным сайтом?
Ну, мобильные пользователи и пользователи настольных компьютеров на адаптивном сайте должны будут загрузить один и тот же CSS.
И их будет больше, чем на сайте, предназначенном только для настольных компьютеров или мобильных устройств.
Более того, специализированный мобильный сайт, скорее всего, будет использовать более легкую, урезанную версию CSS для настольных компьютеров (хотя сейчас это, возможно, менее верно, поскольку пользователи ожидают более богатого опыта на все более сложных мобильных дисплеях).
Таким образом, при прочих равных, похоже, что есть что-то в аргументе, что адаптивный сайт, вероятно, будет медленнее, чем мобильный сайт, из-за необходимости дополнительного CSS. Однако, если дизайнеры осведомлены о потенциальных ловушках, они должны быть в состоянии создавать быстро загружаемые таблицы стилей для адаптивного сайта. В частности, рекомендуется:
- избегайте использования URI данных для изображений — двоичные фоновые изображения (обычно) загружаются только тогда, когда они необходимы, но все URI данных будут загружаться независимо.
- держите его легким — поскольку весь CSS должен быть загружен, важно быть эффективным. Это означает, что нужно избегать дублирования и следить за тем, чтобы глобальные правила устанавливались вне CSS, управляемого медиа-запросами.
RESS (отзывчивый веб-дизайн + серверные компоненты)
RESS — это гибрид отзывчивого и адаптивного дизайна, который включает в себя пользовательский агент, анализирующий сервер, чтобы посмотреть на характеристики клиентского устройства и доставить соответствующий ему контент.
Если одно из возражений против адаптивного дизайна заключается в том, что он предполагает доставку всего контента на все устройства, почему бы не смягчить это, вырезав часть этого контента там, где это возможно?
Это может иметь большой смысл. Если есть изображение, которое, как вы знаете, вы никогда не захотите отображать на устройствах, экран которых меньше определенного размера, вы можете также не отправлять его на эти устройства, экономя пропускную способность и сокращая время загрузки.
Более того, если вы используете медиа-запросы, которые, как вы знаете, не могут быть удовлетворены на определенных устройствах, есть по крайней мере аргумент в пользу разделения вашего CSS на разные файлы и загрузки их условно.
Стоит иметь в виду, что весь этот процесс не является «бесплатным» с точки зрения производительности. Определенная работа, очевидно, должна выполняться на сервере, что требует времени — вероятно, недостаточного, чтобы перевесить преимущества, но об этом следует знать.
Вердикт
Отзывчивые сайты работают медленно?
Это зависит от того, что вы подразумеваете под медленным.
Может ли самый быстрый сайт, который вы могли бы сделать, работать медленнее, чем самый быстрый специализированный мобильный сайт, который вы могли бы сделать?
Вероятно.
Мы также видели, что есть несколько подводных камней. Если вы не будете осторожны, вы можете легко заставить пользователей загружать множество избыточных изображений и CSS, что сделает ваш адаптивный сайт намного медленнее, чем нужно.
Однако так быть не должно. Вполне возможно создать адаптивный сайт, который работает настолько быстро, насколько это необходимо, и обеспечивает превосходное взаимодействие с пользователем. И по мере того, как стандарты и браузеры начинают догонять то, что разработчики хотят предоставить, это должно становиться проще.