Ресурсы блокировки рендеринга — это статические файлы, такие как файлы шрифтов, 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, чтобы веб-шрифты загружались быстрее, если вы не хотите загружать их локально.
09.04.2021
0
11 мин
6 520
Здравствуйте, друзья!
Сегодня я затрону интересную тему — как устранить ресурсы, блокирующие отображение в WordPress.
Если вы не знаете что это такое — читайте дальше и все поймете. Поехали!
«Ресурсы, блокирующие отображение» — если вы видели это всплывающее окно при тестировании скорости вашего веб-сайта или слышали о нем как о частой причине низкой скорости загрузки, вы, вероятно, сбиты с толку.
Вы ищете способы ускорить работу своего веб-сайта и избавиться от постороннего кода, замедляющего его работу, но с чего начать, чтобы это исправить?
К счастью для вас, устранить ресурсы, блокирующие отображение, не так сложно, если вы знаете, с чем имеете дело.
Простой плагин может помочь, или вы даже можете позаботиться об этом вручную, если хотите.
Совершенно потеряны?
Сейчас я объясню вам это простым языком, что такое ресурсы, блокирующие отображение, как узнать, есть ли они на вашем сайте, и что вы можете с ними сделать.
Что такое ресурсы, блокирующие отображение?
Когда кто-то посещает страницу вашего веб-сайта, ему необходимо загрузить (или «обработать») весь ее контент.
Сюда входит код, а именно HTML, CSS и Javascript.
И если вы не сделаете все возможное, чтобы его изменить, каждый последний скрипт необходимо будет загрузить, прежде чем пользователь вообще что-либо сможет увидеть.
Вот что означает блокировка отображения: она останавливает отображение страницы до тех пор, пока пользователь не закончит ее загрузку.
Все, что они получат — это пустой белый экран.
Но почему?
В HTML есть смысл в блокировке отображения.
HTML — это ядро вашего веб-сайта, где находится весь контент.
Без него у вас не было бы веб-сайта для загрузки.
А HTML обычно очень маленький, поэтому загрузка не займет много времени.
Проблемы могут возникнуть с CSS и Javascript.
CSS влияет на стиль вашей страницы — он позиционирует элементы, определяет макет и делает ваш сайт адаптивным.
Без CSS ваш сайт выглядел бы как большой блок текста с некоторыми ссылками и изображениями.
А Javascript делает ваш сайт динамичным, меняя его внешний вид на лету.
Плагины WordPress также могут использовать его для добавления функциональности вашему сайту.
Но вот в чем дело: не все скрипты видны сразу.
Все, что вам нужно для правильного отображения — это любые стили CSS и элементы Javascript, которые появляются над линией загрузки.
Остальные можно безопасно отодвинуть, чтобы страница могла отображаться до того, как полностью загрузится.
Если у вас есть ненужные ресурсы Javascript и CSS, вынуждающие пользователей ждать дольше, чем им нужно, вы увидите ошибку ресурсов, блокирующих отображение, при тестировании своего сайта.
Зачем избавляться от ресурсов, блокирующих отображение?
Поэтому людям приходится ждать еще несколько миллисекунд (или даже секунд!), чтобы сайт загрузился — какая разница?
Но это может иметь большее влияние на ваших посетителей, чем вы думаете.
Когда дело доходит до загрузки, на счету каждая секунда.
Все больше и больше владельцев веб-сайтов узнают, как сжимать свои изображения и код, и люди привыкли полагаться на более высокую скорость загрузки.
Если вы не будете идти в ногу со временем, скорее всего, они просто нажмут кнопку «Закрыть» ваш сайт и найдут другой.
Также стоит подумать о людях, использующих менее мощные мобильные устройства или более медленный интернет.
Вы можете относительно быстро загрузить свой сайт на настольном компьютере, но люди на телефонах или планшетах могут испытывать затруднения и ждать несколько секунд, чтобы пройти через белый экран.
Вы хотите сделать все, что в ваших силах, чтобы избавиться от всего, что может привести к зависанию вашего сайта.
Даже небольшая оптимизация, такая как удаление ресурсов, блокирующих отображение, может иметь огромное значение для некоторых людей.
Есть ли на вашем сайте ресурсы для блокировки отображения?
Возможно, вы здесь, потому что вам сказали, что на вашем сайте есть ресурсы, блокирующие отображение, и вы не знаете, как это исправить.
Но если вы еще не тестировали его, самое время это сделать.
Есть несколько бесплатных сервисов, которые могут указать на общие узкие места, влияющие на скорость загрузки, и они могут сказать вам, есть ли на вашем сайте скрипты, которые загружаются неэффективно.
PageSpeed Insights — самый популярный из этих инструментов.
Вы можете ввести любой URL-адрес, который хотите, чтобы увидеть их оценку сайта.
Переходите в этот сервис и введите адрес вашего сайта прямо сейчас.
Через несколько секунд появятся результаты.
Прокрутите вниз, и вы найдете возможности, которыми вы можете воспользоваться, чтобы сократить время загрузки, а также проверки, которые прошел ваш веб-сайт.
Если у него есть ресурсы, блокирующие отображение, вы должны увидеть их на вкладке «Оптимизация».
Вы можете спросить: а так ли важно получить идеальную оценку PageSpeed?
Ответ в том, что это зависит от обстоятельств.
Помните, что это автоматизированный инструмент и предназначен только для того, чтобы направить вас на верный путь.
Если вы жертвуете функциональностью или удобством для пользователя, чтобы получить высший балл, вы вообще ничего не добьетесь.
Но от ресурсов, блокирующих отображение, вы определенно захотите избавиться, поэтому давайте рассмотрим некоторые способы их удаления.
Устранение блокировки отрисовки CSS и Javascript вручную
Конечно, нет необходимости решать эту проблему вручную, так как существует множество плагинов, которые намного проще использовать, и мы рассмотрим их ниже.
Но если вы чувствуете себя комфортно при навигации по коду и предпочитаете использовать как можно меньше плагинов, вы всегда можете сделать все это самостоятельно.
Чтобы оптимизировать Javascript, вы можете выбрать отдельные скрипты, которые отображаются ниже на странице, и добавить к ним атрибут «async» или атрибу «defer».
Атрибут «async»
Атрибут «async» является логическим атрибутом.
Если он присутствует, он указывает, что сценарий будет выполняться асинхронно, как только он станет доступен.
Этот атрибут «async» предназначен только для внешних скриптов (и должен использоваться только при наличии атрибута «src»).
Существует несколько способов выполнения внешнего сценария:
- Если атрибут «async» присутствует: сценарий выполняется асинхронно с остальной частью страницы (сценарий будет выполняться, пока страница продолжает синтаксический анализ),
- Если атрибута «async» нет, а атрибут «defer» присутствует: сценарий выполняется, когда страница завершает синтаксический анализ,
- Если атрибут «async» и атрибут «defer» отсутствуют: сценарий извлекается и выполняется немедленно, прежде чем браузер продолжит синтаксический анализ страницы.
Атрибут «defer»
Атрибут «defer» также является логическим атрибутом.
Если он присутствует, он указывает, что сценарий выполняется после завершения синтаксического анализа страницы.
Атрибут «defer» предназначен только для внешних скриптов (и должен использоваться только при наличии атрибута «src»).
При загрузке по умолчанию с блокировкой отображения всякий раз, когда браузер встречает файл Javascript, он прекращает загрузку HTML для его загрузки и выполнения.
Атрибут «async» позволяет продолжить загрузку HTML наряду с Javascript, но на короткое время остановки загрузки для выполнения сценария.
Атрибут «defer» делает то же самое, но он выполняет скрипт только после завершения синтаксического анализа HTML.
Когда следует использовать любой из атрибутов?
Атрибут «async» иногда может нарушать работу скриптов в зависимости от порядка загрузки, например jQuery, поэтому в случае сомнений используйте «defer» — он всегда выполняет сценарии в правильном порядке.
Вы можете использовать независимые скрипты «async», которые не полагаются ни на что другое для загрузки.
Исправление CSS, блокирующего отображение, может потребовать немного больше работы.
Вы можете встроить CSS, который отображается для линии загрузки, поместив их в раздел <head> вашего HTML-документа.
Однако делайте это только с небольшими файлами и только со стилями, которые мгновенно увидит зритель.
Что касается остальной части вашего CSS, вы можете добавить атрибуты «async» или «defer» так же, как с Javascript.
Вы также можете добавить медиа-запросы к определенным стилям, чтобы они загружались только в определенных ситуациях.
Помните: вкладка «Coverage» (покрытие) в инструментах разработчика браузера может помочь вам быстро определить элементы, которые вашим посетителям нужно загрузить в первую очередь.
А также выявить неиспользуемый код, который можно удалить.
Плагины для устранения ресурсов, блокирующих отображение
Хотя можно оптимизировать Javascript и CSS, даже не касаясь плагина WordPress, вам не нужно делать всю эту работу.
Возможно, вы не чувствуете себя уверенно, работая с конфиденциальным кодом, или вам просто нужен инструмент, который лучше упрощает процесс.
В этом случае один из этих плагинов отлично справится со своей задачей.
Просто примечание: перед использованием любого из этих плагинов обязательно сделайте резервную копию своего сайта на случай, если что-то пойдет не так.
Autoptimize и Async Javascript
Созданные одним и тем же разработчиком, эти два плагина призваны помочь вам остановить эти скрипты страниц и переместить крайне необходимый код в <head> сайта, где он загружается первым.
Autoptimize — это универсальный плагин оптимизации.
Помимо минимизации изображений, HTML и других скриптов, он также может встраивать CSS и откладывать не очень важные скрипты.
Все это доступно одним нажатием кнопки.
Разработчики могут настроить плагин под свои нужды с помощью дополнительных опций и API.
Но большинству пользователей нужно будет установить только два флажка, чтобы исправить проблему с блокировкой отображения.
Просто зайдите в «Настройки — Autoptimize» в своей административной панели и включите «Оптимизировать код Javascript» и «Оптимизировать код CSS».
Обычно это срабатывает, но если у вас возникнут проблемы, вы можете поэкспериментировать с параметрами, а также с включением или отключением агрегированных файлов JS и агрегированных файлов CSS.
Хорошая идея начать с Autoptimize, и если вам по-прежнему выдают сообщение за ресурсы, блокирующие отображение, попробуйте «AsyncJS», чтобы наверняка добиться действующего результата.
Использовать его так же просто.
Посетите «Настройки — AsyncJS» и включите его.
Здесь вы можете выбрать между «async» или «defer».
Проверьте это, и если при «async» ваша страница ломается, включите «defer» вместо этого.
Вам также следует отложить или исключить jQuery, поскольку его включение «async» почти наверняка сломает ваш сайт.
WP Rocket
Одним из недостатков Autoptimize является то, что его может быть немного сложно настроить.
WP Rocket — это плагин премиум-класса, разработанный специально для простоты использования независимо от вашего уровня навыков.
Он кэширует, сжимает, минимизирует и, конечно же, может отложить ресурсы, блокирующие отображение.
При цене 49 долларов в год (и вы можете продолжать использовать его без поддержки или обновлений вечно) он довольно доступен для всех функций, которые он предлагает, и, конечно, прост в настройке.
WP Rocket поставляется с двумя настройками для устранения скриптов, блокирующих отображение: оптимизированная выдача CSS и отложенная загрузка JavaScript.
Чтобы включить их, перейдите в «Настройки — WP Rocket — Оптимизация файлов».
Включите две настройки, упомянутые выше, и все готово.
Пока вы здесь, вы также можете минимизировать свой Javascript и CSS для еще более быстрой загрузки.
W3 Total Cache
Этот последний плагин немного сложнее.
Вам потребуется вручную идентифицировать и заблокировать файлы, вызывающие ошибку блокировки отображения.
Если вы предпочитаете просто поставить галочку и все готово, вам следует попробовать WP Rocket или Autoptimize, но W3 Total Cache позволяет вам лучше контролировать, какие файлы нужно отложить.
Еще одно преимущество W3 Total Cache перед другими плагинами заключается в том, что он у вас, вероятно, уже установлен.
Это один из самых популярных плагинов для кеширования (и он должен быть в каждой установке WordPress), поэтому вам не придется загромождать свой сайт дополнительными аддонами.
После установки плагина первое, что вам нужно сделать, это вернуться на страницу результатов PageSpeed Insights.
В разделе «Устранение ресурсов, блокирующих отображение» вы должны увидеть список файлов Javascript и CSS, вызывающих проблему.
Держите страницу открытой, чтобы скопировать их позже.
Вернувшись в панель управления WordPress, перейдите в «Performance — Общие настройки» (Производительность — Общие настройки) и убедитесь, что функция «Minify» включена и установлена в ручной режим.
Теперь перейдите в «Performance — Minify».
В настройках минимизации JS в поле «Операции в областях» установите для параметра «Перед <head>» значение «Non-blocking using «defer».
Затем в разделе управления файлами JS щелкните «Добавить сценарий» и вставьте файлы Javascript из PageSpeed, которые вызывают проблемы, один за другим.
Затем прокрутите вниз до управления файлами CSS и нажмите «Добавить таблицу стилей».
Вставьте URL-адреса таблиц стилей, которые также вызывают проблемы.
После этого нажмите «Сохранить настройки и очистить кэш».
При правильной настройке ваш сайт теперь должен загружаться быстрее и получать более высокие баллы в PageSpeed.
Избавьтесь от ресурсов, блокирующих отображение в WordPress навсегда
Когда вы впервые сталкиваетесь с задачей избавиться от ресурсов, блокирующих отображение (и всего остального в ваших результатах PageSpeed!), попытка справиться со всем этим может оказаться непосильной задачей.
Но благодаря плагинам WordPress заблокировать проблемные скрипты очень просто.
Вам никогда не придется напрямую редактировать какой — либо код и рисковать сломать свой сайт.
Ресурсы, блокирующие отображение, если их оставить работать при каждой загрузке, могут нанести ущерб вашему времени загрузки.
Важно отложить несущественные Javascript и CSS, которые можно загрузить на потом.
Используйте такой инструмент, как PageSpeed Insights, чтобы определить, есть ли на вашем веб-сайте неоптимизированный код, а затем устраните проблему вручную или загрузив плагин.
Autoptimize и его родственный плагин AsyncJS — хорошие бесплатные варианты для начала.
Если у вас возникли проблемы с их настройкой или вы не замечаете никаких изменений, WP Rocket является премиальным, но предлагает поддержку и более быструю настройку.
W3 Total Cache труднее всего использовать, но определенно лучший выбор, если вы хотите индивидуально контролировать каждый файл, который хотите заблокировать.
Заключение
Если вы действительно серьезно относитесь к повышению производительности своего сайта, вам просто нужно приложить усилия, чтобы ваш сайт загружался быстрее.
В этом посте я показал, как устранить ресурсы, блокирующие отображение — Javascript и CSS.
Кроме того, я продвинулся дальше, чтобы показать вам два плагина, которые вы можете использовать для решения этой проблемы: W3 Total Cache и Autoptimize.
Скорость загрузки — один из многих факторов, влияющих на СЕО сайта.
Таким образом, сосредоточение внимания исключительно на нем и игнорирование других факторов может не дать вам желаемых результатов.
Каков был ваш показатель PageSpeed до и после оптимизации вашего сайта?
Расскажите нам в комментариях, какой большой толчок вы получили!
А у меня на этом все — до скорых встреч и берегите себя!
Оцените статью:
(+3 баллов, 3 оценок)
Загрузка…
Занимаюсь созданием сайтов на WordPress более 7 лет. Работал в нескольких веб-студиях, да и сейчас работаю. Иногда подрабатываю на фрилансе — как на нашем, так и на зарубежном. Везде зарекомендовал себя очень хорошо. Если нужен сайт на WordPress, шаблон для сайта или лендинг — не стесняйтесь, пишите. Рад буду помочь!
Чем быстрее человек сможет начать взаимодействие со страницей, тем выше вероятность, что он на ней останется. Персональные компьютеры отображают контент быстрее, а в мобильных устройствах на получение доступа к данным, зачастую уходит более 10 секунд. При этом, рекомендованное Google время отображения, при котором пользователь не потеряет интерес к странице, составляет 3 секунды. После этого начинается точка ухода.
Чтобы повысить конверсию, необходимо провести оптимизацию страницы. Другими словами — уменьшить время отрисовки. Для этого следует выполнить настройку загрузки критических ресурсов JS/CSS, отложив загрузку остальных. В данной статье мы разберём что это, зачем это нужно и как осуществить задуманное.
Что происходит при загрузке страницы
В тот момент, пока пользователь ожидает отображения информации на экране своего монитора, система активно работает. Пока не будут выполнены все шаги в определённой последовательности, информация не станет доступной. Вся эта цепочка, которая требуется для первичного отображения, имеет название Critical Rendering Path или Критический Путь Рендеринга. И без него обойтись невозможно.
Что происходит в этот момент физически. Вся информация на сайте зашифрована в HTML, JavaScript и CSS. Представить её пользователю в таком виде невозможно — он не будет читать скрипты, пытаясь получить нужные ему данные. Следовательно, система должна преобразовать их в фактические пиксели на экране. До того момента, пока этот процесс не будет завершён, человек будет наблюдать белый лист. И чем дольше это будет длиться, тем выше вероятность, что потенциальный потребитель просто покинет сайт. Это особенно критично для продающих ресурсов, так как каждый «юзер» — потенциальный покупатель и ему необходимо создать максимально комфортные условия.
Если ваша страница открывается не 3-5 секунд, а значительно дольше, стоит задуматься, а эффективно ли выполнены настройки её рендеринга. Чтобы от запроса до первой визуализации проходило как можно меньше времени, потребуется оптимизировать критические сценарии, за счёт которых и происходит первая отрисовка.
Что такое критический ресурс
PageSpeed Insights показывает не только скорость с которой страница загружается и с ней можно вступать во взаимодействие, но и даёт целый ряд рекомендаций. Их выполнение позволяет существенно ускорить загрузку ресурса, не потеряв при этом пользователей. Важно сделать это корректно, чтобы не произошло сбоев в других сценариях. Ссылки, которые тормозят или блокируют рендеринг, Lighthouse разделяет на 3 типа:
▪ Таблицы стилей
▪ Скрипты
▪ Импорт HTML
В ряде случаев, ресурсы будут иметь пометку «критический». Это значит, что данный ресурс необходим для первой отрисовки, либо же имеет решающее значение для основных функций страницы. Их необходимо оптимизировать в первую очередь. После этого, разработчиками проводятся мероприятия, которые позволяют провести их отсрочку, либо загрузку с минимальной потерей времени.
Что необходимо для оптимизации критического пути рендеринга
Все критические ресурсы, которые блокируют первоначальное отображение страницы выявлены. Появляются пути для их оптимизации. Это возможно достичь следующими инструментами:
▪ Сократив число критических ресурсов за счёт их откладывания
▪ Сократив критический путь, установив приоритеты по первоочередной загрузке контента
▪ Сократив число критических байтов, уменьшив размер файлов.
В первую очередь, необходимо сократить число критических ресурсов, отложив блокирующие рендеринг. При этом, потери файлов не происходит.
Как сократить критические сценарии и ссылки
Как мы выяснили выше, существует несколько типов ссылок, которые «ответственны» за блокировку рендеринга. В зависимости от каждого из них, оптимизацию необходимо проводить по определённому алгоритму.
▪ Для критических сценариев рассмотрите возможность их встраивания в ваш HTML. Для некритических сценариев рассмотрите возможность пометить их атрибутами async или defer.
▪ В отношении таблиц стилей, проанализируйте существует ли вероятность разделить стили на различные файлы, в зависимости от медиа-запросов. Следом потребуется добавить media атрибут в каждую из ссылок, которые указывают на таблицу. В процессе загрузки страницы, браузер проводит блокировку исключительно первой отрисовки таблиц стилей в соответствии с типом устройства пользователя.
▪ Что касается некритического импорта HTML, то его необходимо отметить атрибутом async. Важно, чтобы он на максимум использовал импорт HTML.
Чтобы определить код блокировки визуализации, то есть рендера, потребуется открыть вкладку «Покрытие» в Chrome DevTools. Она отображает критические и некритические JS, а также CSS (Рисунок 1).
Рисунок 1. Вкладка Покрытие
Какие типы ресурсов относятся к блокирующим
Существует всего три типа блокирующих ресурсов. К таковым относятся:
Тег <script> если он:
▪ Расположен в <head> файла
▪ Оснащён атрибутом отсрочки (defer)
▪ Не прописан асинхронный атрибут (async)
Тег <link rel = “stylesheet”>, в случае когда:
▪ Не предусмотрен отключённый атрибут (disabled). Если он предусмотрен, то часть браузеров не загружает таблицу стилей. Важно понимать, что данный атрибут поддерживают не все браузеры.
▪ Если нет атрибута media, который поддерживается гаджетом пользователя.
Тег <link rel = “import”>, если в нём:
▪ Нет асинхронного атрибута (async)
Стоит учитывать, что ряд плагинов могут «конфликтовать» между собой и потребуется вносить изменение в код. В противном случае, информация и изображения могут стать не читабельными и потребуется их полная перерисовка. Поэтому, перед внедрением того или иного изменения, потребуется его тестирование.
Проведение оптимизации позволит отображать имеющийся на сайте контент значительно быстрее. Тем самым, сокращается как визуальное, так и интуитивное восприятие загрузки страницы. Это, в свою очередь, увеличивает конверсию посетителей.
If you’ve ever run your WordPress site through Google PageSpeed Insights, Google has probably told you that you need to eliminate render-blocking resources on your WordPress site. In fact, that might be why you’re reading this very post right now.
That probably poses two questions in your mind:
- What are render-blocking resources in the first place?
- How can you eliminate render-blocking resources on WordPress?
In this post, we’re going to answer both questions for you. Here’s everything that we’ll cover in this post:
- What render-blocking resources are and why they’re a problem
- How to fix render-blocking resources in general
- How to use free or paid plugins to fix the problem on WordPress
Prefer to watch the video version?
What Does “Eliminate Render-Blocking Resources” Mean?
In order to understand what render-blocking resources are and why they hurt your site’s load times, we need to start with a basic look at how a web browser renders a web page.
When a visitor lands on your site, their web browser basically starts at the top of your site’s code and reads down. Top-to-bottom, got it?
If in that process, it encounters a CSS or JavaScript file, it needs to stop “reading” while it waits to download and process that file. The time that it spends “paused” to download and parse those resources could be spent on something much more productive, like loading the part of your website’s content that’s immediately visible when someone lands on the page.
Let’s look at an extreme example to show why this can be an issue.
Let’s say that you have this cool JavaScript effect in your site’s footer. It’s powered by “coolfooter.js”, which is a script that’s referenced at the top of your site’s code (even though the effect is in the footer, so visitors won’t see it until they scroll to the footer).
So a very rough layout for your site’s code might be something like:
- Header meta
- Coolfooter.js
- HTML for your above-the-fold content. This is all the content that a visitor sees right away (before they start interacting with the page)
And here’s why this is a problem:
When a visitor lands on your site, their browser starts reading from top-to-bottom. So before it can parse and render the HTML for the above-the-fold content on your site, it needs to wait to download and parse the coolfooter.js file.
End result? It takes longer to display the HTML for the above-the-fold content, which means that your visitors will perceive your site as being slower.
When Google tells you to eliminate render-blocking resources, it’s essentially saying, “hey, don’t load unnecessary resources at the top of your site’s code because it’s going to make it take longer for visitors’ browsers to download the visible part of your content”.
With the tips in this post, you’ll be able to wait to load certain CSS and JavaScript resources until the visible part of your page has already loaded.
What are Render-Blocking Resources?
When referring to render-blocking resources, we’re usually talking about:
- CSS
- JavaScript
It’s important to understand that not all CSS and JavaScript files are render-blocking.
For example, it’s important to load your critical CSS near the top, otherwise your visitors might experience what’s known as a flash of unstyled content (FOUC).
Are Images Render-Blocking Resources?
No, images are not render-blocking. It’s still important to optimize your images to reduce their file sizes, but you do not need to worry about optimizing the delivery path for your images.
How to Test If Your Website Has Render-Blocking Resources
To assess whether or not your WordPress site currently has render-blocking resources, you can use Google PageSpeed Insights.
All you do is enter the URL that you want to test. Then, if you have a problem with render-blocking resources, PageSpeed Insights will list each individual resource in the Eliminate render-blocking resources section under Opportunities:
How Do You Eliminate Render-Blocking Resources?
Don’t worry, you don’t have to do this manually. We’ll talk about WordPress plugins that can help you eliminate render-blocking resources in the next section.
However, it is helpful to understand what these plugins are doing behind the scenes to eliminate render-blocking resources.
How to Eliminate Render-Blocking JavaScript
There a few different strategies to eliminate render-blocking JavaScript. We cover these in detail in our article on how to defer parsing JavaScript, but here are the main methods:
- Async – lets the HTML parser (e.g. a visitor’s browser) download the JavaScript while still parsing the rest of the HTML. That is, it doesn’t completely stop parsing while the file downloads. However, it will pause the HTML parser to execute the script once it downloads.
- Defer – lets the HTML parser download the JavaScript while parsing the rest of the HTML and waits to execute the script until the HTML parsing is finished.
This illustration from Growing with the Web does a great job of showing the difference:
The benefit of using defer is that your scripts are guaranteed to execute in the order that they appear in the code.
Async does not use this approach, which can sometimes cause issues if you apply async to all JavaScript resources because it can often break resources that are dependent on resources that appear earlier in the document. The most common problem async produces is broken jQuery resources that try to load before jquery.js has been added to the document.
How to Eliminate Render-Blocking CSS
Eliminating render-blocking CSS can be a little trickier because you have to be careful not to delay CSS that is needed to render above-the-fold content. The ideal arrangement is to:
- Identify the styles that are required to render above-the-fold content and deliver those styles inline with the HTML.
- Use the media attribute on the link elements that pull in CSS files to identify CSS resources that are conditional, that is, only needed for specific devices or situations.
- Remaining CSS resources should be loaded asynchronously, a move that is typically done by adding them with deferred or asynchronous JavaScript.To be honest, we’re really getting in over our heads here, aren’t we? This is definitely frontend engineer territory. Which is great if you’re are a front-end engineer, but most of us aren’t. The good news is that this is an article about WordPress, and you can eliminate or at least significantly reduce the number of render-blocking JS and CSS resources affecting your site with the right plugin(s).
For another quick and easy way to boost your overall optimization, consider also minifying your code. Kinsta has built a code minification feature right into the MyKinsta dashboard, allowing customers to enable automatic CSS and JavaScript minification with a simple click.
If you are not able to locate the feature in your dashboard, simply check out our How to Enable Minification in MyKinsta video.
How to Eliminate Render-Blocking CSS and JavaScript Resources with WordPress Plugins
To demonstrate how to eliminate render-blocking resources on WordPress, we’ve set up a simple test site that includes render-blocking CSS and JavaScript and then we’ll take you through how to use two different plugin solutions to eliminate the render-blocking CSS and JavaScript:
- Autoptimize + Async JavaScript (free)
- WP Rocket (paid)
For reference, here’s what our test site looks like before optimizing CSS and JavaScript delivery:
If you’re testing the effectiveness of your changes with Google PageSpeed Insights, be aware that Google caches its results for several minutes. Essentially, this means that if you quickly…
- Test your unoptimized site
- Activate one of the plugins in this section
- Retest your site
…then you’ll still see the results for your unoptimized site until Google resets its cache. So make sure you wait a few minutes for Google to clear its cache before you think that the plugin isn’t working.
How to Eliminate Render-Blocking Resources with Autoptimize + Async JavaScript Plugin
Autoptimize and Async JavaScript are two separate free plugins from the same developer. Together, they help you optimize the delivery of both your CSS and JavaScript.
Once you’ve installed both plugins, go to Settings → Async JavaScript and:
- Check the box to Enable Async JavaScript at the top.
- Choose between Apply Async and Apply Defer in the Quick Settings box.
If the Async option causes problems on your site, we’d recommend trying Defer or excluding jQuery, which the plugin gives you an option for.
Once you’ve set up the Async JavaScript plugin, go to Settings → Autoptimize and:
- Check the box to Optimize JavaScript Code
- Check the box to Optimize CSS Code
If you’re an advanced user, you can play around with the additional JavaScript and CSS optimization settings, but most sites will be fine with the defaults.
After configuring Autoptimize and Async JavaScript, our test site passed PageSpeed Insights’ “Eliminate render-blocking resources” audit:
If you wanted to eliminate even more of those files, you could further use Autoptimize to manually inline your critical CSS. This requires some development knowledge, though, so it’s not something non-developers should try.
You can also use the plugins separately if preferred. But given that both plugins come from the same developer and are built to play nice with each other, the best approach for most sites is to combine them.
How to Eliminate Render-Blocking Resources with WP Rocket
WP Rocket is a popular premium WordPress performance and caching plugin.
Normally, we don’t allow caching plugins on WordPress sites hosted at Kinsta because we already handle caching for you at a server level via the speedy Nginx FastCGI cache.
However, WP Rocket has a special integration with Kinsta that lets WP Rocket play nice with your Kinsta caching. That’s great because WP Rocket does a lot more for WordPress performance than just caching, including helping you eliminate render-blocking CSS and JavaScript resources on your WordPress site.
Once you install and activate WP Rocket, go to the File Optimization tab. Then, enable these two options:
- Optimize CSS delivery under the CSS Files section
- Load JavaScript deferred under the JavaScript files section. You can experiment with turning the Safe Mode for jQuery off. But if you notice problems on the front-end of your site, you’ll want to re-enable safe mode for jQuery as it’s the likely culprit.
After activating these two features, our test site also passed the “eliminate render-blocking resources” audit in PageSpeed Insights. WP Rocket also managed to eliminate more render-blocking resources than the Autoptimize/Async JavaScript setup:
And that’s how to eliminate render-blocking resources on your WordPress website!
Want to get rid of render-blocking resources in #WordPress? It’s super easy with the right plugins… Check out how to tweak their settings and make your site faster! ⚙️🏃♀️Click to Tweet
Summary
Render-blocking resources slow down the perceived page load times of your WordPress site by forcing visitors’ browsers to delay rendering above-the-fold content while the browser downloads files that aren’t needed right away.
To help visitors load the visible portion of your page more quickly, you should delay loading resources that aren’t immediately required.
To eliminate render-blocking resources on WordPress, you can use off-the-rack plugins.
For a free solution, you can use the combination of Autoptimize and Async JavaScript, two plugins from the same developer.
If you’re willing to pay, you can use WP Rocket, which offers a special integration with Kinsta and can help with lots of other WordPress performance tweaks.
Do you have any additional questions about how to eliminate render-blocking resources on WordPress? Let us know in the comments!
Get all your applications, databases and WordPress sites online and under one roof. Our feature-packed, high-performance cloud platform includes:
- Easy setup and management in the MyKinsta dashboard
- 24/7 expert support
- The best Google Cloud Platform hardware and network, powered by Kubernetes for maximum scalability
- An enterprise-level Cloudflare integration for speed and security
- Global audience reach with up to 35 data centers and 275 PoPs worldwide
Test it yourself with $20 off your first month of Application Hosting or Database Hosting. Explore our plans or talk to sales to find your best fit.
If you’ve ever run your WordPress site through Google PageSpeed Insights, Google has probably told you that you need to eliminate render-blocking resources on your WordPress site. In fact, that might be why you’re reading this very post right now.
That probably poses two questions in your mind:
- What are render-blocking resources in the first place?
- How can you eliminate render-blocking resources on WordPress?
In this post, we’re going to answer both questions for you. Here’s everything that we’ll cover in this post:
- What render-blocking resources are and why they’re a problem
- How to fix render-blocking resources in general
- How to use free or paid plugins to fix the problem on WordPress
Prefer to watch the video version?
What Does “Eliminate Render-Blocking Resources” Mean?
In order to understand what render-blocking resources are and why they hurt your site’s load times, we need to start with a basic look at how a web browser renders a web page.
When a visitor lands on your site, their web browser basically starts at the top of your site’s code and reads down. Top-to-bottom, got it?
If in that process, it encounters a CSS or JavaScript file, it needs to stop “reading” while it waits to download and process that file. The time that it spends “paused” to download and parse those resources could be spent on something much more productive, like loading the part of your website’s content that’s immediately visible when someone lands on the page.
Let’s look at an extreme example to show why this can be an issue.
Let’s say that you have this cool JavaScript effect in your site’s footer. It’s powered by “coolfooter.js”, which is a script that’s referenced at the top of your site’s code (even though the effect is in the footer, so visitors won’t see it until they scroll to the footer).
So a very rough layout for your site’s code might be something like:
- Header meta
- Coolfooter.js
- HTML for your above-the-fold content. This is all the content that a visitor sees right away (before they start interacting with the page)
And here’s why this is a problem:
When a visitor lands on your site, their browser starts reading from top-to-bottom. So before it can parse and render the HTML for the above-the-fold content on your site, it needs to wait to download and parse the coolfooter.js file.
End result? It takes longer to display the HTML for the above-the-fold content, which means that your visitors will perceive your site as being slower.
When Google tells you to eliminate render-blocking resources, it’s essentially saying, “hey, don’t load unnecessary resources at the top of your site’s code because it’s going to make it take longer for visitors’ browsers to download the visible part of your content”.
With the tips in this post, you’ll be able to wait to load certain CSS and JavaScript resources until the visible part of your page has already loaded.
What are Render-Blocking Resources?
When referring to render-blocking resources, we’re usually talking about:
- CSS
- JavaScript
It’s important to understand that not all CSS and JavaScript files are render-blocking.
For example, it’s important to load your critical CSS near the top, otherwise your visitors might experience what’s known as a flash of unstyled content (FOUC).
Are Images Render-Blocking Resources?
No, images are not render-blocking. It’s still important to optimize your images to reduce their file sizes, but you do not need to worry about optimizing the delivery path for your images.
How to Test If Your Website Has Render-Blocking Resources
To assess whether or not your WordPress site currently has render-blocking resources, you can use Google PageSpeed Insights.
All you do is enter the URL that you want to test. Then, if you have a problem with render-blocking resources, PageSpeed Insights will list each individual resource in the Eliminate render-blocking resources section under Opportunities:
How Do You Eliminate Render-Blocking Resources?
Don’t worry, you don’t have to do this manually. We’ll talk about WordPress plugins that can help you eliminate render-blocking resources in the next section.
However, it is helpful to understand what these plugins are doing behind the scenes to eliminate render-blocking resources.
How to Eliminate Render-Blocking JavaScript
There a few different strategies to eliminate render-blocking JavaScript. We cover these in detail in our article on how to defer parsing JavaScript, but here are the main methods:
- Async – lets the HTML parser (e.g. a visitor’s browser) download the JavaScript while still parsing the rest of the HTML. That is, it doesn’t completely stop parsing while the file downloads. However, it will pause the HTML parser to execute the script once it downloads.
- Defer – lets the HTML parser download the JavaScript while parsing the rest of the HTML and waits to execute the script until the HTML parsing is finished.
This illustration from Growing with the Web does a great job of showing the difference:
The benefit of using defer is that your scripts are guaranteed to execute in the order that they appear in the code.
Async does not use this approach, which can sometimes cause issues if you apply async to all JavaScript resources because it can often break resources that are dependent on resources that appear earlier in the document. The most common problem async produces is broken jQuery resources that try to load before jquery.js has been added to the document.
How to Eliminate Render-Blocking CSS
Eliminating render-blocking CSS can be a little trickier because you have to be careful not to delay CSS that is needed to render above-the-fold content. The ideal arrangement is to:
- Identify the styles that are required to render above-the-fold content and deliver those styles inline with the HTML.
- Use the media attribute on the link elements that pull in CSS files to identify CSS resources that are conditional, that is, only needed for specific devices or situations.
- Remaining CSS resources should be loaded asynchronously, a move that is typically done by adding them with deferred or asynchronous JavaScript.To be honest, we’re really getting in over our heads here, aren’t we? This is definitely frontend engineer territory. Which is great if you’re are a front-end engineer, but most of us aren’t. The good news is that this is an article about WordPress, and you can eliminate or at least significantly reduce the number of render-blocking JS and CSS resources affecting your site with the right plugin(s).
For another quick and easy way to boost your overall optimization, consider also minifying your code. Kinsta has built a code minification feature right into the MyKinsta dashboard, allowing customers to enable automatic CSS and JavaScript minification with a simple click.
If you are not able to locate the feature in your dashboard, simply check out our How to Enable Minification in MyKinsta video.
How to Eliminate Render-Blocking CSS and JavaScript Resources with WordPress Plugins
To demonstrate how to eliminate render-blocking resources on WordPress, we’ve set up a simple test site that includes render-blocking CSS and JavaScript and then we’ll take you through how to use two different plugin solutions to eliminate the render-blocking CSS and JavaScript:
- Autoptimize + Async JavaScript (free)
- WP Rocket (paid)
For reference, here’s what our test site looks like before optimizing CSS and JavaScript delivery:
If you’re testing the effectiveness of your changes with Google PageSpeed Insights, be aware that Google caches its results for several minutes. Essentially, this means that if you quickly…
- Test your unoptimized site
- Activate one of the plugins in this section
- Retest your site
…then you’ll still see the results for your unoptimized site until Google resets its cache. So make sure you wait a few minutes for Google to clear its cache before you think that the plugin isn’t working.
How to Eliminate Render-Blocking Resources with Autoptimize + Async JavaScript Plugin
Autoptimize and Async JavaScript are two separate free plugins from the same developer. Together, they help you optimize the delivery of both your CSS and JavaScript.
Once you’ve installed both plugins, go to Settings → Async JavaScript and:
- Check the box to Enable Async JavaScript at the top.
- Choose between Apply Async and Apply Defer in the Quick Settings box.
If the Async option causes problems on your site, we’d recommend trying Defer or excluding jQuery, which the plugin gives you an option for.
Once you’ve set up the Async JavaScript plugin, go to Settings → Autoptimize and:
- Check the box to Optimize JavaScript Code
- Check the box to Optimize CSS Code
If you’re an advanced user, you can play around with the additional JavaScript and CSS optimization settings, but most sites will be fine with the defaults.
After configuring Autoptimize and Async JavaScript, our test site passed PageSpeed Insights’ “Eliminate render-blocking resources” audit:
If you wanted to eliminate even more of those files, you could further use Autoptimize to manually inline your critical CSS. This requires some development knowledge, though, so it’s not something non-developers should try.
You can also use the plugins separately if preferred. But given that both plugins come from the same developer and are built to play nice with each other, the best approach for most sites is to combine them.
How to Eliminate Render-Blocking Resources with WP Rocket
WP Rocket is a popular premium WordPress performance and caching plugin.
Normally, we don’t allow caching plugins on WordPress sites hosted at Kinsta because we already handle caching for you at a server level via the speedy Nginx FastCGI cache.
However, WP Rocket has a special integration with Kinsta that lets WP Rocket play nice with your Kinsta caching. That’s great because WP Rocket does a lot more for WordPress performance than just caching, including helping you eliminate render-blocking CSS and JavaScript resources on your WordPress site.
Once you install and activate WP Rocket, go to the File Optimization tab. Then, enable these two options:
- Optimize CSS delivery under the CSS Files section
- Load JavaScript deferred under the JavaScript files section. You can experiment with turning the Safe Mode for jQuery off. But if you notice problems on the front-end of your site, you’ll want to re-enable safe mode for jQuery as it’s the likely culprit.
After activating these two features, our test site also passed the “eliminate render-blocking resources” audit in PageSpeed Insights. WP Rocket also managed to eliminate more render-blocking resources than the Autoptimize/Async JavaScript setup:
And that’s how to eliminate render-blocking resources on your WordPress website!
Want to get rid of render-blocking resources in #WordPress? It’s super easy with the right plugins… Check out how to tweak their settings and make your site faster! ⚙️🏃♀️Click to Tweet
Summary
Render-blocking resources slow down the perceived page load times of your WordPress site by forcing visitors’ browsers to delay rendering above-the-fold content while the browser downloads files that aren’t needed right away.
To help visitors load the visible portion of your page more quickly, you should delay loading resources that aren’t immediately required.
To eliminate render-blocking resources on WordPress, you can use off-the-rack plugins.
For a free solution, you can use the combination of Autoptimize and Async JavaScript, two plugins from the same developer.
If you’re willing to pay, you can use WP Rocket, which offers a special integration with Kinsta and can help with lots of other WordPress performance tweaks.
Do you have any additional questions about how to eliminate render-blocking resources on WordPress? Let us know in the comments!
Get all your applications, databases and WordPress sites online and under one roof. Our feature-packed, high-performance cloud platform includes:
- Easy setup and management in the MyKinsta dashboard
- 24/7 expert support
- The best Google Cloud Platform hardware and network, powered by Kubernetes for maximum scalability
- An enterprise-level Cloudflare integration for speed and security
- Global audience reach with up to 35 data centers and 275 PoPs worldwide
Test it yourself with $20 off your first month of Application Hosting or Database Hosting. Explore our plans or talk to sales to find your best fit.
В разделе Opportunities (Возможности) отчета Lighthouse перечислены все URL-адреса, блокирующие первую отрисовку страницы. Цель: уменьшить влияние URL-адресов, блокирующих рендеринг, путем встраивания критических ресурсов, отсрочки загрузки некритических ресурсов и удаления всего неиспользуемого.
Какие URL-адреса помечаются как ресурсы, блокирующие рендеринг?
Lighthouse отмечает два типа URL-адресов, блокирующих рендеринг: скрипты и таблицы стилей.
Скрипт <script> помечается, если он:
- Находится в
<head>документа. - Не имеет атрибута
defer. - Не имеет атрибута
async.
Таблица стилей <link rel="stylesheet"> помечается, если она:
- Не имеет атрибута
disabled. Если этот атрибут присутствует, браузер не загружает таблицу стилей. - Не имеет атрибута
media, который соответствует конкретному устройству пользователя.media="all"считается блокирующим рендеринг.
Как определить критические ресурсы
Первый шаг к уменьшению воздействия ресурсов, блокирующих рендеринг, — это определить, что критично, а что нет. Используйте вкладку Coverage в Chrome DevTools, чтобы определить некритический код CSS и JS. Когда вы загружаете или запускаете страницу, вкладка показывает, какое количество кода из всего загруженного реально использовалось.
Вы можете уменьшить размер своих страниц, отправляя только тот код и стили, которые вам нужны. Щелкните URL-адрес, чтобы просмотреть этот файл на панели Sources (Источники). Стили в файлах CSS и код в файлах JavaScript отмечены двумя цветами:
- зеленый (критический): стили, необходимые для первой отрисовки; код, который важен для основных функций страницы;
- красный (некритический): стили, применяемые к контенту, который не виден сразу; код, неиспользуемый в основных функциях страницы.
Как избавиться от скриптов, блокирующих рендеринг
Как только вы определили критический код, переместите этот код из URL-адреса, блокирующего рендеринг, во встроенный тег script на вашей HTML-странице. Теперь во время загрузки у страницы будет всё необходимое для обработки основных функций.
Если в URL-адресе, блокирующем рендеринг, есть код, который не является критическим, вы можете сохранить его в URL-адресе, а затем пометить URL-адрес атрибутами async или defer (см. также статью «Добавление интерактивности с помощью JavaScript»).
Код, который вообще не используется, следует удалить (см. статью «Удалите неиспользуемый код»).
Как избавиться от таблиц стилей, блокирующих рендеринг
Используйте прием, аналогичный переносу критического кода во встроенный тег <script>, встройте критические стили, необходимые для первой отрисовки, в блок <style> элемента head HTML-страницы. Затем асинхронно загрузите остальные стили, используя ссылку preload (см. статью «Отложите загрузку неиспользуемого CSS»).
Подумайте об автоматизации процесса извлечения и встраивания CSS верхней половины полосы с помощью инструмента Critical.
Другой подход к устранению стилей, блокирующих рендеринг, — это разделить эти стили на разные файлы, организованные по медиа-запросам. Затем добавьте атрибут media к каждой ссылке таблицы стилей. При загрузке страницы браузер блокирует только первую отрисовку, чтобы получить таблицы стилей, соответствующие устройству пользователя (см. статью «Блокирующий рендеринг CSS»).
Наконец, вы захотите выполнить минификацию CSS-кода, чтобы удалить лишние пробелы или символы (см. статью «Выполните минификацию CSS-кода»). Это гарантирует, что вы отправите пользователям минимально возможный бандл.
Рекомендации по стекам
AMP
Используйте такие инструменты, как AMP-оптимизатор, для рендеринга макетов AMP на стороне сервера.
Drupal
Подумайте об использовании модуля для встраивания критического кода CSS и JavaScript или о потенциальной асинхронной загрузке ресурсов через JavaScript, например, с помощью модуля Advanced CSS/JS Aggregation.
Joomla
Существует ряд плагинов Joomla, которые могут помочь вам встроить критические ресурсы или отложить загрузку менее важных ресурсов.
WordPress
Существует ряд плагинов WordPress, которые могут помочь вам встроить критические ресурсы или отложить загрузку менее важных ресурсов.
Ресурсы
- Исходный код проверки Eliminate render-blocking resources (Устраните ресурсы, блокирующие рендеринг).
- Сократите полезную нагрузку JavaScript за счет разделения кода.
- Удалите неиспользуемый код (codelab).
- Оптимизация загрузки JavaScript.
От автора: я все время думала, что вопрос, когда и как загружать CSS-файлы, лучше оставить самому браузеру. Браузеры спроектированы для работы с такими вещами. Зачем разработчикам что-то делать, если можно просто добавить ссылку с rel=»stylesheet» и href=»style.css» в head документа и забыть?
По-видимому, сегодня этого уже не достаточно, по крайней мере, если вы думаете о скорости сайта и быстром рендеринге страниц. Учитывая, как эти два фактора влияют на UX и успех сайта, скорее всего, вы уже искали способы контролировать метод загрузки стилей в браузере по умолчанию.
В этой статье я расскажу о том, что может пойти не так, когда браузеры загружают CSS-файлы, а также мы обсудим возможные подходы к проблеме, которые вы испытаете на своем сайте.
Проблема: CSS блокирует рендеринг
Если вы хоть раз пользовались Google Page Speed Insights для проверки производительности сайта, вы должны были встречать сообщения подобного содержания:
JavaScript. Быстрый старт
Изучите основы JavaScript на практическом примере по созданию веб-приложения
Узнать подробнее
Google Page Insights описывает проблему и предлагает стратегию ее решения.
Сначала давайте попробуем лучше понять суть проблемы.
Для отображения веб-страниц браузеры используют DOM (Document Object Model) и CSSOM (CSS Object Model). DOM – модель HTML, необходимая браузеру для рендеринга структуры страницы и ее контента. CSSOM – карта CSS, которую использует браузер для стилизации веб-страниц.
CSS является частью критического пути рендеринга, т.е. браузер тормозит рендеринг веб-страницы до тех пор, пока не загрузятся и обработаются все HTML и CSS файлы. Это объясняет, почему HTML и CSS файлы считаются блокирующими рендеринг файлами. Внешние стили включают в себя многократные запросы туда-обратно между браузером и сервером. Это может вызывать задержку между временем загрузки HTML и временем рендеринга страницы на экран.
Проблема заключается в этой задержке, когда пользователь смотрит на пустой экран несколько миллисекунд. Не самый лучший опыт от первого посещения сайта.
Концепция критического CSS
С одной стороны, HTML в первую очередь влияет на рендеринг страницы, но в противном случае вообще нечего было бы рендерить. Можно ли то же самое сказать про CSS?
Конечно, страница без стилей совсем не user friendly, а значит, браузеру нужно подождать загрузки и парсинга CSS перед рендерингом страницы. С другой стороны, можно сказать, что не все стили критичны для построения нормальной страницы. В первую очередь пользователей интересует верхняя часть страницы, видимая на экране после загрузки без прокрутки.
За этой мыслью кроется доминирующий на сегодня подход по решению нашей проблемы и предложения из сообщения Google Page Insights. Что нас интересует: «Попробуйте отложить загрузку блокирующих ресурсов или делайте это асинхронно, или же встройте критические части ресурсов напрямую в HTML.»
Но как отложить загрузку стилей на странице или сделать ее асинхронной?
Все не так просто, как может звучать. Здесь не получится добавить атрибут toss к тегу link, как это можно было в script.
Ниже описано несколько методов, которыми разработчики решают эту задачу.
Используйте медиа типы и медиа запросы для минимизации блокировок рендеринга
Ilya Grigorik иллюстрирует простой способ минимизации блокировок рендеринга страницы, который делится на два этапа:
необходимо разбить внешний CSS на несколько файлов по медиа типам и медиа запросам, тем самым избегая загрузки больших CSS-документов;
необходимо ссылаться на все файлы с подходящим медиа типом и медиа запросом внутри тега link. Это предотвращает блокировку некоторых файлов стилей, если не соблюдаются условия медиа типа и медиа запроса.
Как пример, ссылки на внешние CSS-файлы в head документа могут выглядеть так:
|
<link href=«style.css» rel=«stylesheet»> <link href=«print.css» rel=«stylesheet» media=«print»> <link href=«other.css» rel=«stylesheet» media=«(min-width: 40em)»> |
Первая ссылка в коде сверху не использует медиа тип и медиа запрос. Браузер считает, что она удовлетворяет всем кейсам, поэтому она всегда блокирует рендеринг страницы на время загрузки и обработки.
У второй ссылки есть атрибут media=»print», который говорит браузеру: «привет, браузер, смотри, чтобы этот файл стилей применялся только, если страница уходит на печать». При обычном просмотре страницы на экране браузер понимает, что этот файл стилей ему не нужен, и рендеринг не блокируется.
В третьей ссылке есть media=»(min-width: 40em)», что значит, что стили в ссылке блокируют рендеринг только, если соблюдено условие медиа запроса. То есть когда ширина вьюпорта равна минимум 40em. Во всех остальных случаях ресурс не блокирует рендеринг.
Также учтите, что браузер всегда будет загружать все стили, но не блокирующим стилям он будет отдавать более низкий приоритет.
Вывод: подход не полностью устраняет проблему, но может значительно минимизировать время блокировок рендеринга страниц.
Используйте директиву preload на теге link
Самый новый способ противостояния блокировкам страниц в браузере при загрузке внешних стилей – стандартизированная директива preload. С помощью preload мы-разработчики можем сказать браузерам загружать определенные ресурсы, потому что мы знаем, что они понадобятся в скором времени.
Scott Jehl, дизайнер и разработчик из The Filament Group, первый придумал этот способ. Что нужно делать. Добавьте preload в ссылку стилей и вставьте немного JS-магии с помощью события onload. Результат – асинхронная загрузка стилей прямо в разметку:
|
<link rel=«preload» as=«style» href=«style.css» onload=«this.rel=’stylesheet'»> |
Код выше дает браузеру возможность скачать style.css, не блокируя рендеринг. Как только ресурс загрузится, т.е. сработает событие onload, скрипт заменит значение preload атрибута rel на stylesheet и применит стили на странице.
В настоящее время поддержка preload ограничена Chrome и Opera. Но не бойтесь, Filament Group разработали полифил. Более подробно в следующей секции.
JavaScript. Быстрый старт
Изучите основы JavaScript на практическом примере по созданию веб-приложения
Узнать подробнее
Решение от Filament Group: от инлайнового CSS к HTTP/2 Server Push
Filament Group на протяжении долгого времени отдавали решению проблемы блокирования рендеринга из-за загрузки критических ресурсов наивысший приоритет. Filament Group – отмеченное наградами агентство по дизайну и разработке из Бостона: «Наш главный приоритет – работа с HTML, готовым для рендеринга сразу после загрузки в браузере.»
Последнее обновление по оптимизации загрузки страниц подчеркнуло их прогресс от инлайнового критического CSS до суперэффективного HTTP/2 Server Push. Общая стратегия:
любой критический для рендеринга первой видимой части страницы файл должен быть включен в HTML-ответ от сервера;
любой некритичный для рендеринга первой видимой части страницы файл должен загружаться асинхронно без блокировки рендеринга
До HTTP/2 Server Push была первая версия метода. В первой версии нужно было выбрать критические CSS-правила, т.е. те правила, которые нужны для плавного рендеринга верхней видимой части страницы и стили по умолчанию, после чего вставить их в тег style внутрь head на странице. Разработчики Filament Group написали Critical, крутой JS-плагин, автоматизирующий задачу извлечения критического CSS.
С принятием HTTP/2 Server Push Filament Group стали работать не только над инлайновыми критическими стилями.
Что такое Server Push? Для чего он нужен?
«Server push позволяет посылать пользователю файлы с сайта еще до того, как он их попросит. …Server push позволяет серверу превентивно «толкать» файлы сайта в клиент без явного запроса со стороны пользователя. При правильном подходе мы можем посылать пользователю файлы, которые, как мы точно знаем, ему понадобятся для запрошенной страницы. Jeremy Wagner»
Другими словами, когда браузер запрашивает определенную страницу, например, index.html, все файлы, от которых зависит эта страница, будут включены в ответ (style.css, main.js и т.д.), давая огромное ускорение при рендеринге страницы.
Разберем на практике способ №2 (асинхронную загрузку некритического CSS). Здесь используется комбинация preload из предыдущей техники и LoadCSS, JS-библиотеки от Filament Group, которая включает полифил для браузеров без поддержки preload.
Для работы с LoadCSS необходимо включить этот код в head:
|
<link rel=«preload» href=«mystylesheet.css» as=«style» onload=«this.rel=’stylesheet'»> <!— for browsers without JavaScript enabled —> <noscript><link rel=«stylesheet» href=«mystylesheet.css»> </noscript> |
Обратите внимание на noscript. Внутри этого тега подключается файл стилей, как обычно. Этот блок обрабатывает ситуации, когда JS не сработал или был отключен.
Под noscript подключите LoadCSS и LoadCSS rel=preload polyfill script в теге script:
|
<script> /*! loadCSS. [c]2017 Filament Group, Inc. MIT License */ (function(){ ... }()); /*! loadCSS rel=preload polyfill. [c]2017 Filament Group, Inc. MIT License */ (function(){ ... }()); </script> |
Детальную инструкцию по использованию LoadCSS можно найти на странице репозитория проекта на GitHub, а увидеть вживую в демо.
Я изучал этот подход: в нем используется техника прогрессивного улучшения, и он чистый и понятный для разработчиков.
Разместите ссылку на файлы стилей внутри body документа
По словам Jake Archibald у предыдущего метода есть минус – он основывается на главном предположении, что вы или я считаем критическим CSS. Очевидно, что все стили, применяемые к верхней видимой части страницы, критичны. Тем не менее, мы почти точно можем определить первую видимую часть страницы после загрузки. «Почти» потому, что при изменении размеров вьюпорта, изменяется объем контента, видимый пользователю без прокрутки страницы. Поэтому «один размер подо все» не всегда надежно.
Jake Archibald предлагает другое решение:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
<head> </head> <body> <!— HTTP/2 push this resource, or inline it —> <link rel=«stylesheet» href=«/site-header.css»> <header>…</header> <link rel=«stylesheet» href=«/article.css»> <main>…</main> <link rel=«stylesheet» href=«/comment.css»> <section class=«comments»>…</section> <link rel=«stylesheet» href=«/about-me.css»> <section class=«about-me»>…</section> <link rel=«stylesheet» href=«/site-footer.css»> <footer>…</footer> </body> |
Как видите, ссылки на внешние стили размещены не в , а внутри body документа.
Более того, стили, отображаемые сразу на странице, будь-то инлайновые или HTTP/2 Server Push – это стили, применяемые к верхней части страницы. Все остальные внешние стили помещаются прямо перед HTML-контентом, к которому они применяются: article.css перед main, site-footer.css перед footer и т.д.
Чего пытается достичь данная техника: «План – для каждого link rel=”stylesheet” блокировать рендеринг последующего контента на время загрузки стилей, но разрешать рендеринг контента перед этим тегом. Стили загружаются параллельно, но применяются последовательно. … Так вы получаете страницу с последовательным рендерингом. Вам не нужно вычислять «верхнюю часть страницы», просто подключите CSS для компонента страницы прямо перед первым появлением этого компонента.»
Все браузеры разрешают вставлять тег link внутри body, но не все браузеры ведут себя одинаково. Тем не менее, в большинстве браузеров эта техника решает поставленную задачу.
Все детали можно узнать в посте Jake Archibald, а результат посмотреть в демо.
Заключение
Проблема с тем, как браузеры загружают стили, заключается в том, что рендеринг страницы блокируется до тех пор, пока не будут загружены все файлы. Таким образом, при первом посещении сайта страдает UX, особенно у людей со слабым соединением.
В этой статье я показала несколько подходов решения этой проблемы. Не думаю, что маленькие сайты с относительно небольшим структурированным CSS будут сильно страдать, если оставят загрузку стилей в браузере самому устройству.
А что вы думаете, улучшает ли ленивая загрузка стилей или их последовательное применение (подход Jake Archibald) скорость рендеринга сайта? Какая техника самая эффективная? Пишите в комментариях.
Редакция: Maria Antonietta Perna
Источник: //www.sitepoint.com/
Редакция: Команда webformyself.
JavaScript. Быстрый старт
Изучите основы JavaScript на практическом примере по созданию веб-приложения
Узнать подробнее
CSS3. Основы
Прямо сейчас изучите CSS3 с нуля!
Смотреть
Минимизируйте работу в основном потоке
Рекомендуем сократить время на анализ, компиляцию и выполнение скриптов JS. Для этого вы можете уменьшить размер фрагментов кода JS.
Устраните ресурсы, блокирующие отображение
Некоторые ресурсы блокируют первую отрисовку страницы. Рекомендуем встроить критическую часть данных JS/CSS в код HTML и отложить загрузку остальных ресурсов.
Удалите неиспользуемый код JavaScript
Чтобы сократить расход трафика, удалите неиспользуемый код JavaScript и отложите загрузку скриптов до тех пор, пока они не понадобятся.
Удалите неиспользуемый код CSS
Чтобы сократить расход трафика, удалите ненужные правила из таблиц стилей и отложите загрузку кода CSS, который не используется в видимой части страницы.
Настройте показ всего текста во время загрузки веб-шрифтов
Используйте свойство CSS font-display, чтобы пользователи могли видеть текст во время загрузки веб-шрифтов.
Уменьшите влияние стороннего кода
Сторонний код может сильно замедлить загрузку страниц сайта. Рекомендуем использовать только самые необходимые сторонние ресурсы и сделать так, чтобы они загружались в последнюю очередь.
Задайте правила эффективного использования кеша для статических объектов
Благодаря долгому времени хранения кеша страница может быстрее загружаться при повторных посещениях.
Сократите время выполнения кода JavaScript
Рекомендуем сократить время на анализ, компиляцию и выполнение скриптов JS. Для этого вы можете уменьшить размер фрагментов кода JS.
Настройте эффективную кодировку изображений
Оптимизированные изображения загружаются быстрее и меньше расходуют мобильный трафик
Используйте современные форматы изображений
Форматы WebP и AVIF обеспечивают более эффективное сжатие по сравнению с PNG или JPEG, поэтому такие изображения загружаются быстрее и потребляют меньше трафика.