Пользователь кликнул по ссылке и первые полторы секунды смотрит на белый экран. Ничего не сломано — просто браузер честно ждёт, пока загрузится тяжёлый файл стилей, прежде чем нарисовать хоть что-то. Эти секунды пустоты стоят вам отказов, конверсии и позиций: половина посетителей уходит, если контент не появился быстро, а поисковики учитывают скорость в ранжировании.
Разберёмся, откуда берётся эта задержка и как её убрать: что такое блокирующие ресурсы, как работает критический CSS, как правильно откладывать стили и скрипты и какие штатные инструменты 1С-Битрикс это закрывают. Тема — часть большой работы по производительности, которую мы ведём при аудите и оптимизации 1С и связанных систем.
Коротко
- Белый экран в начале загрузки — это блокирующие рендеринг CSS и синхронные скрипты в head.
- Критический CSS встраивают в HTML, чтобы первый экран рисовался сразу, а остальной CSS грузился асинхронно.
- Некритичным скриптам добавляют defer или async, чтобы они не тормозили отрисовку.
- Битрикс закрывает многое из коробки: минификация, объединение, композитный сайт и кэш.
Почему страница «белая» первые секунды
Задержка первой отрисовки — не «медленный интернет» и не «тяжёлый сервер» в общем смысле. Чаще всего это конкретный технический эффект: браузер получил HTML, но не может ничего показать, потому что в разметке есть ресурсы, которые он обязан обработать до отрисовки. Пока эти ресурсы грузятся и парсятся, экран остаётся пустым.
Проблема усугубляется на мобильных: слабый процессор дольше разбирает большой CSS и JS, а медленная сеть дольше их качает. Именно на мобильных потери от блокирующих ресурсов максимальны, а мобильный трафик для большинства магазинов — основной. Поэтому оптимизацию первого экрана всегда меряют в первую очередь на мобильном профиле.
Как браузер строит страницу
Чтобы понять, что блокирует рендер, полезно увидеть, как браузер вообще собирает страницу. Упрощённо цепочка такая: браузер парсит HTML и строит дерево DOM; параллельно из CSS строит дерево стилей CSSOM; из DOM и CSSOM собирает дерево отрисовки и только потом рисует пиксели на экране.
Ключевой момент: браузер не может отрисовать страницу без CSSOM, а CSSOM не готов, пока не загружен и не разобран весь CSS, подключённый в head. Синхронные скрипты в head ещё хуже — они останавливают парсинг HTML до своего выполнения. Отсюда и берутся два врага скорости: блокирующий CSS и блокирующий JS.
Что такое блокирующие ресурсы
Render-blocking ресурсы — это файлы, которые браузер обязан обработать до первой отрисовки. Их два типа, и с каждым работают по-своему.
| Ресурс | Почему блокирует | Решение |
|---|---|---|
| CSS в head | Без CSSOM нет отрисовки | Критический CSS инлайном + асинхронная загрузка остального |
| Синхронный JS в head | Останавливает парсинг HTML | defer / async, перенос в конец body |
| Внешние шрифты | Ждём загрузки, текст невидим | font-display: swap, предзагрузка |
| Импорты внутри CSS | Цепочка загрузок | Убрать @import, собрать в один файл |
Цель не в том, чтобы удалить эти ресурсы (стили и скрипты нужны), а в том, чтобы разорвать их блокировку рендера: критичное для первого экрана — сразу и минимально, всё остальное — без задержки отрисовки. Дальше разберём оба приёма.
Критический CSS: идея и польза
Критический CSS (critical CSS, above-the-fold CSS) — это выделенный минимальный набор стилей, нужный ровно для отрисовки видимой части страницы: шапки, первого экрана, основного контейнера. Этот набор встраивают прямо в HTML внутри тега style в head. Тогда браузер получает всё необходимое для первого экрана вместе с самим HTML и рисует его немедленно, не дожидаясь загрузки полного файла стилей.
Полный CSS при этом никуда не девается — он подгружается асинхронно и применяется к остальной части страницы по мере прокрутки. Выигрыш в том, что момент «пользователь увидел контент» наступает почти сразу, а не после скачивания сотен килобайт стилей. Для интернет-магазина, где первый экран — это часто главный оффер или карточка товара, эффект особенно заметен.
Как выделить критический CSS
Определить, какие именно стили критичны, вручную для сложного сайта тяжело и недолговечно — при каждом изменении вёрстки набор меняется. Поэтому подход зависит от масштаба.
- Определите ключевые шаблоны. Главная, каталог, карточка товара — у каждого свой первый экран и свой критический CSS.
- Сгенерируйте автоматически. Инструменты сборки анализируют, какие правила применяются к видимой области, и выделяют их.
- Встройте инлайном. Полученный набор помещается в
styleв head шаблона. - Обновляйте с релизом. Критический CSS пересобирается при изменениях вёрстки, а не живёт вручную.
Автоматизация здесь — не роскошь, а необходимость: ручной критический CSS устаревает на первом же изменении дизайна. Встраивание генерации в процесс сборки и деплоя снимает эту проблему; как выстроить такой конвейер, мы разбираем в статье про CI/CD и деплой на Битрикс.
Асинхронная загрузка остального CSS
После того как критический CSS встроен, полный файл стилей нужно загрузить так, чтобы он не блокировал рендер. Приём стандартный: ссылку на стили подключают с загрузкой в неблокирующем режиме, а применение включают после загрузки. Технически это делают через rel="preload" с последующим переключением на rel="stylesheet" либо через media-трюк с переключением после onload.
Что важно учесть:
- Fallback без JS. На случай отключённого JS оставляют обычное подключение стилей внутри
noscript. - Порядок каскада. Асинхронный CSS не должен конфликтовать с критическим — иначе после его применения возможен мигающий пересчёт стилей.
- Один объединённый файл. Меньше запросов — быстрее загрузка; Битрикс умеет объединять CSS штатно.
defer, async и порядок скриптов
Со скриптами логика похожая: то, что не нужно для первой отрисовки, не должно её тормозить. Для этого есть два атрибута, и путать их не стоит.
| Атрибут | Когда выполняется | Порядок | Для чего |
|---|---|---|---|
| defer | После парсинга HTML | Сохраняется | Основные скрипты с зависимостями |
| async | Сразу по загрузке | Не гарантирован | Независимые скрипты (аналитика) |
| без атрибута в head | Немедленно, блокируя | — | Избегать для некритичного |
Практическое правило: большинству скриптов подходит defer — он откладывает выполнение и сохраняет порядок, что безопасно для зависимостей. async — для полностью независимых скриптов вроде счётчиков. Всё, что не нужно для первого экрана, убирают из блокирующего head. Главное — проверить, что отложенный скрипт действительно не участвует в отрисовке видимой области, иначе появятся сдвиги контента.
Штатные инструменты 1С-Битрикс
Хорошая новость: значительную часть работы 1С-Битрикс закрывает из коробки, без самописных решений. В настройках оптимизации есть готовые механизмы, которые стоит включить и проверить в первую очередь.
- Объединение CSS и JS. Множество мелких файлов собирается в один — меньше запросов.
- Минификация. Из стилей и скриптов убираются пробелы и комментарии — меньше объём.
- Перенос скриптов вниз. JS переносится ближе к концу страницы, чтобы не блокировать парсинг.
- Отложенная загрузка. Штатная поддержка defer для подключаемых скриптов.
Эти опции дают быстрый выигрыш почти без риска, если после включения проверить ключевые страницы. Тонкую же настройку — критический CSS, асинхронный CSS, ручную работу с порядком — делают уже на уровне шаблона проекта. Как устроена архитектура таких доработок в платформе, полезно понимать из статьи про D7 в Битрикс — тот же принцип «делать правильно средствами платформы» работает и во фронтенде.
Композитный сайт и кэширование
Отдельный мощный механизм платформы — композитный сайт. Он разделяет страницу на статическую часть (шапка, каркас, повторяющиеся блоки) и динамическую (цена клиента, корзина, персональные данные). Статика кэшируется и отдаётся пользователю почти мгновенно, а динамические блоки догружаются после первой отрисовки. Для скорости первого экрана это огромный выигрыш: пользователь видит страницу сразу, ещё до того, как отработала вся серверная логика.
Композитный сайт хорошо сочетается с критическим CSS: статическую версию с уже встроенными критическими стилями браузер рисует за доли секунды. При этом важно грамотно разделить, что кэшируется, а что персонально, — иначе можно показать чужую цену или устаревшие данные. Настройку композита и кэширования мы закладываем в основу производительности при автоматизации на 1С, когда сайт тесно связан с учётной системой.
Шрифты и сдвиги макета
Шрифты — недооценённый источник и задержек, и сдвигов. Пока внешний шрифт грузится, браузер либо прячет текст (пустое место вместо контента), либо показывает системный, а потом резко подменяет — и макет прыгает. Оба сценария вредят: первый бьёт по скорости, второй — по метрике сдвигов.
- font-display: swap. Текст сразу рисуется системным шрифтом и плавно заменяется на нужный, а не прячется.
- Предзагрузка ключевых шрифтов.
preloadдля основного шрифта первого экрана. - Минимум начертаний. Не грузить пять весов шрифта, если используются два.
- Резервирование места. Совпадающие метрики fallback-шрифта уменьшают прыжок при подмене.
Влияние на Core Web Vitals
Вся эта работа — не ради абстрактной «скорости», а ради конкретных метрик, которые видит и пользователь, и поисковик. Core Web Vitals прямо реагируют на устранение блокирующих ресурсов.
- LCP (отрисовка главного контента). Критический CSS и композит ускоряют появление основного элемента первого экрана.
- FCP (первая отрисовка). Снятие блокировки рендера сокращает время до первого пикселя.
- CLS (сдвиги макета). Правильные шрифты и резервирование места убирают прыжки.
- INP (отзывчивость). Вынос тяжёлых скриптов из потока рендера делает страницу отзывчивее на действия.
Core Web Vitals — фактор ранжирования и поведения: быстрый сайт лучше индексируется, дольше удерживает и выше конвертирует. Поэтому оптимизация загрузки окупается сразу по двум фронтам — SEO и продажам.
Частые ошибки
- Раздутый критический CSS. В инлайн засунули почти весь CSS — он сам стал тормозом.
- Критический CSS устарел. Вёрстку меняли, а инлайн-набор не пересобрали — первый экран рисуется криво.
- defer на критичном скрипте. Отложили скрипт, нужный для первого экрана, — появились сдвиги и мигание.
- Объединение без проверки. Сломан порядок каскада или зависимостей — поехала вёрстка.
- Шрифт без swap. Текст невидим, пока грузится шрифт, или макет прыгает при подмене.
- Композит без разделения данных. В кэш попала персональная цена — пользователь видит чужую.
- Оптимизация без замеров. «Ускорили» вслепую, не проверив метрики до и после.
Чек-лист оптимизации
- Замер сделан. Ключевые страницы прогнаны через аудит на мобильном профиле, блокирующие ресурсы выявлены.
- Штатная оптимизация включена. Объединение и минификация CSS/JS, перенос скриптов вниз.
- Критический CSS встроен. Для главной, каталога и карточки, сгенерирован автоматически и обновляется с релизом.
- Остальной CSS асинхронный. Полный файл грузится неблокирующе, с fallback без JS.
- Скрипты с defer/async. Некритичный JS вынесен из блокирующего head.
- Композитный сайт. Статика отдаётся мгновенно, динамика отделена и не кэширует персональное.
- Шрифты оптимизированы. font-display: swap, предзагрузка основного, минимум начертаний.
- Метрики сверены. LCP, FCP, CLS, INP измерены до и после, эффект подтверждён.
Вывод
Белый экран в начале загрузки — это не судьба, а следствие конкретных блокирующих ресурсов, которые можно и нужно убрать. Критический CSS даёт браузеру всё для первого экрана сразу, асинхронная загрузка стилей и defer-скрипты снимают блокировку рендера, а композитный сайт отдаёт статику почти мгновенно.
1С-Битрикс закрывает значимую часть задачи штатными средствами — начните с них, замерьте эффект, а дальше добавляйте критический CSS и тонкую настройку загрузки. Работайте итеративно, всегда сверяясь с Core Web Vitals, — и вы получите сайт, который появляется мгновенно, лучше ранжируется и выше конвертирует, особенно на мобильных, где это решает.
