Оптимизация Critical Rendering Path (CRP) может существенно повлиять на производительность вашего сайта. В этой статье мы объясняем, что такое CRP, почему он так важен, и как его можно улучшить.

Содержание

Что такое Critical Rendering Path?

Critical Rendering Path (CRP) это этапы работы (шаги), выполняемые браузером для преобразования HTML, CSS и JavaScript в отображаемые пиксели на экране или, проще говоря, отрисовка страницы. Большая часть этой работы скрыта от веб-разработчиков и пользователей, но для оптимизации производительности сайта важно понимать, что происходит на всех промежуточных этапах.

Шаги CRP:

Почему CRP так важен?

С июня 2021-го пользовательский опыт является одним из важнейших факторов при определении рейтинга страницы в выдаче Google. Именно поэтому очень важно, чтобы сайт соответствовал всем трем критериям Core Web Vital: скорости загрузки основного контента (Largest Contentful Paint или LCP), времени ожидания до первого взаимодействия с контентом (First Input Delay или FID) и совокупному сдвигу макета (Cumulative Layout Shift или CLS). В противном случае сайт хуже ранжируется в результатах поиска, что ведет к потере части поискового трафика.

Оптимизируя CRP сайта, вы можете значительно сократить время до появления на экране первых пикселей страниц и тем самым улучшить показатель LCP. Кроме того, понимание критического пути рендеринга служит основой для создания хорошо работающих интерактивных приложений, способных улучшить показатель FID.

Что влияет на CRP?

  • Сетевая нагрузка (время отклика веб-сервера): помните, что сотовые сети всегда требуют гораздо больше времени на установку соединения, вне зависимости от скорости сети.
  • HTML-код: невозможно отобразить веб-страницу без полной загрузки HTML и построения объектной модели документа (DOM). Отрисовка страницы может начаться только после полной загрузки HTML.
  • CSS: имеет свою собственную объектную модель, CSSOM, которая также должна быть создана и применена к DOM. Процесс построения CSSOM блокирует процесс отрисовки.
  • Шрифты: загрузка всех подключаемых шрифтов страницы, на которые имеются ссылки в DOM/CSSOM, также блокирует отрисовку.
  • JavaScript: Взаимодействуя как с HTML, так и с CSS, JavaScript потенциально является наиболее “разрушительным” компонентом, влияющим на CRP. Пока JavaScript загружается и выполняется, браузеры прекращают рендеринг, если не предпринимаются дополнительные шаги. В результате выполнения JS может быть изменен на DOM/CSSOM, что влечет за собой повторение всех шагов CRP сначала.

А изображения?

Обратите внимание, что изображения являются самой тяжелой частью большинства веб-страниц, Однако, они не включены в приведенный выше список компонентов CRP, так как изображения представляют собой простое содержимое и не требуют особого обращения, а потому не оказывают никакого влияния. Фактический процесс рендеринга (построение дерева DOM) не зависит от изображений и не блокируется их загрузкой.

Как определить, есть ли проблемы с CRP?

Такие инструменты как webpagetest.org и Chrome DevTools очень полезны для поиска проблемных мест. Диаграммы также наглядно демонстрируют, что происходит с вашей страницей. В качестве примера на скриншоте ниже показано, как несколько js/css файлов загружаются до начала рендера (вертикальная зеленая полоса) и откладывают его, не позволяя пользователю начать взаимодействие со страницей.

Как сократить CRP и получить прирост производительности?

Оптимизируйте скорость ответа сервера и используйте CDN

Прежде всего, для оптимизации CRP нужен быстрый ответ сервера, так как от этого напрямую зависит большинство метрик производительности. Обычно, эта величина измеряется как «время получения первого байта» или TTFB. Оптимальное «время получения первого байта» должно составлять менее 200 миллисекунд.

Чтобы улучшить время ответа сервера, можно также использовать сеть доставки контента (CDN), например Cloudflare Enterprise. CDN осуществляет доставку контента, основываясь на геолокации пользователя. Сочетая этот способ с HTML-кэшированием заметно увеличит прирост производительности вашего сайта. 

Сформируйте верхнюю часть страницы (above-the-fold)

Контент (все компоненты, входящие в CRP) загружается браузером отдельными «фрагментами». Однако может показаться, что это происходит в одном устойчивом потоке, так как «фрагменты» загружаются в быстрой, близкой последовательности. Каждый фрагмент сайта состоит из пакета данных размером до 14 КБ, что в результате ведет к более быстрой загрузки веб-страницы размером 14 КБ или меньше. Для страницы 15 КБ потребуются уже два фрагмента, для страницы 29 КБ 一 три, и так далее. При стабильном подключении к Интернету и ненагруженном сервере, страница весом 14 КБ будет загружена и полностью обработана менее чем за 1 секунду.

Формирование первого экрана (Above the Fold) веб-страницы критически важно для положительного пользовательского опыта. В CRP должны быть включены только коды/ресурсы, необходимые для визуализации первого экрана веб-страницы (Above The Fold). В противном случае, вы получите пустой белый экран до тех пор, пока все важные элементы первого экрана не станут видимыми.

Зная принципы работы браузера и формирования содержимого above-the-fold, вы сможете обеспечить положительный пользовательский опыт. Для этого мы рекомендуем сделать следующее:

  1. Возьмите среднюю веб-страницу размером 1,2 мб.
  2. Поместите критически важные компоненты (части HTML/CSS/JS/шрифты, которые имеют решающее значение для отрисовки содержимого в одном экране) в первые 14 КБ. Это максимально ускорит отрисовку страницы для пользователей.
  3. Оставшееся содержимое загружайте асинхронно, либо переместите ниже в коде (например, перед закрывающим тегом </body>).

Соблюдайте общие рекомендации

Также существуют несколько общих правил, которым могут следовать веб-разработчики для улучшения критических путей рендеринга страниц. Это, в свою очередь, положительно скажется на максимальной производительности и улучшит показатели LCP и FID:

  1. Все блокирующие компоненты CRP, находящиеся в HEAD, в сумме должны составлять меньше 14 КБ.
  2. Все ресурсы критического пути должны подгружаться с одного доменного имени, чтобы минимизировать время поиска DNS.
  3. Устраните редиректы, так как они вызывают дополнительные сетевые задержки.
  4. Отрисовка выполняется быстрее и эффективнее, когда CSS предшествует JavaScript.
  5. Старайтесь обеспечить асинхронное обслуживание JavaScript (async/defer). Если это невозможно, разместите синхронный скрипт как можно ниже в коде документа, чтобы он не попал в первые 14 КБ загружаемых данных.
  6. Объедините и уменьшите все файлы CSS и JS.
  7. Организуйте Code splitting. Загружайте только те ресурсы, которые вам нужны для данной страницы. Это кажется очевидным, однако некоторые фреймворки и CMS (Content Management System) используют все CSS и JS на каждой странице, независимо от того, используются они или нет. 

Как Clickio Prism влияет на CRP?

Prism автоматически преобразовывает контент оригинального сайта в привычное для пользователей мобильное приложение, улучшая показатели LCP и FID, сохраняя при этом контент, имеющийся на оригинальном сайте. 

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

  1. Организуем архитектуру на основе app-shell, согласно паттерну PRPL.
  2. Разделяем css на две части: critical css и прочий css, который подключается асинхронно после того, как отрисовывается контент в первом экране (Above The Fold).
  3. Создаем механизм для управления очередностью асинхронной загрузки подключаемого контента (виджетов). 
  4. Разделяем монолитный бандл javascript на отдельные файлы. Необходимые модули подключаются только в том случае, если они используются на странице. При подключении скриптов используется стратегию модулей type=”module”.
  5. Переносим в модули большинство inline-js и inline-css кода.
  6. Большинство виджетов/компонентов, которые не используются в первом экране, переводим на client-side рендеринг — с сервера запрашивается только json-конфигурация. Это, в свою очередь, уменьшает общий вес app-shell, увеличивает скорость рендера страниц и уменьшает затраты CPU на обработку ресурсов.

После внедрения указанных модификаций показатели LCP и FID на сайтах партнеров, использующих Prism, вырастают на 5-20%.

Почему бы не воспользоваться бесплатным пробным периодом Prism, чтобы ощутить разницу в производительности и доходах от рекламы? Если вы действующий партнер Clickio — просто свяжитесь с вашим аккаунт-менеджером. В противном случае зарегистрироваться и попробовать Prism бесплатно можно здесь