Как ускорить сайт для SEO: чек-лист по Core Web Vitals
Core Web Vitals — три метрики, которые Google официально использует как часть ранжирующего сигнала page experience: LCP отвечает за скорость загрузки, CLS — за визуальную стабильность, INP — за отзывчивость на действия. Все три измеряются в PageSpeed Insights и в отчёте Core Web Vitals в Search Console.
LCP: почему главный экран должен появляться быстро
LCP (Largest Contentful Paint) — время до отрисовки самого крупного видимого блока: обычно это герой-изображение, видео-превью или крупный заголовок. Порог «хорошо» — до 2,5 секунды, «требует улучшения» — до 4 секунд, свыше 4 секунд — «плохо», и именно эта категория напрямую вредит ранжированию.
Основные причины медленного LCP: тяжёлое несжатое изображение в шапке, шрифт, блокирующий рендеринг текста (FOIT), и сторонние скрипты — виджеты чата, счётчики аналитики, пиксели ретаргетинга — загружаемые синхронно до основного контента.
Практические шаги: сконвертировать герой-изображение в WebP или AVIF с атрибутом fetchpriority="high", подключить шрифты через font-display: swap, вынести сторонние скрипты в асинхронную загрузку через async или defer, использовать CDN для статики — для Узбекистана это особенно заметно снижает задержку по сравнению с хостингом за пределами региона.
CLS: почему сайт не должен «прыгать» при загрузке
CLS (Cumulative Layout Shift) измеряет суммарное визуальное смещение элементов во время загрузки страницы. Порог «хорошо» — до 0,1, «плохо» — свыше 0,25. Пользователь начинает читать текст, а через секунду блок съезжает из-за подгрузившейся картинки или рекламы — это и есть CLS, и Google фиксирует такие смещения программно.
Основные источники: изображения и видео без явно заданных атрибутов width и height или CSS aspect-ratio, из-за чего браузер не резервирует место заранее; шрифты, которые подгружаются позже и меняют ширину текста; динамически вставляемый контент — баннеры, попапы согласия на cookie — без зарезервированного места.
Практические шаги: всегда указывать размеры для медиа или использовать aspect-ratio в CSS, резервировать место под баннеры и попапы через min-height ещё до их загрузки, избегать вставки нового контента выше уже отрисованного, кроме как в ответ на действие пользователя.
INP: новая метрика отзывчивости вместо FID
INP (Interaction to Next Paint) заменил FID в марте 2024 года и измеряет задержку между действием пользователя — тапом, кликом, вводом текста — и визуальным откликом интерфейса на протяжении всего визита, а не только первого взаимодействия. Порог «хорошо» — до 200 мс, «плохо» — свыше 500 мс.
Главная причина плохого INP — длинные задачи (long tasks) в основном потоке JavaScript: тяжёлая аналитика, сложные обработчики событий на карточках товара, синхронные вычисления при фильтрации каталога. Пока главный поток занят, браузер не может ответить на тап пользователя.
Практические шаги: разбивать длинные задачи на части через планирование с помощью requestIdleCallback или разбиение на чанки, использовать debounce на обработчиках ввода в фильтрах и поиске, переносить тяжёлые вычисления в Web Worker там, где это возможно без блокировки интерфейса.
Как измерять: полевые данные важнее лабораторных
PageSpeed Insights показывает два типа данных: лабораторные (Lighthouse, единичный симулированный запуск) и полевые (Chrome UX Report, реальные данные пользователей за последние 28 дней). Для ранжирования Google использует именно полевые данные — лабораторный результат полезен для диагностики, но не отражает то, что видит алгоритм.
Если у сайта недостаточно трафика для попадания в CrUX (обычно нужен минимум заметный объём посещений), Search Console не покажет полевые данные вообще, и ориентироваться приходится на лабораторные показатели PageSpeed Insights и на собственный RUM (real user monitoring) через web-vitals.js.
Порядок работ: с чего начинать оптимизацию
Сначала LCP — это самая заметная метрика и чаще всего даёт наибольший прирост от относительно простых правок: сжатие изображений, критический CSS, приоритизация героя. Затем CLS — обычно фиксится за счёт явных размеров медиа без серьёзной переработки кода. INP чинится дольше всего, потому что требует разбора JS-архитектуры страницы, и его стоит планировать как отдельную итерацию с разработчиком.
После каждой правки проверяйте изменение не только в лабораторном тесте, но и ждите обновления полевых данных CrUX — это занимает до 28 дней, поэтому промежуточная лабораторная метрика не гарантирует такой же сдвиг в реальном ранжирующем сигнале.