Render-blocking ресурсы

Как работает

Когда браузер строит страницу, он останавливается на некоторых ресурсах. По умолчанию внешний CSS блокирует отрисовку: браузер не покажет контент, пока не загрузит и не разберёт все стили, иначе страница мелькнула бы без оформления. Синхронный JavaScript в <head> блокирует ещё и разбор HTML — браузер обязан выполнить скрипт, прежде чем продолжить.

<head>
  <!-- блокирует отрисовку -->
  <link rel="stylesheet" href="/style.css">
  <script src="/app.js"></script>

  <!-- не блокирует разбор HTML -->
  <script src="/analytics.js" defer></script>
</head>

Атрибут defer откладывает выполнение скрипта до конца разбора HTML, async — выполняет по готовности не блокируя парсинг. Для стилей используют разделение на критические и остальные, отложенную загрузку и preload.

Порядок тоже имеет значение: браузер обрабатывает <head> сверху вниз, поэтому тяжёлый блокирующий ресурс в начале задерживает всё, что идёт ниже. Сторонние виджеты — чаты, счётчики, карты — часто подключают через собственный загрузчик, который сам подтягивает дополнительные файлы уже после загрузки страницы; такие скрипты почти всегда можно пометить defer без ущерба для работы.

Почему важно для SEO

Блокирующие ресурсы напрямую отодвигают момент, когда пользователь видит первый контент, — метрику FCP. Через неё страдает и LCP, а обе входят в оценку скорости, которую поисковики учитывают при ранжировании и особенно чувствительно — на мобильных.

Чем больше блокирующего CSS и JS в начале документа, тем дольше белый экран. Решения известны: вынести критический CSS в инлайн и загрузить остальное асинхронно, добавить defer или async скриптам, поднять важные ресурсы через preload. Google в отчётах PageSpeed отдельно перечисляет ресурсы, блокирующие рендеринг, и оценивает, сколько миллисекунд можно сэкономить. Робот при рендеринге тоже ждёт эти ресурсы, так что тяжёлая блокировка замедляет и обход.

Сторонние ресурсы заслуживают отдельного внимания: скрипты чатов, карт и рекламных сетей нередко тянут за собой цепочку дополнительных запросов, которые продолжают блокировать поток даже после загрузки основного файла. Такие виджеты почти всегда переносят на событие после отрисовки первого экрана. Для доменов, к которым страница обращается в любом случае, помогает заранее установить соединение через preconnect — тогда браузер не тратит время на DNS и TLS в момент, когда ресурс уже понадобился.

Частые ошибки

• Весь CSS сайта грузится одним файлом в <head> без выделения критической части.
• Скрипты аналитики и виджетов подключены синхронно в <head> без defer.
• Подключены шрифты, блокирующие текст, без font-display: swap.
• Сторонние библиотеки грузятся до контента, хотя нужны только для интерактива внизу страницы.
• defer и async расставлены наугад, из-за чего ломается порядок зависимостей скриптов.

Как проверить

PageSpeed Insights и вкладка Lighthouse в DevTools дают пункт «Устраните ресурсы, блокирующие отображение» со списком файлов и потенциальной экономией. В DevTools → Performance видно, на каком ресурсе браузер задержал первую отрисовку. Вкладка Network показывает порядок и приоритет загрузки.

SEO Crawler при обходе фиксирует скорость отрисовки и подключённые к странице стили и скрипты, помогая увидеть, где тяжёлые блокирующие ресурсы откладывают появление контента. Дальше по конкретным URL проще решить, что вынести в инлайн, а что отложить.

Вывод

Render-blocking ресурсы — главная причина долгого белого экрана и плохого FCP. Вынесите критический CSS в инлайн, остальное грузите асинхронно, добавьте скриптам defer или async и уберите из начала документа всё, что не нужно для первой отрисовки. Это один из самых заметных рычагов ускорения загрузки, и его стоит проверять при каждой правке шаблона или подключении нового стороннего скрипта.