В 2018 году среднее время для полной загрузки мобильной страницы составляло 15 секунд, что значительно больше, чем рекомендуемые Google 3 секунды. Поэтому сегодня уменьшение общего времени загрузки остаётся основным приоритетом.
Однако скорость страницы – это не только общее время её загрузки, это также и опыт пользователей в эти 3 (или 15) секунд. В связи с этим важно учитывать, насколько эффективно осуществляется рендеринг страниц.
Эффективность этого процесса достигается за счёт оптимизации критического пути рендеринга для максимально быстрого получения первой отрисовки контента.
По сути, вы сокращаете время, затрачиваемое пользователями на просмотр белого экрана до отображения визуального контента.
На сайте Google Developers подробно описано, как оптимизировать критический путь рендеринга (спасибо автору статьи, Илье Григорику). Но мы сосредоточимся на одном из основных моментов: сокращении количества блокирующих рендеринг ресурсов.
Что такое «критический путь рендеринга»?
Критический путь рендеринга относится к серии шагов, которые браузер предпринимает для рендеринга страницы путем преобразования HTML, CSS и JavaScript в фактические пиксели на экране.
По сути, браузер должен запрашивать, получать и анализировать все файлы HTML и CSS (плюс выполнять некоторую дополнительную работу), прежде чем он начнёт отображать любой визуальный контент.
Пока браузер не выполнит эти шаги, пользователи будут видеть пустую белую страницу.
Как его оптимизировать?
Улучшение критического пути рендеринга включает идентификацию и анализ критических ресурсов (всех ресурсов, блокирующих первоначальный рендеринг страницы), а также поиск возможностей для:
Сокращения количества критических ресурсов через откладывание загрузки тех ресурсов, что блокируют рендеринг;
Сокращения критического пути посредством приоритизации контента на первом экране и максимально быстрой загрузки всех важных ресурсов;
Сокращения числа критических байтов через уменьшение размера файлов оставшихся критических ресурсов.
Мы сосредоточимся на первом шаге – откладывании загрузки тех ресурсов, что блокируют рендеринг (другими словами, речь пойдёт о реорганизации элементов для повышения эффективности, чтобы создать ощущение о более быстром процессе без удаления содержимого).
Зачем это нужно?
Как говорил изображённый на стодолларовой купюре Бенджамин Франклин: «Время – деньги».
Данные Google о поведении пользователей показывают, что большинство людей покидают медленные сайты через 3 секунды после начала загрузки.
При этом, согласно результатам исследования Unbounce, около 75% пользователей готовы ждать 4 и больше секунд, пока страница не загрузится.
Возвращаясь к блокирующим рендеринг ресурсам
Главная цель оптимизации критического пути рендеринга – это приоритизация тех ресурсов, которые необходимы для отображения значимого контента.
Для этого нам нужно идентифицировать и деприоритизировать блокирующие рендеринг ресурсы – те ресурсы, которые не являются необходимыми для загрузки контента на первом экране и тормозят рендеринг страницы.
Блокировка рендеринга из-за 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.
«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» и обновите страницу.
Методы для уменьшения блокировки рендеринга
Когда вы выясните, что ресурс не является критически важным для рендеринга содержимого на первом экране, изучите различные методы, доступные для отсрочки загрузки ресурсов и улучшения рендеринга страницы.
Размещение 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, чтобы понять, как они влияют на контент страницы;
После того, как блокирующие рендеринг ресурсы будут определены, вместе с разработчиками найдите наиболее эффективное решение для отсрочки их загрузки.
Доля no-click запросов к Google впервые превысила 50%
В июне доля поисковых запросов к Google без переходов на сайты впервые превысила 50%.
Аналитическая компания Jumpshot проанализировала 40 млн поисковых сессий в браузерах на десктопных и мобильных устройствах в США и выяснила, что количество no-click запросов составило 50,33%.
Что это изменение значит для отрасли, читайте в колонке.
В Яндекс.Вебмастере появилась возможность посмотреть список действующих турбо-страниц сайта.
С помощью новой функциональности можно выгрузить адреса всех страниц, доступных в технологии Турбо: так будет проще понять, какие из них стоит обновить или удалить.
В результате на первом экране помещается меньше результатов. Поисковик также продолжает экспериментировать с бесконечной прокруткой в десктопной версии SERP.
Google поделился более подробной информацией о тех сбоях в индексировании, которые имели место в последние несколько месяцев.
Компания также рассказала, какие уроки вынесла из этих ситуаций, и как планирует взаимодействовать с вебмастерами при возникновении подобных сбоев в будущем.
Комментариев нет:
Отправить комментарий