Core Web Vitals: как ускорить сайт и попасть в зелёную зону

Что такое Core Web Vitals и почему это важно

Core Web Vitals — три метрики, которыми Google измеряет реальный пользовательский опыт на сайте. LCP (Largest Contentful Paint) — за сколько секунд отрисовывается самый крупный элемент первого экрана: хорошо, если укладывается в 2,5 секунды. INP (Interaction to Next Paint) — как быстро интерфейс отвечает на клики и ввод: порог 200 миллисекунд. CLS (Cumulative Layout Shift) — насколько «прыгает» вёрстка во время загрузки: допустимо не больше 0,1.

Эти цифры — фактор ранжирования. При прочих равных Google отдаёт предпочтение быстрым страницам, а медленный сайт теряет позиции ещё до того, как поисковик оценит контент. Но важнее другое: по разным исследованиям, каждая лишняя секунда загрузки уводит 7–10% конверсии. Пользователь с телефона в метро не будет ждать шесть секунд — он вернётся в выдачу и откроет сайт конкурента.

Лабораторные и полевые данные: почему PageSpeed «врёт»

Первая ловушка при диагностике — путать лабораторный замер с реальностью. Lighthouse и PageSpeed Insights прогоняют сайт на эмуляторе среднего телефона с медленной сетью — это лабораторные данные, воспроизводимые, но синтетические. А ранжирование строится на полевых данных CrUX: Google собирает метрики реальных посетителей вашего сайта за 28 дней и берёт 75-й перцентиль.

Отсюда типичная ситуация: у разработчика на MacBook «всё летает», Lighthouse показывает 90+, а в Search Console страницы висят в жёлтой зоне. Диагноз всегда начинается с полевых данных (Search Console → «Основные интернет-показатели»), а лаборатория нужна, чтобы воспроизвести проблему и проверить исправление.

Где чаще всего прячется медленный LCP

LCP — самая частая проблемная метрика, и у неё всего четыре фазы: время ответа сервера, задержка загрузки ресурса, само скачивание и задержка отрисовки. Разложив LCP по фазам (это умеет PageSpeed Insights), вы сразу видите виновника.

• Медленный сервер (TTFB больше 800 мс) — дешёвый хостинг, тяжёлая CMS без кеша, сервер на другом континенте. Лечится кешированием страниц и CDN.
• Тяжёлое hero-изображение — картинка 3–5 МБ в PNG вместо 100–200 КБ в WebP/AVIF. Самый дешёвый в исправлении пункт списка.
• Render-blocking ресурсы — CSS и шрифты со сторонних доменов, каждый из которых добавляет 100–300 мс на установку соединения. Шрифты стоит хостить на своём домене.
• JS-анимации поверх контента — прелоадеры и reveal-эффекты, которые держат готовый контент невидимым. Реальный случай из моей практики: сокращение декоративного прелоадера с 3 до 1,2 секунды срезало столько же с LCP — контент был готов, его просто прятали.
• Клиентский рендеринг — если HTML приходит пустым, а контент рисует JavaScript, LCP начинается только после загрузки и исполнения бандла. Лечится SSR/SSG.

INP и CLS: отзывчивость и стабильность

INP растёт, когда главный поток браузера занят: длинные JavaScript-задачи, тяжёлая гидратация, аналитика и чаты, которые грузятся вместе с контентом. Рецепт — дробить длинные задачи, откладывать некритичные скрипты и не тащить в бандл то, что нужно только на одной странице (code splitting).

CLS почти всегда рукотворный: изображения без атрибутов width/height, баннеры и виджеты, которые вставляются поверх контента после загрузки, шрифты, меняющие высоту строк при подмене. Задайте размеры всем медиа, резервируйте место под динамические блоки, используйте font-display: swap с подобранным фолбэком — и сдвиги исчезнут.

Чек-лист: что проверить в первую очередь

• Полевые данные в Search Console — какие группы страниц и какая метрика в красной зоне.
• Разбивка LCP по фазам в PageSpeed Insights — сервер, ресурс или отрисовка.
• Формат и вес hero-изображения: WebP/AVIF, адекватный размер, fetchpriority="high".
• Шрифты: self-hosted, с preload и font-display: swap.
• Сторонние скрипты: что реально нужно до первого экрана (обычно — ничего).
• Размеры у всех изображений и iframe, зарезервированное место под баннеры.
• Кеширование HTML и статики, gzip/brotli, HTTP/2.

По моему опыту, 60–70% сайтов попадают в зелёную зону уже после первых трёх пунктов — без переписывания кода и смены стека.

Когда нужен полноценный аудит

Если быстрые правки не помогли, проблема обычно глубже: архитектура рендеринга, утечки в SPA, монолитный бандл на мегабайты, legacy-код, который страшно трогать. Здесь нужен системный аудит: профилирование, разбор бандла, карта проблем с приоритетами и планом внедрения.

Я делаю такие аудиты регулярно: например, на e-commerce платформе с миллионом посетителей в месяц вывод Core Web Vitals в зелёную зону и миграция сборки дали ускорение загрузки на 70%. Средний результат моих клиентов после аудита — улучшение метрик на 40% и больше.