Core Web Vitals — набор метрик Google для оценки пользовательского опыта загрузки веб-страниц. С 2021 года являются сигналом ранжирования в Google Search. Три основные метрики: LCP, INP (ранее FID), CLS.
Метрики Core Web Vitals
- LCP (Largest Contentful Paint)
- Время отрисовки самого крупного видимого элемента страницы (изображение, блок текста). Хорошо: ≤ 2.5 с. Требует улучшения: 2.5-4 с. Плохо: > 4 с. Зависит от TTFB, размера изображений, приоритизации загрузки ресурсов.
- INP (Interaction to Next Paint)
- Замеряет задержку между взаимодействием пользователя (клик, нажатие) и следующей отрисовкой. Заменил FID в марте 2024 года. Хорошо: ≤ 200 мс. Плохо: > 500 мс. Зависит от JavaScript-производительности и блокировки основного потока.
- CLS (Cumulative Layout Shift)
- Суммарный сдвиг контента страницы во время загрузки (раздражающий эффект «прыгающего» контента). Хорошо: ≤ 0.1. Плохо: > 0.25. Причины: изображения без размеров, веб-шрифты, динамически вставляемый контент.
История
Core Web Vitals анонсированы Google в мае 2020 года, стали сигналом ранжирования с июня 2021 года. До этого Google оценивал скорость через PageSpeed Score (произвольный балл 0-100). Переход к измеримым метрикам с конкретными пороговыми значениями упростил работу разработчиков: теперь понятно, что именно нужно улучшать. INP заменил FID (First Input Delay) в 2024 году как более репрезентативная метрика отзывчивости.
Измерение и инструменты
Field data (реальные пользователи): Chrome UX Report (CrUX) — статистика из реальных браузеров Chrome. PageSpeed Insights использует CrUX для оценки. Lab data (синтетическое измерение): Lighthouse в Chrome DevTools, WebPageTest, PageSpeed Insights. Lab data отличается от field: тесты проводятся из одного места, без кеша, без пользовательского контекста.
# Lighthouse CLI
npm install -g lighthouse
lighthouse https://example.com --output html --output-path report.html
# Проверка Core Web Vitals через API PageSpeed
curl "https://www.googleapis.com/pagespeedonline/v5/runPagespeed?url=https://example.com&strategy=mobile"Оптимизация LCP
LCP-элемент обычно — Hero-изображение или крупный заголовок. Оптимизация:
<link rel="preload" href="/hero.webp" as="image" fetchpriority="high">— приоритетная загрузка.- Конвертировать в WebP/AVIF — на 25-50% меньше размер.
- Сервировать через CDN с edge-кешированием.
- Снизить TTFB — замедляет всё, в том числе LCP.
На что обращать внимание
Core Web Vitals оцениваются по 75-му перцентилю полевых данных — 25% «плохих» сессий не портят оценку. Для сайтов с мало посещаемыми страницами CrUX-данных недостаточно (< 1000 визитов/28 дней) — только lab-метрики. Хостинг напрямую влияет на LCP и TTFB — медленный VPS не позволит достичь «зелёных» показателей даже с оптимизированным кодом.
Core Web Vitals и хостинг
Между Core Web Vitals и качеством хостинга существует прямая зависимость. LCP — время загрузки крупнейшего элемента страницы — напрямую зависит от скорости сервера и эффективности кэширования. Сервер на HDD с медленным I/O будет проигрывать аналогичному на NVMe SSD в несколько раз. Разница в 200 мс TTFB может сместить LCP за порог в 2,5 секунды, что переводит сайт из «хорошего» в «требующий улучшения».
INP (Interaction to Next Paint) зависит не только от JavaScript, но и от времени ответа сервера на API-запросы. Если каждое действие пользователя инициирует AJAX-запрос к бэкенду, медленный сервер напрямую ухудшает показатель. Настройка Redis для кэширования сессий и часто запрашиваемых данных снижает задержку ответа в разы. CLS — смещение макета — серверных проблем почти не касается, но зависит от корректной отдачи CSS через CDN. Если стили подгружаются позже разметки, страница «прыгает» в момент рендера.