Оптимизация производительности веб-сайта и критического пути рендеринга

Соответствует ли производительность рендеринга вашей веб-страницы сегодняшним стандартам? Рендеринг — это процесс преобразования ответа сервера в картинку, которую браузер «рисует», когда пользователь посещает веб-сайт. Плохая производительность рендеринга может привести к относительно высокому показателю отказов.

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

Критический путь рендеринга

Критический путь рендеринга (CRP) — это процесс, через который проходит ваш браузер, чтобы преобразовать код в отображаемые пиксели на экране. Он состоит из нескольких этапов, некоторые из которых можно выполнять параллельно для экономии времени, а некоторые части необходимо выполнять последовательно. Вот это визуализируется:

Прежде всего, как только браузер получает ответ, он начинает его анализировать. Когда он сталкивается с зависимостью, он пытается загрузить ее.

Если это файл таблицы стилей, браузер должен будет полностью проанализировать его перед рендерингом страницы, поэтому говорят, что CSS блокирует рендеринг .

Если это сценарий, браузер должен: остановить синтаксический анализ, загрузить сценарий и запустить его. Только после этого он может продолжить синтаксический анализ, потому что программы JavaScript могут изменять содержимое веб-страницы (в частности, HTML). И именно поэтому JS называется блокировкой парсера .

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

Предпоследний шаг — перевести Render Tree в Layout. Этот этап также называется Reflow. Именно здесь рассчитывается каждая позиция каждого узла Render Tree, а также его размер.

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

Выводы, связанные с оптимизацией

Как вы можете догадаться, процесс оптимизации производительности сайта включает в себя изменения на сайте, которые уменьшают:

• Объем данных, которые необходимо передать
• Количество ресурсов, которые браузер должен загрузить (особенно блокирующих)
• Длина СРБ

Далее мы углубимся в детали того, как это делается, но сначала следует соблюдать важное правило.

Как измерить производительность

Важное правило оптимизации: сначала измерьте, затем оптимизируйте по мере необходимости . В инструментах разработки большинства браузеров есть вкладка « Производительность », где и происходят измерения. При оптимизации для самого быстрого начального (первого) рендеринга самое важное, на что следует обратить внимание, — это время следующих событий:

• Первая краска
• Первая содержательная краска
• Первая осмысленная краска

Здесь «Paint» означает успешный рендеринг страницы, последний этап критического пути рендеринга. Несколько рендеров могут происходить один за другим, потому что браузеры пытаются отобразить что-то как можно скорее и обновить позже.

Помимо времени рендеринга, нужно учитывать и другие вещи — самое главное, сколько блокирующих ресурсов используется и сколько времени требуется для их загрузки. Эта информация находится на вкладке «Производительность» после выполнения измерений.

Стратегии оптимизации производительности

Учитывая то, что мы узнали выше, существует три основных стратегии оптимизации производительности веб-сайта:

1. Сведение к минимуму объема данных, передаваемых по сети,
2. Сокращение общего количества ресурсов, которые будут передаваться по сети, и
3. Сокращение критического пути рендеринга

1. Минимизируйте объем передаваемых данных

Прежде всего, удалите все неиспользуемые части, такие как недостижимые функции в JavaScript, стили с селекторами, которые никогда не соответствуют ни одному элементу, и теги HTML, которые навсегда скрыты с помощью CSS. Во-вторых, удалите все дубликаты.

Затем я рекомендую внедрить автоматический процесс минификации. Например, он должен удалить все комментарии из того, что обслуживает ваш сервер (но не из исходного кода), и каждый символ, который не несет дополнительной информации (например, символы пробела в JS).

После того, как это будет сделано, то, что у нас останется, может быть текстом. Это означает, что мы можем безопасно применять алгоритм сжатия, такой как GZIP (который понимает большинство браузеров).

Наконец, есть кеширование. Это не поможет при первом отображении страницы браузером, но значительно сэкономит при последующих посещениях. Однако важно помнить о двух вещах:

• Если вы используете CDN, убедитесь, что кеширование поддерживается и правильно настроено.
• Вместо того, чтобы ждать истечения срока действия ресурсов, вы можете захотеть иметь способ обновить его раньше с вашей стороны. Встраивайте «отпечатки пальцев» файлов в их URL-адреса, чтобы сделать локальный кеш недействительным.

Конечно, политики кэширования должны быть определены для каждого ресурса. Некоторые из них могут редко меняться или вообще никогда не меняться. Другие меняются быстрее. Некоторые содержат конфиденциальную информацию, другие могут считаться общедоступными. Используйте директиву «private», чтобы CDN не кэшировали личные данные.

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

2. Уменьшите общее количество критических ресурсов

«Критический» относится только к ресурсам, необходимым для правильного отображения веб-страницы. Поэтому мы можем пропустить все стили, которые не участвуют в процессе напрямую. И все скрипты тоже.

Таблицы стилей

Чтобы сообщить браузеру, что определенные файлы CSS не требуются, мы должны установить атрибуты media для всех ссылок, ссылающихся на таблицы стилей. При таком подходе браузер будет обрабатывать только те ресурсы, которые соответствуют текущему media (типу устройства, размеру экрана) по мере необходимости, при этом понижая приоритет всех остальных таблиц стилей (они все равно будут обрабатываться, но не как часть критического рендеринга). дорожка). Например, если вы добавите атрибут media="print" к тегу style , ссылающемуся на стили для печати страницы, эти стили не будут мешать вашему критическому пути рендеринга, когда носитель не print (т. е. при отображении страницу в браузере).

Чтобы еще больше улучшить процесс, вы также можете сделать некоторые стили встроенными. Это избавляет нас как минимум от одного обращения к серверу, которое в противном случае потребовалось бы для получения таблицы стилей.

Скрипты

Как упоминалось выше, скрипты блокируют синтаксический анализатор, потому что они могут изменять DOM и CSSOM. Поэтому скрипты, которые их не изменяют, не должны блокироваться, что экономит нам время.

Чтобы реализовать это, все теги script должны быть отмечены атрибутами — либо async , либо defer .

Скрипты, помеченные как async , не блокируют построение DOM или CSSOM, поскольку они могут быть выполнены до построения CSSOM. Имейте в виду, однако, что встроенные скрипты в любом случае будут блокировать CSSOM, если вы не поместите их над CSS.

Напротив, скрипты, отмеченные defer , будут оцениваться в конце загрузки страницы. Следовательно, они не должны влиять на документ (иначе произойдет повторный рендеринг).

Другими словами, с defer сценарий не выполняется до тех пор, пока не будет запущено событие загрузки страницы, тогда как async позволяет сценарию работать в фоновом режиме, пока документ анализируется.

3. Сократите длину критического пути рендеринга

Наконец, длина CRP должна быть сокращена до возможного минимума. Частично для этого подходят подходы, описанные выше.

Медиа-запросы в качестве атрибутов для тегов стиля уменьшат общее количество ресурсов, которые необходимо загрузить. Атрибуты тега скрипта defer и async предотвратят блокировку синтаксического анализа соответствующими скриптами.

Минификация, сжатие и архивирование ресурсов с помощью GZIP уменьшит размер передаваемых данных (тем самым сократив время передачи данных).

Встраивание некоторых стилей и скриптов может уменьшить количество обращений между браузером и сервером.

Что мы еще не обсуждали, так это возможность перераспределения кода между файлами. Согласно последней идее лучшей производительности, первое, что веб-сайт должен делать быстрее всего, — это отображать содержимое ATF. ATF означает «выше сгиба». Это область, которая видна сразу, без прокрутки. Поэтому лучше всего переставить все, что связано с его рендерингом, так, чтобы нужные стили и скрипты загружались первыми, а все остальное останавливалось — ни парсинг, ни рендеринг. И всегда не забывайте измерять до и после внесения изменений.

Вывод: оптимизация охватывает весь стек

Таким образом, оптимизация производительности веб-сайта включает в себя все аспекты отклика вашего сайта, такие как кэширование, настройка CDN, рефакторинг, оптимизация ресурсов и другие, однако все это можно делать постепенно. Как веб-разработчик, вы должны использовать эту статью в качестве справочной информации и всегда помнить о измерении производительности до и после ваших экспериментов.

Разработчики браузеров делают все возможное, чтобы оптимизировать производительность веб-сайта для каждой посещаемой вами страницы, поэтому браузеры обычно реализуют так называемый «предварительный загрузчик». Эта часть программы сканирует перед ресурсом, который вы запросили в HTML, чтобы сделать несколько запросов одновременно и запустить их параллельно. Вот почему теги стилей в HTML лучше располагать близко друг к другу (построчно), а также теги сценария.

Кроме того, попробуйте пакетно обновлять HTML, чтобы избежать множественных событий макета, которые вызываются не только изменением DOM или CSSOM, но также изменением ориентации устройства и изменением размера окна.

Полезные ресурсы и дополнительная литература:

• Статистика PageSpeed
• Контрольный список кэширования
• Способ проверить, включен ли GZIP для вашего сайта.
• Высокопроизводительные браузерные сети: книга Ильи Григорика