01Що це таке та як це працює
Коли браузер завантажує сторінку, він будує DOM з HTML та CSSOM зі таблиць стилів. Якщо тег ` знаходиться в без атрибутів defer або async, браузер припиняє парсинг HTML, щоб завантажити та виконати його. Подібним чином ` блокує рендеринг, оскільки браузеру потрібен CSSOM для відмальовування. Чим більше у вас Render-blocking resources, тим довше користувач дивиться на порожній екран. Google Lighthouse позначає ці ресурси та вимірює їхній вплив на First Contentful Paint (FCP) та Largest Contentful Paint (LCP).
Render-blocking resources — це скрипти та таблиці стилів, які заважають браузеру показувати контент, доки вони не завантажаться. Видалення або відкладення їхнього завантаження пришвидшує роботу сторінок.
02Що з цим робити
Ви можете зменшити або усунути Render-blocking resources за допомогою кількох практичних кроків. Вбудовуйте критичний CSS — стилі, необхідні для контенту над лінією згину — безпосередньо в `. Завантажуйте некритичний CSS за допомогою атрибутів media або preload з onload. Для JavaScript додавайте defer або async до тегів або переміщуйте скрипти в кінець `. Розділяйте ваші JavaScript-пакети так, щоб спочатку завантажувався лише основний код. Використовуйте такі інструменти, як Lighthouse або PageSpeed Insights, щоб визначити, які ресурси блокують рендеринг, а потім застосуйте ці виправлення. Для WordPress розгляньте можливість використання плагіна для продуктивності, який автоматично обробляє критичний CSS та відкладення скриптів.
03Як це вимірюється
Lighthouse та PageSpeed Insights надають спеціальний аудит під назвою "Eliminate render-blocking resources". Він перелічує кожну блокуючу URL-адресу та приблизний час, який вдалося заощадити завдяки її відкладенню або вбудовуванню. Цей показник пов'язаний із FCP та LCP у Core Web Vitals. Ви також можете використовувати панель Performance у Chrome DevTools: запишіть завантаження сторінки, перегляньте трек "Main" і подивіться, де браузер зупиняється на таблиці стилів або скрипті. Вкладка Network показує, які ресурси запитуються перед подією першої мальовнистої дії (first paint). Звіт Core Web Vitals у Google Search Console позначить сторінки з поганим LCP, що часто спричинено скриптами, які блокують рендеринг.
04Поширені помилки
- Відкладення всього JavaScript, включаючи скрипти, які мають виконуватися до того, як сторінка стане інтерактивною, — це затримує час до інтерактивності (time-to-interactive).
- Вбудовування величезних CSS-файлів, що збільшує розмір HTML і може погіршити продуктивність на повільному з'єднанні.
- Використання
asyncдля скриптів, які залежать від інших скриптів, що спричиняє стан гонитви та порушення функціональності. - Невидалення невикористовуваного CSS або JavaScript — зайвий код все одно блокує рендеринг.
- Попереднє завантаження всіх ресурсів замість лише критично важливих, що витрачає пропускну здатність і затримує справді критичні активи.
05Обмеження та плутанина
Не всі ресурси є render-blocking. Зображення, відео та шрифти, завантажені через ` або @font-face, не блокують рендеринг (хоча вони впливають на LCP). Скрипти з async або defer` не блокують парсинг. Також render-blocking — це не те саме, що "затримка рендерингу" — велике зображення може затримувати LCP, не блокуючи перший рендеринг (first paint). І ресурс може бути позначений як render-blocking, але мати мінімальний вплив, якщо він малий або закешований. Оцінка економії часу в аудиті — це найкращий сценарій, а не гарантія. Зрештою, render-blocking resources — це проблема продуктивності, а не прямий фактор ранжування — вони опосередковано впливають на позиції через Core Web Vitals.
06Приклад роботи
Припустимо, ваша головна сторінка має<link rel="stylesheet" href="styles.css">та<script src="app.js"></script>у<head>. Lighthouse каже, що styles.css економить 0,8 с, а app.js економить 0,5 с, якщо використати відкладене завантаження. Ви вбудовуєте критичний CSS (стилі заголовка та першого екрана) у тег<style>, а потім завантажуєте решту styles.css за допомогоюmedia="print" onload="this.media='all'". Ви додаєтеdeferдо app.js. Після змін FCP зменшується з 2,1 с до 1,3 с, а ваш LCP покращується з 3,4 с до 2,2 с. Тепер сторінка відповідає порогу Core Web Vitals для мобільних пристроїв.
07Поширені запитання
Яка різниця між render-blocking та non-render-blocking ресурсами?
Render-blocking resources мають бути завантажені та розпарсено до того, як браузер зможе виконати рендеринг, тоді як non-render-blocking resources, такі як зображення або асинхронні скрипти, не затримують першу відмальовку. Ключова відмінність полягає в тому, чи призупиняє браузер рендеринг під час завантаження ресурсу. На практиці CSS часто є render-blocking, тоді як JavaScript можна зробити non-render-blocking за допомогою async або defer.
Чи варто мені усунути всі render-blocking resources?
Ні, не всі. Вам слід усунути або відкласти ресурси, які не є критичними для початкового контенту, як-от необов'язковий JavaScript, але деякий CSS необхідний для стилізації сторінки. Мета полягає в тому, щоб вбудувати критичний CSS і відкласти решту, балансуючи швидкість із функціональністю.
Як мені вбудувати render-blocking JavaScript?
Ви не вбудовуєте JavaScript безпосередньо; натомість ви завантажуєте його за допомогою атрибута defer або використовуєте async, де це доречно. Для CSS ви можете вбудувати критичні стилі прямо в HTML і відкласти решту за допомогою media="print" або методів попереднього завантаження (preload). Такі інструменти, як Lighthouse, надають конкретні рекомендації для кожної URL-адреси, що блокує рендеринг.
Чи покращує виправлення Render-blocking resources мої позиції в пошуку?
Так, опосередковано. Render-blocking resources затримують показ першого контенту (first contentful paint), що є показником Core Web Vital, який Google використовує як фактор ранжування. Їх зменшення покращує швидкість завантаження сторінки та може підвищити ваші позиції, особливо на мобільних пристроях. Проте це лише один із багатьох факторів, тому вплив може бути різним.
Що станеться, якщо я не виправлю Render-blocking resources?
Ваша сторінка матиме повільніший перший показ (first paint), що призведе до вищого показника відмов і гіршого користувацького досвіду. З часом це може зашкодити вашим позиціям у пошуку та погіршити результати аудитів продуктивності вашого сайту. Ви також побачите низькі бали в Lighthouse, що може викликати занепокоєння у клієнтів або стейкхолдерів.
Скільки часу потрібно, щоб побачити покращення після виправлення Render-blocking resources?
Ви побачите миттєві покращення у ваших показниках Lighthouse та PageSpeed Insights, щойно впровадите зміни. Щодо позицій у пошуку, це залежить від того, як часто Google сканує ваш сайт, але ви можете помітити зміни протягом кількох тижнів. Стежте за своїми показниками Core Web Vitals у Google Search Console, щоб відстежувати прогрес.
08Як про це питають уголос
Той самий термін словами, якими про нього питають асистента, а не набирають у рядку пошуку — написано із ситуації, тому кожне питання несе ту ситуацію, з якої виникло.
Ймовірно, це render-blocking resources. Це такі файли, як CSS та JavaScript, які браузер має завантажити, перш ніж зможе відобразити сторінку. Ви можете виправити це, вбудовуючи критичний CSS (inlining) та відкладаючи виконання несуттєвих скриптів (deferring).
Це аудит render-blocking resources. У ньому перелічені конкретні URL, які уповільнюють ваше перше відображення (first paint). Ви можете виправити це, відклавши ці скрипти або вбудувавши критичний CSS, а звіт навіть показує, скільки часу ви заощадите.
Спочатку перевірте на наявність render-blocking resources. Це найпоширеніша причина повільного першого відображення, і це легко виправити. Запустіть тест PageSpeed і подивіться аудит "Eliminate render-blocking resources", щоб побачити, що саме гальмує сторінку.