5 хитростей по устранению ресурсов, блокирующих рендеринг
Ресурсы блокировки рендеринга - это статические файлы, такие как файлы шрифтов, HTML, CSS и JavaScript, которые жизненно важны для процесса рендеринга веб-страницы. Когда браузер сталкивается с ресурсом блокировки рендеринга, он прекращает загрузку остальных ресурсов до тех пор, пока эти критические файлы не будут обработаны. Тем временем весь процесс рендеринга приостанавливается. С другой стороны, ресурсы, не блокирующие рендеринг, не откладывают рендеринг страницы. Браузер может безопасно загрузить их в фоновом режиме после отрисовки начальной страницы.
Однако не все ресурсы, которые браузер считает блокирующими рендеринг, необходимы для первой отрисовки; все зависит от индивидуальных особенностей страницы. Есть передовые методы, которые вы можете использовать, чтобы превратить эти некритические ресурсы, блокирующие рендеринг, в некритические ресурсы, блокирующие рендеринг. Кроме того, вы также можете уменьшить количество и / или размер ресурсов, блокирующих рендеринг, которые все еще критичны и не могут быть устранены.
Зачем устранять ресурсы, блокирующие рендеринг?
Если вы уменьшите количество ресурсов, блокирующих рендеринг, вы можете сократить критический путь рендеринга и сократить время загрузки страницы, тем самым улучшив взаимодействие с пользователем и оптимизируя поисковую систему.
Есть три способа уменьшить количество и влияние ресурсов, блокирующих рендеринг:
- Сделайте их не блокирующими рендеринг ресурсами, отложив их загрузку
- Уменьшите общее количество ресурсов, блокирующих рендеринг, используя такие методы, как объединение (это также означает меньше HTTP-запросов)
- Уменьшите размер ресурса с помощью минификации, чтобы на странице было меньше байтов для загрузки
Типы ресурсов, блокирующих рендеринг
Как правило, браузер обрабатывает все, что находит в разделе <head> HTML-страницы, как блокировку рендеринга. Это включает в себя:
- Таблицы стилей CSS
- Файлы JavaScript добавленные в раздел
<head> - Шрифты, добавленные либо из CDN, либо с локального сервера
- Импорт HTML (хотя импорт HTML теперь устарел, вы все еще можете встретить его на старых страницах)
Изображения, медиафайлы и теги <script>, размещенные внизу раздела <body>, рассматриваются как ресурсы, не блокирующие рендеринг.
Теперь давайте рассмотрим пять стратегий для устранения или уменьшения количества и воздействия ресурсов, блокирующих рендеринг.
1. Не добавляйте CSS с правилом @import
Вы можете добавить CSS на страницу, используя:
- Тег
<link rel="stylesheet">, который нужно добавить в свой HTML - файл - Правило
@import, которое вам нужно добавить в ваш CSS-файл
Несмотря на то, что правило @import сохраняет ваш HTML-файл более чистым и позволяет хранить все ваши CSS-зависимости в одном месте, это не лучший выбор с точки зрения производительности. Правило @import позволяет импортировать CSS из других таблиц стилей, но это приводит к тому, что браузер обрабатывает ваш CSS-файл медленнее, поскольку ему также приходится загружать импортированные файлы. Пока это не произойдет, процесс рендеринга будет заблокирован.
Если вы хотите добавить на свою страницу более одного файла CSS, вы можете либо использовать тег <link>, либо объединить файлы с помощью инструмента минификации и / или объединения.
Вам нужно добавить элемент <link> в раздел <head> HTML-страницы следующим образом:
<head>
<link href="style.css" rel="stylesheet">
</head>2. Используйте атрибут media для условного CSS
По умолчанию браузер обрабатывает все файлы CSS как ресурсы, блокирующие рендеринг. Однако, если вы добавите атрибут media к тегу <link>, вы можете указать браузеру наличие условного файла CSS.
Условный CSS применяется только при определенных условиях, например, ниже или выше заданного размера области просмотра или на странице печати. С помощью атрибута media вы можете определить конкретное условие мультимедиа для файла CSS. Вы можете использовать любое значение, которое вы бы использовали для медиа-запроса в файле CSS. Например:
<link href="print.css" rel="stylesheet" media="print">
<link href="large.css" rel="stylesheet" media="screen and (min-width: 1500px)">
<link href="mobile.css" rel="stylesheet" media="screen and (max-width: 600px)">Несмотря на то, что эти файлы по-прежнему загружаются на все устройства, они становятся ресурсами, не блокирующими рендеринг, если условие оценивается как ложное. Однако они все равно будут блокировать рендеринг, если условие оценивается как истинное.
Например, таблица стилей mobile.css в приведенном выше примере будет блокировать рендеринг на мобильных устройствах с максимальной шириной области просмотра 600px и не блокировать рендеринг в окнах просмотра больше 600px.
Если у вас есть файл CSS с одним или несколькими медиа-запросами, вы можете извлечь все правила @media и сохранить их в виде отдельных файлов с помощью этого плагина PostCSS. Этот метод оптимизации производительности также называется разделением кода. Хотя разделение кода обычно упоминается в связи с JavaScript, вы также можете разделить большие файлы CSS и загружать каждый файл только тогда, когда это необходимо, чтобы сократить критический путь рендеринга и уменьшить время загрузки начальной страницы.
3. Используйте атрибуты defer и async для устранения визуализации блокировки JavaScript
Файлы JavaScript, добавленные в раздел документа <head>, по умолчанию обрабатываются как ресурсы, блокирующие рендеринг.
Вы можете удалить их из критического пути рендеринга, разместив теги <script> прямо перед закрывающим тегом </body> вместо раздела <head>. В этом случае они начнут загружаться только после того, как будет загружен весь HTML. Однако, поскольку загрузка этих сценариев начинается позже, загружаемые ими элементы, такие как реклама, анимация или динамические функции, могут загружаться позже, чем остальная часть внешнего интерфейса, особенно если это более длинный сценарий. Это может привести к заметным задержкам и отставанию пользовательского интерфейса при более медленных соединениях, что плохо для пользователя.
В атрибутах defer и async тега <script> предлагают решение этой проблемы. Оба являются логическими атрибутами, что означает, что если вы их добавите, они будут срабатывать без какой-либо дополнительной настройки. Они также добавляют скрипты в раздел <head> HTML-документа без блокировки рендеринга, но другим способом - отложенные скрипты соблюдают порядок документа, в то время как асинхронные скрипты не зависят от DOM.
Атрибут defer указывает браузеру загружать скрипт в фоновом режиме, чтобы он не блокировал рендеринг страницы. Отложенный сценарий выполняется после того, как DOM будет готов, но до того, как сработает событие DOMContentLoaded.
<script src="script01.js" defer></script>
<script src="script02.js" defer></script>Отложенные сценарии следуют порядку документов, как неотложные сценарии по умолчанию. Например, в приведенном выше примере, script01.js будет выполняться первым, независимо от того, какой скрипт загружается первым. Вы не можете добавить defer к встроенным скриптам; он работает только с внешними скриптами, которые определяют местоположение скрипта с помощью атрибута src.
С другой стороны, атрибут async сообщает браузеру, что сценарий полностью независим от страницы. Он будет загружен в фоновом режиме как ресурс, не блокирующий рендеринг, как и отложенные скрипты. Однако, в отличие от отложенных сценариев, асинхронные сценарии не следуют порядку документов, поэтому они будут выполняться всякий раз, когда они закончат загрузку, что может произойти в любое время.
Например, в приведенном ниже примере мы не можем быть уверены, какой сценарий запустится первым; это зависит исключительно от того, что загружается быстрее (обычно меньшее). Помните, что асинхронные сценарии независимы как от документа, так и друг от друга, поэтому порядок документов никоим образом не повлияет на них.
<script src="script03.js" async></script>
<script src="script04.js" async></script>Атрибут defer рекомендуется использовать для сценариев, которым требуется DOM, но вы хотите начать их загрузку до загрузки документа, не превращая их в блокирующий рендер ресурс. Вы также должны использовать defer, а не async, если порядок документов важен - например, когда последовательные сценарии зависят друг от друга.
Атрибут async рекомендуется использовать для независимых сторонних скриптов, таких как рекламные объявления, трекеры и аналитические скрипты. Например, Google Analytics рекомендует добавить атрибут async для поддержки асинхронной загрузки в современных браузерах.
4. Минимизируйте и объедините CSS и JavaScript.
Помимо удаления несущественных CSS и JavaScript из критического пути рендеринга, вы также можете минимизировать и объединить ресурсы, блокирующие рендеринг, и ресурсы, не блокирующие рендеринг.
Например, вы можете создавать пакеты для файлов, которые используют одни и те же правила загрузки, и минимизировать каждый пакет отдельно. Поскольку минифицированные файлы легче, а пакеты означают меньшее количество файлов в критическом пути рендеринга, начальный рендеринг страницы завершится раньше. Кроме того, загрузка ресурсов без блокировки рендеринга в фоновом режиме займет меньше времени.
Существует множество инструментов, которые помогут вам выполнить минификацию и объединение в соответствии с передовыми практиками, включая Minify, CSS Minifier, Minify Code и PostCSS. Инструменты сборки, такие как webpack, Parcel и Rollup, имеют встроенные функции минификации, объединения и разделения кода, которые позволяют быстро уменьшить количество ресурсов, блокирующих рендеринг.
5. Загрузите пользовательские шрифты локально.
Поскольку пользовательские шрифты вызываются из раздела <head> документа, они также блокируют отображение ресурсов. Например:
<link href="https://fonts.googleapis.com/css2?family=Lato&display=swap" rel="stylesheet"> Вы можете уменьшить влияние пользовательских шрифтов на начальную отрисовку страницы, добавляя их локально, а не извлекая их из сети доставки контента, такой как Google CDN. Поставщики шрифтов, как правило, добавляют несколько правил @font-face, многие из которых вам не понадобятся.
Например, Google Fonts добавляет правила @font-face для всех наборов символов, с которыми идет гарнитура, таких как латиница, кириллица, китайский, вьетнамский и другие. Скажем, например, что онлайн-файл CSS, который вы добавляете с тегом <link>, включает правила @font-face для семи различных наборов символов, но вы хотите использовать только один (например, латинский). Однако шрифты Google не загружают файлы шрифтов для всех наборов символов; они просто добавляют много избыточных правил @font-face в файл CSS.
Если вы добавляете шрифты локально, вы также можете минимизировать свой CSS, связанный со шрифтами, и связать его с остальной частью вашего CSS. Вы можете использовать Google Web Fonts Helper для быстрого создания локальных правил @font-face для Google Fonts. Например, вот что вам нужно добавить, чтобы включить начертание шрифта Lato Regular:
/* lato-regular - latin */
@font-face {
font-family: 'Lato';
font-style: normal;
font-weight: 400;
font-display: swap;
src: local('Lato Regular'), local('Lato-Regular'),
url('../fonts/lato-v16-latin-regular.woff2') format('woff2'),
url('../fonts/lato-v16-latin-regular.woff') format('woff');
}Обратите внимание, что Google Web Fonts Helper не добавляет правила font-display: swap; я сам добавил это в указанное выше объявление. Это дескриптор правила @font-face, позволяющего указать, как браузер должен отображать начертание шрифта на странице.
Используя font-display со значением swap, вы даете команду браузеру немедленно начать использовать системный шрифт и заменить его пользовательским шрифтом после загрузки (это правило также добавляется, когда вы извлекаете шрифт из CDN Google). Это позволяет избежать невидимого текста на странице, пока пользовательский шрифт все еще загружается.
Когда вы загружаете шрифты локально, убедитесь, что вы обслуживаете сжатые форматы шрифтов для современных браузеров, таких как WOFF и WOFF2. Помните, что более легкие файлы также уменьшают влияние ресурсов, блокирующих рендеринг. Помимо создания правил @font-face, Google Web Fonts Helper также позволяет загружать заархивированный файл, содержащий все нужные вам форматы шрифтов.
Почему не следует загружать пользовательские шрифты асинхронно
В некоторых статьях о ресурсах блокировки рендеринга рекомендуется использовать загрузчик веб-шрифтов TypeKit для асинхронной загрузки пользовательских шрифтов. Когда-то это был достойный инструмент, но он не обновлялся с 2017 года, и у него много нерешенных проблем. Я бы не рекомендовал его использовать.
Хотя асинхронная загрузка шрифтов сокращает критический путь рендеринга, вы всегда должны делать это осторожно. Если шрифты загружаются позже, чем содержимое страницы, на странице может возникнуть общая проблема UX, называемая миганием невидимого текста (FOIT).
Существуют различные способы, чтобы справиться с FOIT, например, использование сторонних библиотек или вышеупомянутое правило font-display: swap (см. поддержка браузера для font-display, плюс, обратите внимание, что использовать его с правилом swap просто превращает FOIT в FOUT - вспышка неокрашенного текста - но это не полностью устраняет проблему). Тем не менее, вы захотите потратить время на обдумывание того, действительно ли стоит идти по асинхронному маршруту с точки зрения производительности. Подумайте о весе дополнительных скриптов, потенциальных проблемах, пользователях с отключенным JavaScript (вам все равно нужно добавить статический элемент <link> в теги <noscript> для их поддержки) и т. д.
Резюме
В этой статье мы обсудили пять стратегий устранения ресурсов, блокирующих рендеринг. Обобщенно:
- Не используйте импорт CSS
- Загрузить условный CSS с атрибутами
media - Используйте атрибуты
deferиasyncдля устранения рендер блокировки JavaScript - Разделение, объединение и минимизация файлов CSS и JavaScript
- Локальная загрузка пользовательских шрифтов
Чтобы найти файлы блокировки рендеринга, вы можете использовать инструменты анализа производительности, такие как Lighthouse, web.dev (тот же инструмент, что и Lighthouse, только интегрированный в веб-приложение), GTmetrix и другие. Эти инструменты не только помогают найти ресурсы, блокирующие рендеринг, но и предлагают практические советы, которые помогут повысить производительность вашего сайта.
Список лучших практик, обсуждаемых в этой статье, не является исчерпывающим. Например, также неплохо проводить регулярные аудиты веб-сайтов для обнаружения и удаления неиспользуемого кода, который может иметь огромное влияние на время отрисовки начальной страницы.
Чтобы улучшить общее время загрузки страницы, вы также можете использовать подсказки ресурсов и директиву предварительной загрузки. Они не устраняют ресурсы, блокирующие рендеринг, сами по себе, но вы можете использовать их для уменьшения времени загрузки страницы. Ресурсы с блокировкой рендеринга не остановят процесс загрузки предварительно загруженных ресурсов, и вы также можете предварительно подключиться к Google CDN, чтобы веб-шрифты загружались быстрее, если вы не хотите загружать их локально.
