Страница открывается медленно, хотя картинки сжаты, а сервер отвечает быстро? Скорее всего дело не в весе файлов, а в том, какие из них браузер берёт первым. Render-blocking ресурсы и неправильная работа с HTTP/2 — одна из самых частых причин, почему сайт тормозит и теряет позиции. Разберём, что именно блокирует экран, как это исправить технически и зачем вообще нужен современный протокол.
Что такое render-blocking ресурсы и как они тормозят страницу
Когда пользователь открывает сайт, браузер не рисует готовую картинку сразу. Он скачивает HTML, а затем по очереди разбирает ссылки на стили, скрипты, шрифты и картинки. Render-blocking ресурсы — это файлы, без которых браузер сознательно останавливает отрисовку: ждёт, пока они загрузятся и обработаются, и только потом показывает содержимое страницы.
Классические примеры таких файлов — тегов два: CSS-таблица стилей в <head> и синхронный (обычный) <script> без атрибутов. Пока браузер читает <link rel="stylesheet">, он не рисует ни одного слова на странице. Пока выполняется синхронный JavaScript, он не продолжает разбирать HTML ниже по коду. На практике это выглядит как «белый экран» или пустой лист в первые секунды после открытия — именно этот простой экран и называют First Contentful Paint (FCP) и Largest Contentful Paint (LCP). Чем дольше стоит блокировка, тем дольше пользователь видит пустоту.
Для поисковиков и людей это одинаково плохо. Google публично называет скорость загрузки одним из факторов ранжирования, а реальные посетители уходят: по данным отраслевых исследований, вероятность отказа резко растёт, если страница открывается дольше трёх секунд. Поэтому задача не в том, чтобы «ускорить всё», а в том, чтобы найти конкретные блокирующие ресурсы и убрать их.
CSS и JS, которые блокируют рендеринг
Не любой файл тормозит экран — важно понимать, какие именно и почему.
CSS в <head>. Браузер строит так называемый Render Tree (дерево отрисовки) и намеренно ждёт всех таблиц стилей, чтобы не перерисовывать страницу дважды. Если большой stylesheet подключён в шапке, весь первый экран стоит.
Синхронный JavaScript. Обычный <script src="..."> без defer или async останавливает разбор HTML: браузер ждёт загрузки и выполнения скрипта, прежде чем продолжить. Если это внешний файл с медленного CDN, стояние может быть долгим.
Системные шрифты и сторонние виджеты. Подключение шрифтов через Google Fonts без font-display: swap или встроенный код чата/каруселей тоже может вставать в очередь блокировки. Сторонний код особенно коварен: он делает запросы на чужой домен, а иногда ждёт ответа дольше, чем остальной контент страницы.
Понять, какие файлы ваши — помогает аудит скорости, который показывает именно порядок загрузки, а не только общий вес страницы. Подробнее об этом — в статье как проверить скорость сайта для SEO.
Как исправить: defer, async, critical CSS и minification
У блокировки есть несколько рабочих решений. На практике я применяю их вместе, по порядку от простого к сложному.
1. defer для скриптов приложения. Атрибут defer скачивает скрипт параллельно с разбором HTML, а выполняет его уже после того, как HTML полностью загружен, сохраняя порядок подключения. Для обычных приложений это обычно безопасный выбор — код не мешает отрисовке, но остаётся в правильном порядке.
2. async только для независимого кода. Атрибут async тоже грузит параллельно, но выполняется в любой момент, как только загрузился, без учёта порядка. Это подходит для аналитики и пикселей, которые не управляют интерфейсом. Критическую логику класть в async не стоит: можно случайно сломать порядок зависимостей и получить ошибку вместо ускорения.
<link rel="stylesheet" href="/assets/site.css">
<script defer src="/assets/app.js"></script>
<script async src="https://analytics.example/tag.js"></script>
Как выбрать между defer и async, чтобы не запутаться:
| Атрибут | Загрузка | Порядок выполнения | Когда применять |
|---|---|---|---|
defer |
параллельно с HTML | после разбора HTML, по порядку | скрипты приложения |
async |
параллельно с HTML | в любой момент, как загрузился | аналитика, пиксели |
3. Critical CSS для первого экрана. Если стилей немного, можно встроить в HTML только те правила, которые нужны для того, что видно без прокрутки, а остальной stylesheet оставить обычным тегом. Выигрыш есть, но важно не переборщить: если скопировать в head весь stylesheet целиком, вы увеличите вес страницы и усложните кэширование. Короткий critical CSS полезен только когда он реально покрывает первый экран.
4. Minification. Это самое простое и надёжное ускорение: удаление лишних пробелов, комментариев и переносов из CSS, JS и HTML. Файлы становятся меньше — а значит, быстрее скачиваются и раньше освобождают блокировку. Обычно минификацию включают на сервере или в сборке проекта; о том, как сжимать файлы и кэшировать их, рассказано в статье Gzip и Brotli: сжатие HTML, CSS и JS.
HTTP/2 vs HTTP/1.1: многозапросность и приоритеты
Зачем вообще упоминать протокол, если речь о блокировке? Потому что HTTP/2 меняет сам способ доставки файлов, но не отменяет логику браузера.
На HTTP/1.1 каждый файл — это отдельное соединение или ограниченное их количество. Чтобы загрузить страницу со ста файлами, браузер долго ждёт в очереди: типичный браузер открывает лишь 6–8 соединений с одного домена одновременно. HTTP/2 позволяет отправлять множество файлов через одно соединение параллельно (multiplexing) и сжимать заголовки. Страница действительно начинает доставляться быстрее и ровнее — например, десять небольших CSS-файлов укладываются в один поток вместо десяти последовательных запросов.
Но важный нюанс для SEO: сам по себе HTTP/2 не является самостоятельным фактором ранжирования и не делает тяжёлый синхронный JavaScript неблокирующим. Протокол ускоряет доставку, но если критический CSS или скрипт всё ещё стоят в очереди блокировки, белый экран останется. Ценность HTTP/2 раскрывается на нормальном быстром сервере, когда вы уже устранили базовые проблемы: сжали изображения, убрали неиспользуемые стили и сторонние виджеты.
Отдельно стоит упомянуть приоритеты (priority hints): в HTTP/2 браузер может получать подсказки о том, какие ресурсы важнее, и отдавать им предпочтение в очереди. Это тонкая настройка, которая работает только вместе с быстрым сервером — на медленном она почти не даёт эффекта.
Как проверить в Lighthouse и PageSpeed Insights
Оба инструмента Google строятся на одном движке аудита, поэтому дают близкие цифры.
PageSpeed Insights (PSI) — это онлайн-сервис: вставляете URL и сразу получаете оценку по мобильной и десктопной версиям с показателями FCP, LCP, CLS и списком конкретных проблем. В разделе «Диагностика» и «Возможности» прямо указаны ресурсы, которые блокируют рендеринг, — там будет ваш критический CSS и синхронные скрипты.
Lighthouse — расширение или встроенный инструмент в DevTools браузера. Он даёт более глубокий отчёт: можно посмотреть Waterfall (водопад загрузки) и увидеть именно последовательность запросов, где стоит каждый файл. Это удобнее PSI, когда нужно понять порядок, а не только итоговый балл.
На что смотреть в первую очередь: - Render-blocking resources — список конкретных CSS/JS, которые тормозят экран. - LCP и FCP — время первого и крупного контента; именно на них больше всего влияет блокировка. - Eliminate render-blocking рекомендации с оценкой экономии секунд.
Хотите увидеть эти же показатели без ручного запуска инструментов? Посмотрите их в своём аудите на карте сайта и в бесплатной проверке ниже.
Как проверить в seoquest.ru (/check/free)
Если не хочется разбираться с DevTools по отдельности, все ключевые проверки собраны в одном месте. Сервис seoquest.ru проводит автоматическую проверку сайта и выдаёт Health Score — сводную оценку вместе с конкретными SEO-ошибками.
Что использовать по теме статьи: - Проверка render-blocking — показывает, какие именно ресурсы блокируют отрисовку. - HTTP/2 — проверяет, поддерживает ли сайт современный протокол. - Бесплатная проверка — запускает полный аудит и сравнивает изменения после правок, чтобы вы видели эффект от каждого исправления прямо в цифрах.
Такой подход особенно удобен, когда нужно быстро найти источник проблемы, а не настраивать сложные инструменты вручную.
Часто задаваемые вопросы
HTTP/2 сам исправит белый экран?
Нет. Он не делает тяжёлый синхронный JavaScript неблокирующим и не уменьшает размер CSS. Сначала посмотрите водопад загрузки и покрытие ресурсов, затем уберите лишнее — назначьте defer или разделите код по страницам, и только потом оценивайте пользу от протокола.
Всегда ли нужно ставить defer?
Для обычных скриптов приложения defer часто безопасен, но перед этим проверьте порядок зависимостей и inline-код, который ждёт библиотеку раньше времени. Аналитику и независимые пиксели можно подключать через async, если они не управляют интерфейсом.
Обязателен ли critical CSS?
Нет. На маленьком сайте выигрыш может оказаться меньше, чем затраты на поддержку двух версий стилей. Сначала сожмите изображения, удалите неиспользуемые стили и сторонние виджеты, а уже потом измеряйте реальную необходимость critical CSS.
Нужно ли включать HTTP/3 вместо HTTP/2?
HTTP/3 может быть полезным дополнением, но не поводом откладывать базовые исправления. Наличие протокола не заменяет быстрый серверный ответ, разумный вес страницы и отсутствие блокирующих ресурсов.
Что делать в первую очередь
- Запустите бесплатную проверку сайта и откройте раздел скорости.
- Найдите конкретные render-blocking ресурсы в отчёте.
- Назначьте скриптам
deferилиasyncпо назначению, а стили разделите на критические и обычные. - Сожмите файлы через minification и проверьте результат повторно — чтобы увидеть разницу в цифрах.
Хотите узнать, сколько именно времени ваш сайт теряет на блокировке и какие ресурсы тормозят первый экран? Проверьте site бесплатно и откройте раздел скорости в своём аудите — без регистрации и ручного настройки инструментов.