Critical rendering path что это
Критические этапы рендеринга
Оптимизация критических этапов рендеринга улучшает время до первого рендера. Понимание и оптимизация этих этапов чрезвычайно важны для того, чтобы рендерить приложение с нужной частотой кадров (60 кадров в секунду, fps) и предоставить пользователю удобный, плавный интерфейс.
Понимание этапов (CRP)
Производительность Web-приложений включает в себя запросы к серверу, получение ответов, загрузку, парсинг и выполнение скриптов, рендеринг, компоновку и отрисовку пикселей.
Document Object Model
Построение DOM инкрементально. Ответ в виде HTML превращается в токены, которые превращаются в узлы (nodes), которые формируют DOM дерево. Простейший узел начинается с startTag-токена и заканчивается токеном endTag. Узлы содержат всю необходимую информацию об HTML-элементе, соответствующем этому узлу. Узлы (nodes) связаны с Render Tree с помощью иерархии токенов: если какой-то набор startTag и endTag-токенов появляется между уже существующим набором токенов, мы получаем узел (node) внутри узла (node), то есть получаем иерархию дерева DOM.
Чем больше количество узлов (node) имеет приложение, тем дольше происходит формирование DOM tree, а значит дольше происходит обработка критических этапов рендеринга. Измеряйте! Несколько лишних узлов (node) не сделают погоды, но divitis обязательно приведёт к подвисаниям.
CSS Object Model
У CSS имеются свои правила валидации токенов. Помните, что C в CSS означает «Cascade». CSS-правила ниспадают каскадом. Иными словами, когда парсер преобразует токены в узлы (nodes), вложенные узлы наследуют стили от родительских. Инкрементальная обработка недоступна для CSS, потому что набор следующих правил может перезаписать предыдущие. Объектная модель CSS (CSSOM) строится по мере парсинга CSS, но она не может быть использована для построения дерева рендера (render tree), потому что может оказаться так, что следующий набор правил может сделать какой-либо из узлов дерева невидимым на экране. Это может привести к лишнему вызову компоновки и перерасчёта стилей.
Если вы измерите время, требуемое на парсинг CSS, вы будете удивлены тем, как быстро работают браузеры. Более специфичные правила более затратны, потому что требуют обхода большего числа узлов в DOM дереве, но эта дороговизна обходится довольно дёшево, особенно в сравнении с другими узкими местами производительности. Сначала измеряйте. Потом оптимизируйте, если это действительно необходимо. Вероятно, специфичность селекторов не то, что действительно затормаживает ваше приложение. Когда дело доходит до оптимизации CSS, улучшение производительность селекторов ускоряет рендеринг лишь на микросекунды. Существуют другие пути оптимизации CSS, такие как унификация, разделение CSS-файлов на разные файлы на основе медиавыражений.
Дерево рендера (Render Tree)
Дерево рендера охватывает сразу и содержимое страницы, и стили: это место, где DOM и CSSOM деревья комбинируются в одно дерево. Для построения дерева рендера браузер проверяет каждый узел (node) DOM, начиная от корневого (root) и определяет, какие CSS-правила нужно присоединить к этому узлу.
Компоновка (Layout)
В тот момент, когда дерево рендера (render tree) построено, становится возможным этап компоновки (layout). Компоновка зависит от размеров экрана. Этот этап определяет, где и как на странице будут спозиционированы элементы и каковы связи между элементами.
Мета тэг viewport, который вы можете указать в Head страницы, определяет ширину видимой области и влияет на компоновку. Без этого тэга браузеры используют ширину «по умолчанию», которая обычно составляет 960px. В браузерах, открывающихся по умолчанию в полноэкранном режиме, например, в браузере телефона, установка тега установит ширину видимой области в 100% от ширины экрана устройства, вместо того, чтобы использовать ширину по умолчанию. Эта ширина ( device-width) изменяется каждый раз, когда пользователь поворачивает телефон. Это приводит к запуску этапа компоновки. Равно как и при изменении размеров окна в обычном браузере.
Для уменьшения частоты и продолжительности этого этапа, группируйте обновления экрана и избегайте анимации свойств, связанных с box-моделью элементов.
Отрисовка (Paint)
Оптимизация CRP
Улучшайте загрузку страницы с помощью приоритизации ресурсов, с помощью контролирования порядка, в котором они грузятся и с помощью уменьшения размеров файлов. Главные подсказки здесь:
Улучшаем производительность сайта с помощью PageSpeed от Google
Всех приветствую! Присаживайтесь поудобнее, налейте вкусного чаю и давайте обсудим довольно популярную и животрепещущую тему: оптимизацию производительности сайта.
Одним из инструментов для анализа качества и usability страницы с составлением отчёта является PageSpeed Insights (далее просто PageSpeed).
Какие вопросы я затрону в статье:
При анализе мы получаем два результата: для десктопной и мобильной версий, где значения от 0 до 49 являются низкими, от 50 до 86 — средними, и от 87 до 100 — высокими.
С выходом 8-го релиза PageSpeed, на примере мобильной версии главной страницы ДомКлик (актуальной на момент написания статьи) мы можем увидеть значения ниже, чем, например, в 5-м релизе (см. дальше), что доказывает рост пороговых показателей и ужесточение требований к производительности сайтов.
Очень важно брать в расчёт производительность мобильной версии, потому что с июля 2018-го позиция мобильного сайта учитывается в том числе при ранжировании страниц, предназначенных для десктопа, тем более что большинство пользователей сейчас ищет информацию с мобильных устройств.
На текущий момент в основном используются: имитация мобильного устройства Nexus 5 на Android, сеть 3G со скоростью 8 мегабит/с., задержка 150 миллисекунд, рендерится на европейских серверах и применяется троттлинг процессора.
Показатели с каждым запуском анализа могут колебаться из-за A/B-тестов, изменений маршрутизации интернет-трафика, дополнительных активных расширений браузера, которые добавляют или изменяют сетевые запросы, и антивирусов.
Если говорить о критериях оценки, то основные представлены ниже:
First Contentful Paint — первичная отрисовка контента; показатель, определяющий интервал между началом загрузки страницы и появлением первого видимого блока, текста или изображения. Иными словами, время от ответа сервера до отрисовки, белый экран. Ответ сервера при этом не входит в этот показатель.
Speed Index — индекс скорости загрузки, который показывает, как быстро загружается содержимое.
Largest Contentful Paint — время отрисовки крупного содержимого, находящегося на первом экране. Под крупным содержимым мы понимаем картинки, видео или текст.
Time to Interactive — время, в течении которого страница становится полностью готова к взаимодействию с пользователем.
Total Blocking Time — сумма всех периодов от первой отрисовки содержимого, когда скорость выполнения задач превышала 50 мс. Измеряется в миллисекундах.
Cumulative Layout Shift — процентная величина, на которую смещаются видимые элементы области просмотра при загрузке.
Прежде чем описывать способы улучшения этих показателей, важно вспомнить, что такое Critical Render Path. Схематично шаги по отрисовке сайта выглядят следующим образом:
Как можно улучшить метрики?
Актуальная версия HTTP
Использование актуальной версии HTTP позволяет оптимизировать запросы к серверу. Если сравнивать версию HTTP/1.1, которая поддерживается до сих пор, и версию HTTP/2.0, то изменения ярко заметны и влияют на работу сайта в целом в HTML/2.0:
Оптимизация изображений
Используйте правильные размеры изображений. На странице не должно быть изображений, размер которых больше, чем можно отобразить на экране пользователя. С помощью «отзывчивых» изображений можно создать несколько версий каждой картинки, а затем через, к примеру, @media-запросы указать нужную для отображения. Также можно воспользоваться ресайзерами: thumbor, npm sharp, imagemagick или любым другим на ваш вкус.
Вне первого экрана важно использовать для всех изображений «ленивую загрузку», она позволяет подгружать картинки по мере необходимости.
Использование критического CSS
Прежде чем браузер отрисует содержимое страницы, он должен получить и обработать всю информацию о макете и внешних стилях для неё. Внешний CSS — это код, загружаемый через внешнюю таблицу стилей. В теории, он может считаться блокирующим, потому что, как сказано выше, браузер не сможет отрисовать страницу, пока этот код не будет обработан. Критический CSS отвечает за стили первого экрана сайта, такой код необходимо заинлайнить внутри прямо в HTML-документе, это снижает нагрузку на сервер.
Уменьшайте bundle.js
Минифицируйте JS и CSS, это ускорит анализ скриптов и сократит объём полезной сетевой нагрузки.
Откажитесь от тяжёлых библиотек и асинхронной/отложенной загрузки скриптов
Уменьшайте Critical Render Path
Включает в себя совокупность предыдущих пунктов. Сюда можно добавить «ленивую загрузку» DOM-элементов.
Использование SSR
Server Side Rendering — рендеринг страницы на сервере. В этом случае поисковые роботы получают готовый код сайта, что важно в условиях новых правил ранжирования.
Это основные моменты, которые работают на практике и которые мы применяем у себя в ДомКлик при разработке сервисов.
Для чего нам нужно улучшать метрики?
При грамотном использовании этих рекомендаций мы решаем основополагающие задачи: улучшение позиций, увеличение конверсии и снижение нагрузки на сервер. И, как следствие, пользователи довольны, а компания получает прибыль.
Очень ёмко и кратко смысл оптимизации описывает цитата из твиттера Википедии:
Cut page load by 100ms and you save Wikipedia readers 617 years of wait annually
Процесс визуализации
При визуализации страниц браузер проделывает огромную работу, которую мы, веб-разработчики, обычно не замечаем. Мы не знаем, как разметка, стили и скрипты превращаются в страницы на экране.
Оптимизация помогает сократить время загрузки веб-страниц. Кроме того, изучив процесс визуализации, вы сможете создавать более эффективные интерактивные приложения, потому что они подчиняются тем же принципам (разве что обновление приложения происходит циклично и с частотой 60 кадров/сек. Однако не будем спешить. Сначала разберемся, как браузер визуализирует простую веб-страницу.
Critical Rendering Path
You will learn how to optimize any website for speed by diving into the details of how mobile and desktop browsers render pages.
You’ll learn about the Critical Rendering Path, or the set of steps browsers must take to convert HTML, CSS and JavaScript into living, breathing websites. From there, you’ll start exploring and experimenting with tools to measure performance and simple strategies to deliver the first pixels to the screen as early as possible. You’ll learn how to dive into recommendations from PageSpeed Insights and the Timeline view of Google Chrome’s Developer Tools to find the data you need to achieve immediate performance boosts!
This is a free course offered through Udacity
Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License, and code samples are licensed under the Apache 2.0 License. For details, see the Google Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.
Critical Rendering Path
Optimizing the critical rendering path refers to prioritizing the display of content that relates to the current user action.
Delivering a fast web experience requires a lot of work by the browser. Most of this work is hidden from us as web developers: we write the markup, and a nice looking page comes out on the screen. But how exactly does the browser go from consuming our HTML, CSS, and JavaScript to rendered pixels on the screen?
By optimizing the critical rendering path we can significantly improve the time to first render of our pages. Further, understanding the critical rendering path also serves as a foundation for building well-performing interactive applications. The interactive updates process is the same, just done in a continuous loop and ideally at 60 frames per second! But first, an overview of how the browser displays a simple page.
Critical Rendering Path
You will learn how to optimize any website for speed by diving into the details of how mobile and desktop browsers render pages.
You’ll learn about the Critical Rendering Path, or the set of steps browsers must take to convert HTML, CSS and JavaScript into living, breathing websites. From there, you’ll start exploring and experimenting with tools to measure performance and simple strategies to deliver the first pixels to the screen as early as possible. You’ll learn how to dive into recommendations from PageSpeed Insights and the Timeline view of Google Chrome’s Developer Tools to find the data you need to achieve immediate performance boosts!
This is a free course offered through Udacity
Оптимизация критического пути рендеринга
Последние годы мы видим в вебе два тренда: 1. Веб-страницы значительно выросли, особенно в плане запросов по требуемой полосе пропускания и загружаемым ресурсам (стили, скрипты, изображения, шрифты). 2. Выросло количество пользователей, просматривающих сайты с мобильных телефонов и планшетов.
Дома у большинства есть ПК и быстрый интернет. Но ничуть не меньше пользователей, находящихся в иных условиях. Даже быстрое соединение 4G в дороге решает не все проблемы — остается проблема с экономией трафика и скоростью рендеринга на мобильных устройствах.
Все это ведет к новому отношению к скорости загрузки страниц и их оптимизации. Google повышает в выдаче страницы, грузящиеся быстрее секунды. 1 секунда это принятое оптимальное время ответа страницы (10 мс это мгновенно, 3 секунды заставляют отменить загрузку сайта, а 10 секунд ожидания могут навсегда отпугнуть посетителей).
Но как этого достигнуть, не урезая функциональность и не ухудшая внешний вид?
Идея состоит не только в том, чтобы перенести сайта на быстрый сервер и максимально уменьшить размер страниц. Нужно оптимизировать всю цепочку событий, которые происходят при рендеринге страницы в окне браузера. Эта цепочка называется критический путь рендеринга.
От загрузки страницы до рендеринга
Google определяет критический путь рендеринга как цепь шагов браузера от загрузки кода и ресурсов до его отображения на экране вплоть до отдельных пикселов.
Это совершенно меняет понятие “скорость загрузки страницы”. Недостаточно просто быстро загрузить страницу — решающее значение, особенно для пользователей мобильных устройств, имеет скорость появления визуального отображения страницы на экране. Важен именно критический путь — так как далеко не весь код на странице производит что-либо в окне браузера.
Для оптимизации критического пути рендеринга и, соответственно, скорости рендеринга, давайте рассмотрим внимательней шаги по рендерингу страницы и их взаимодействие.
От чистого листа до содержания
Представьте себя на месте пользователя, заходящего на сайт. После ввода URL, браузер отправляет запрос на сервер и получает в качестве ответа следующий HTML:
Браузер парсит этот поток байтов кода в объектную модель документа (DOM). DOM это полное древовидное представление HTML-разметки:
Примечание: браузер строит DOM постепенно. Это значит, что он может начать парсинг сразу, как только получит первые фрагменты кода, постепенно добавляя к дереву узлы. И это может быть использовано в некоторых продвинутых, но эффективных методиках оптимизации.
Этот небольшой фрагмент CSS парсится в объектную модель CSS или CSSOM.
К сожалению, CSSOM не может строится постепенно, как DOM. Представьте, что в нашей таблице стилей, приведенной выше есть третья строка, например p < font-weight: normal; >, переписывающая первую декларацию. И именно по причине каскадирования и переписывания, мы должны дождаться полной загрузки CSS, перед тем как перейти к рендерингу. Пока CSS не загружен — рендеринг блокирован.
Как только браузер получает машинно-читаемое представление разметки и стилей, он переходит к построению дерева рендеринга — структуры, сочетающей DOM и CSSOM для всех видимых элементов:
Отметьте, что тег span не является частью дерева рендеринга (еще одна причина, по которой рендеринг не начинается без CSS — только в CSS есть информация об отображении/не отображении элементов на странице).
Дерево рендеринга это хорошее представление контента, который мы затем увидим в окне браузера. Браузер начинает показывать пиксели после еще двух шагов: макетирования и отрисовки. При макетировании рассчитываются позиции и размеры элементов в соответствии с областью просмотра. Отрисовка это уже сам процесс отрисовки элементов на экране.
Каждый раз, когда дерево рендеринга меняется (при использовании интерактивного JS, например) или меняется область просмотра (путем изменения размеров браузера или поворота мобильного устройства), запускается отрисовка.
Полностью критический путь рендеринга для нашего простого примера выглядят так:
Как насчет изображений
Фактически только HTML, CSS и JavaScript критически важны для рендеринга (это ресурсы, загрузка которых блокирует рендеринг страницы). Как это не удивительно, изображения не блокируют ни построение DOM, ни первоначальный рендеринг страницы. Посмотрите на вкладку сеть в инструментах разработчика Chrome:
А теперь JavaScript
JavaScript это мощный инструмент и он имеет огромное значение для критического пути. Давайте добавим в наш параграф небольшой скрипт:
Даже этот простой фрагмент кода демонстрирует, что скрипты могут изменять и DOM, и CSSOM. Так как JavaScript может добавлять узлы в DOM, парсер останавливает свою работу, пока скрипты не будут выполнены. JavaScript блокирует парсер.
JS в примере запрашивает цвет элемента, а это значит, что CSSOM должна быть готова до запуска скрипта. CSS должен быть загружен до скриптов.
Давайте оценим критический путь после избавления от инлайнового скрипта и замены его ссылкой на внешний файл JavaScript:
Внешний файл JavaScript требует дополнительный запрос — инлайновый скрипт обходится без этого. Также отметьте — неважно какой файл, CSS и JS, будет загружен первым, парсинг CSS всегда начинается раньше. Если CSSOM построена, тогда уже выполняется скрипт. И только после этого парсер DOM разблокируется и завершает работу. Даже в простом сайте из нашего примера, находятся свои блокираторы, вмешивающиеся в процесс рендеринга.
Теперь, после того как мы выяснили, какие части сайта важны для рендеринга страницы и как они влияют друг на друга, мы рассмотрим конкретные методики оптимизации.
Три шага для оптимизации критического пути рендеринга
Есть три направления по которым мы можем оптимизировать критический путь рендеринга, увеличив скорость появления в браузере видимого результата для пользователя. Учитывайте, что оптимизация это всегда тщательные расчеты и компромиссы. И, к сожалению, нет универсального сценария оптимизации. Важно учитывать информацию из средств разработчика в браузерах, а также применять иные инструменты.
1. Минимизируйте объем трафика, передающегося на сайт.
Минифицируйте, сжимайте и кэшируйте ресурсы вашего сайта, а также его разметку. Да, HTML также блокирует рендеринг. Многие системы сборки (наиболее известные — Grunt и Gulp) поддерживают плагины минификации и очистки от лишних пробелов и комментариев.
Сжатие сокращает время загрузки страницы, а кэширование позволяет экономить трафик. Вместо загрузки по сети, критически важные ресурсы сохраняются в локальной копии.
Примечание: При минификации разметки HTML вы рискуете, что контент и стили отобразятся некорректно. Например, если вы разделяли строчно-блочные элементы пробелами, после минификации пробелы исчезнут вместе с отступом. Применяйте минификацию разметки HTML осторожно.
2. Минимизируйте блокирование рендеринга загрузкой CSS
Основной файл стилей уменьшится, а значит уменьшится и время блокировки рендеринга. Стили для печати будут использоваться только при печати и не будут загружаться в остальных случаях. Файл CSS для портретной ориентации будет загружаться же только при повороте мобильного устройства. Очевидно, что мы можем использовать медиа-запросы, чтобы отдельно загружать стили, необходимые только в особых ситуациях. Это уменьшает размер подключаемого блокирующего CSS, а значит, уменьшает и время, затрачиваемое браузером на парсинг. Примечание: Браузер по прежнему будет загружать дополнительные стили, но это будет происходить в низком приоритете, параллельно процессу рендеринга. Также в отдельных ситуациях можно инлайнировать блокирующий CSS — это позволяет сэкономить запросы и ограничить браузер парсингом HTML.
Как я упоминал, это все компромиссные меры. Иногда это может помочь, а иногда излишне увеличит размер критически важного CSS, вставленного в разные файлы.
Есть несколько автоматических инструментов для оптимизации CSS:
3. Минимизируйте блокирующий рендеринг JavaScript
Точно так же как и CSS, JavaScript можно включать напрямую в разметку, чтобы сэкономить на сетевых запросах.
В лучшем случае вы не подключаете JS до первоначальной загрузки страницы. Если это не возможно, попытайтесь отложить выполнение JS до события загрузки.
Также внимательно проверяйте свои и чужие скрипты. Если они не взаимодействуют с DOM или CSSOM, вы можете загрузить их асинхронно. Это делается просто:
С атрибутом async вы говорите браузеру, что необязательно немедленно исполнять скрипт по ссылке из HTML. Браузер строит DOM и только после построения DOM запускает выполнение скрипта. Представьте скрипт app.js, взаимодействующий только с Гугл-аналитикой и социальными сетями — если это скрипт не трогает DOM или CSSOM, он отличный кандидат на асинхронную загрузку.
Заключение
Большая часть статьи почерпнута из следующих источников:
Активней пользуйтесь инструментами, такими как Chrome DevTools, PageSpeed Insights или WebPagetest, чтобы понять, какие оптимизации возможны и необходимы.
Скорость рендеринга страницы может иметь решающее значение для ваших посетителей, которые обычно не привыкли долго ждать. Учитывайте это при разработке и поддержке сайта, от улучшения его производительности вы тоже выиграете.