Автор: Эбби Гамильтон (Abby Hamilton), SEO-менеджер, Merkle.
В 2018 году среднее время для полной загрузки мобильной страницы составляло 15 секунд, что значительно больше, чем рекомендуемые Google 3 секунды. Поэтому сегодня уменьшение общего времени загрузки остаётся основным приоритетом.
Однако скорость страницы – это не только общее время её загрузки, это также и опыт пользователей в эти 3 (или 15) секунд. В связи с этим важно учитывать, насколько эффективно осуществляется рендеринг страниц.
Эффективность этого процесса достигается за счёт оптимизации критического пути рендеринга для максимально быстрого получения первой отрисовки контента.
По сути, вы сокращаете время, затрачиваемое пользователями на просмотр белого экрана до отображения визуального контента.
На сайте Google Developers подробно описано, как оптимизировать критический путь рендеринга (спасибо автору статьи, Илье Григорику). Но мы сосредоточимся на одном из основных моментов: сокращении количества блокирующих рендеринг ресурсов.
Что такое «критический путь рендеринга»?
Критический путь рендеринга относится к серии шагов, которые браузер предпринимает для рендеринга страницы путем преобразования HTML, CSS и JavaScript в фактические пиксели на экране.
По сути, браузер должен запрашивать, получать и анализировать все файлы HTML и CSS (плюс выполнять некоторую дополнительную работу), прежде чем он начнёт отображать любой визуальный контент.
Пока браузер не выполнит эти шаги, пользователи будут видеть пустую белую страницу.
Как его оптимизировать?
Улучшение критического пути рендеринга включает идентификацию и анализ критических ресурсов (всех ресурсов, блокирующих первоначальный рендеринг страницы), а также поиск возможностей для:
- Сокращения количества критических ресурсов через откладывание загрузки тех ресурсов, что блокируют рендеринг;
- Сокращения критического пути посредством приоритизации контента на первом экране и максимально быстрой загрузки всех важных ресурсов;
- Сокращения числа критических байтов через уменьшение размера файлов оставшихся критических ресурсов.
В статье мы сосредоточимся на первом шаге – откладывании загрузки тех ресурсов, что блокируют рендеринг (другими словами, речь пойдёт о реорганизации элементов для повышения эффективности, чтобы создать ощущение о более быстром процессе без удаления содержимого).
Зачем это нужно?
Как говорил изображённый на стодолларовой купюре Бенджамин Франклин: «Время – деньги».
Данные Google о поведении пользователей показывают, что большинство людей покидают медленные сайты через 3 секунды после начала загрузки.
При этом, согласно результатам исследования Unbounce, около 75% пользователей готовы ждать 4 секунды и больше, пока страница не загрузится.
Что это даcт?
«Время – иллюзия», - Альберт Энштейн.
Исследование, опубликованное The Journal of Consumer Research, показало, что в целом можно выделить два типа времени:
- Объективное – стандартное время, которое мы видим на часах.
- Субъективное – восприятие времени отдельным человеком.
Слишком сильный фокус на объективном времени может быть не совсем правильным подходом, поскольку пользователи по-разному оценивают время.
Восприятие времени людьми основано на ряде субъективных факторов. Включая то, находятся ли они в «пассивном ожидании» или же в «активном». С точки зрения рендеринга страницы, это можно определить так:
- Пассивное ожидание – пользователь смотрит на пустой белый экран.
- Активное ожидание – на странице отображается визуальный контент.
Исследование INFORMS выяснило, что даже при соизмеримом времени ожидания люди в состоянии пассивного ожидания переоценивают время ожидания на 36%.
Эта же концепция легла в основу широкого использования в ПО визуального индикатора загрузки, поскольку было установлено, что добавление этого элемента снижает беспокойство и создаёт более позитивный опыт для пользователей.
«У веб-страниц нет индикаторов загрузки. Поэтому, когда страница медленная, посетитель не знает, сколько составит задержка – 500 мсек или 15 сек. Может быть, она вообще никогда не загрузится. А кнопка “Назад” всегда под рукой», - Энди Крестодина (Andy Crestodina), Orbit Media.
В связи с тем, что многие исследования связывают сокращение времени загрузки страницы с улучшением ценных KPI (конверсий, показателя отказов, времени на сайте), работа над этим показателем стала одним из главных приоритетов для многих организаций.
При этом уникальное положение SEO-специалистов позволяет им возглавить эту инициативу, поскольку их роль часто заключается в том, чтобы преодолеть разрыв между целями бизнеса и приоритетами программиста.
Возвращаясь к блокирующим рендеринг ресурсам
Главная цель оптимизации критического пути рендеринга – это приоритизация тех ресурсов, которые необходимы для отображения значимого контента.
Для этого нам нужно идентифицировать и деприоритизировать блокирующие рендеринг ресурсы – те ресурсы, которые не являются необходимыми для загрузки контента на первом экране и тормозят рендеринг страницы.
- Блокировка рендеринга из-за CSS
CSS по своей сути блокирует рендеринг. Браузер не начнёт отображать содержимое страницы, пока не сможет запрашивать, получать и обрабатывать все стили CSS. Это позволяет избежать негативного пользовательского опыта, который может возникнуть, если браузер попытается отобразить не стилизованный контент.
Страница, отображаемая без CSS, будет практически непригодна для использования, и большую часть контента (если не весь) потребуется перерисовать.
Оглядываясь на процесс рендеринга страницы, серый прямоугольник на изображении ниже отображает время, которое требуется браузеру для запроса и загрузки всех ресурсов CSS, чтобы он мог начать строить дерево CCSOM (DOM CSS).
При этом итоговое время может сильно различаться в зависимости от количества и размера CSS-ресурсов.
«CSS является ресурсом, блокирующим рендеринг. Передайте его клиенту как можно скорее, чтобы оптимизировать время первого рендеринга», - советует Илья Григорик из Google.
- Блокировка рендеринга из-за JavaScript
Подождите, а как насчёт JavaScript?
В отличие от CSS, для визуализации страницы браузеру не требуется загружать и анализировать все ресурсы JavaScript, поэтому технически* это не обязательный шаг (* большинству современных веб-сайтов для реализации контента на первом экране требуется JavaScript).
Тем не менее, когда браузер обнаруживает JavaScript перед начальным рендерингом страницы, этот процесс приостанавливается до тех пор, пока не будет выполнен JavaScript (если не указано иное с использованием атрибутов defer или async – подробнее об этом позже).
Например, добавление JS-оповещений в HTML-код блокирует рендеринг страницы до тех пор, пока не завершится выполнение кода JavaScript.
Это связано с тем, что JavaScript обладает способностью манипулировать элементами страницы (HTML) и связанными с ними стилями (CSS).
Поскольку теоретически JavaScript может изменить весь контент на странице, браузер на всякий случай приостанавливает анализ HTML для загрузки и выполнения JavaScript.
Официальная рекомендация Google:
«JavaScript также может блокировать построение DOM и задерживать отображение страницы. Чтобы обеспечить оптимальную производительность ... исключите ненужный JavaScript из критического пути рендеринга».
Как определить блокирующие рендеринг ресурсы
Чтобы определить критический путь рендеринга и проанализировать критические ресурсы, выполните следующие шаги:
- Протестируйте страницу с помощью webpagetest.org. В результатах проверки нажмите на изображение в столбце «Waterfall».
- Сосредоточьтесь на всех ресурсах, запрошенных и загруженных до зеленой линии «Start Render».
- Проанализируйте данные, ищите CSS- или JS-файлы, которые запрашиваются перед зелёной линией «Start Render», но не являются критичными для загрузки контента на первом экране.
- После определения потенциального блокирующего рендеринг ресурса, протестируйте его удаление, чтобы увидеть, не повлияет ли это на контент на первом экране.
Например, мы заметили, что некоторые JS-запросы к Google Maps API не кажутся критичными. Но было бы неплохо протестировать удаление этих сценариев, чтобы проверить, как смещение элементов на сайте повлияет на пользовательский опыт.
Чтобы проверить в браузере, как откладывание этих ресурсов повлияет на контент на первом экране, выполните следующие шаги:
- Откройте страницу в Chrome в режиме инкогнито (это лучшая практика для проверки скорости страницы, поскольку расширения Chrome могут искажать результаты, а многие из нас используют их в своей работе);
- Откройте инструменты разработчика Chrome (F12), на панели «Network» выберите тот ресурс, который нужно заблокировать, в контекстном меню найдите пункт «Block Request URL» и перейдите на вкладку «Request blocking».
- Поставьте галочку рядом с «Enable request blocking» и нажмите на значок «+».
- Введите паттерн для блокировки обнаруженных вами ресурсов, используя * в качестве подстановочного знака.
- Нажмите «Add» и обновите страницу.
Методы для уменьшения блокировки рендеринга
Когда вы выясните, что ресурс не является критически важным для рендеринга содержимого на первом экране, изучите различные методы, доступные для отсрочки загрузки ресурсов и улучшения рендеринга страницы.
| Метод | Влияние | Работает с |
| Размещение JS в нижней части HTML | Низкое | JS |
| Атрибут asinc или defer | Среднее | JS |
| Индивидуальные решения | Высокое | JS/CSS |
| Медиазапросы CSS | Низкое/Высокое | CSS |
- Размещение JavaScript в нижней части HTML
Если вы когда-нибудь проходили курс по основам веб-дизайна, то этот метод может быть вам знаком: поместите ссылки на таблицы стилей CSS в верхнюю часть HTML-тега <head>, а внешние скрипты – в нижнюю часть тега <body> (перед </body>).
Возвращаясь к примеру JS-оповещений, чем выше эта функция расположена в HTML, тем быстрее она будет загружена и выполнена браузером.
Хотя размещение ресурсов JavaScript в нижней части HTML остаётся стандартной лучшей практикой, этот метод является недостаточно оптимальным для исключения блокирующих рендеринг скриптов из критического пути.
Продолжайте использовать этот метод для критически важных сценариев, но исследуйте и другие решения, чтобы отложить некритические сценарии.
- Использование атрибута async или defer
Атрибут async сигнализирует браузеру об асинхронной загрузке JavaScript и извлекает скрипт, когда ресурсы становятся доступными (в отличие от приостановки анализа HTML).
После того, как скрипт извлечен и загружен, анализ HTML приостанавливается, а скрипт выполняется.
Атрибут defer сигнализирует браузеру, чтобы он произвёл асинхронную загрузку JavaScript (аналогично атрибуту async), но не выполнял JS до завершения парсинга HTML, что приводит к дополнительной экономии времени.
Оба метода относительно просты в реализации и помогают сократить время, затрачиваемое браузером на парсинг HTML (первый шаг в рендеринге страницы), без существенных изменений в том, как загружается контент на странице.
Async и defer – это хорошие решения для дополнительных элементов на сайте, таких как кнопки социальных сетей, персонализированная боковая панель, новостные фиды и т.п., которые приятно иметь, но которые не составляют основной пользовательский опыт.
- Собственные решения
Помните то раздражающее JS-оповещение, которое блокировало рендеринг страницы? Добавление JavaScript-функции с событием onload решило эту проблему раз и навсегда.
Скрипт ниже использует событие onload для вызова внешнего ресурса «alert.js» только после завершения загрузки всего исходного содержимого страницы, удаляя его из критического пути.
Но это не универсальное решение.
Хотя этот способ может быть полезен для ресурсов с самым низким приоритетом (прослушивателей событий, элементов в футере страницы и т.п.), вам, вероятно, потребуется другое решение для важного контента, расположенного ниже первого экрана.
Вместе с командой разработчиков попробуйте найти наиболее эффективное решение для улучшения рендеринга страниц при сохранении оптимального UX.
- Медиазапросы CSS
Медиазапросы CSS позволяют разблокировать рендеринг через пометку тех ресурсов, которые используются только некоторое время, и установку условий, когда браузер должен анализировать CSS (на основе печати, ориентации страницы, размера области просмотра и т.п.).
Все ресурсы CSS будут всё равно запрошены и загружены, но с более низким приоритетом для неблокирующих ресурсов.
По возможности используйте медиазапросы CSS, чтобы сообщить браузеру, какие ресурсы CSS являются (и не являются) критическими для отображения страницы.
Заключение
Целью оптимизации критического пути рендеринга является максимально быстрое предоставление пользователям значимого контента.
Откладывание блокирующих рендеринг CSS- и JS-ресурсов позволяет быстрее отобразить важный контент.
Чтобы определить блокирующие рендеринг ресурсы:
- Найдите некритические ресурсы, которые загружаются перед началом рендеринга (зелёная линия в результатах проверки на webpagetest.org);
- Протестируйте удаление этих ресурсов с помощью инструментов разработчика Chrome, чтобы понять, как они влияют на контент страницы;
- После того, как блокирующие рендеринг ресурсы будут определены, вместе с разработчиками найдите наиболее эффективное решение для отсрочки их загрузки.
