В корзине пусто!
С марта 2024 года Google окончательно заменил FID на INP — метрику, которая оценивает не только первое взаимодействие, но и любое в течение всей сессии. Если ваш сайт оптимизировался под старые показатели, часть работы уже неактуальна. Core Web Vitals остаются сигналом ранжирования, и слабые показатели становятся реальным барьером для конкуренции в топе. Этот материал — детальный технический разбор каждой метрики с причинами, кодом и реальными кейсами.
Если нужна помощь с технической оптимизацией — команда SEO-Factory проводит аудит в рамках SEO-продвижения сайтов. Актуальные пороги и методологию можно проверить на официальном ресурсе: web.dev/articles/vitals.
Содержание
Пороги показателей: что считать нормой
Google оценивает каждую метрику по данным реальных пользователей (CrUX — Chrome User Experience Report) и смотрит на 75-й перцентиль: 75% посещений вашего сайта должны попадать в зелёную зону. Если хотя бы одна метрика в «жёлтой» или «красной» зоне — страница не проходит оценку Page Experience.
Важно: если в вашем отчёте Google Search Console нет данных CrUX (новый сайт или мало трафика), Google не применяет Page Experience сигнал к страницам — но PageSpeed Insights всё равно покажет лабораторные данные Lighthouse.
Где проверить Core Web Vitals
Существует два типа данных: полевые (реальные пользователи, CrUX) и лабораторные (Lighthouse, симуляция). Google использует только полевые данные для ранжирования, но лабораторные помогают воспроизвести и зафиксировать проблему.
| Инструмент | Тип данных | Когда использовать |
|---|---|---|
| PageSpeed Insights | Полевые + лабораторные | Быстрая проверка конкретного URL |
| Google Search Console (Core Web Vitals) | Полевые | Обзор всего сайта, группировка URL |
| Chrome DevTools → Performance | Лабораторные | Профилирование конкретных проблем |
| Lighthouse CI | Лабораторные | Автоматизированный мониторинг в CI/CD |
| CrUX Dashboard (Looker Studio) | Полевые | Анализ динамики по 28-дневным окнам |
| WebPageTest | Лабораторные + waterfall | Глубокий анализ загрузки ресурсов |
Совет: начинайте с GSC — он покажет, какие шаблоны страниц имеют проблемы (карточки товаров, статьи, лендинги). PageSpeed Insights проверяет один URL за раз, GSC — картину по всему сайту сразу.
LCP: детальный разбор
Что именно является LCP-элементом
LCP (Largest Contentful Paint) измеряет момент, когда во viewport становится видимым наибольший по площади контентный элемент. Браузер рассматривает в качестве кандидатов на LCP следующие типы:
- Изображения —
<img>, элемент внутри<picture>, или изображение как CSSbackground-image(при определённых условиях) - Постер видео — атрибут
posterэлемента<video> - Текстовые блоки —
<h1>,<p>,<div>с большим количеством текста, если они являются наибольшими элементами во viewport - SVG с
<image>— редко, но учитывается
На практике для большинства коммерческих сайтов LCP-элемент — это hero-изображение в верхней части страницы. Для блогов — чаще всего первый <h1> или большая иллюстрация. Точный элемент можно определить через Chrome DevTools: вкладка Performance → после записи сессии найдите событие LCP в треке Timings. PageSpeed Insights также подсвечивает элемент скриншотом.
LCP > 4 секунды — это не просто плохая метрика. Это значит, что пользователь четыре секунды смотрит на незагруженную страницу. По данным Google, 53% мобильных пользователей покидают сайт, если загрузка занимает более 3 секунд. Сайт может ранжироваться, но конверсии падают задолго до того, как SEO-метрика становится красной.
Топ-5 причин плохого LCP и их исправление
1. LCP-изображение не имеет preload в <head>
Браузер не знает о важности LCP-изображения до тех пор, пока не распарсит HTML и не найдёт тег <img>. Это может занимать сотни миллисекунд. Решение — явный preload:
<link rel="preload" as="image"
href="/hero.webp"
fetchpriority="high">Для адаптивных изображений используйте imagesrcset и imagesizes на том же теге preload. Атрибут fetchpriority="high" (поддерживается с Chrome 102) дополнительно повышает приоритет в очереди загрузки.
2. Render-blocking ресурсы блокируют первый рендер
CSS и синхронный JavaScript в <head> блокируют парсер. Страница не рендерится, пока они не загружены и не выполнены. Исправление:
- Критический CSS (above-the-fold стили) — инлайните прямо в
<head> - Некритический CSS — откладывайте через
<link rel="preload" as="style" onload="this.rel='stylesheet'"> - JavaScript — используйте
deferилиtype="module"; синхронный JS в<head>— главный враг LCP
3. Ошибочный lazy loading на LCP-элементе
Атрибут loading="lazy" говорит браузеру подождать с загрузкой изображения. Если он присутствует на hero-изображении — это прямая причина плохого LCP, которую легко пропустить в шаблонах CMS. Проверка: PageSpeed Insights покажет предупреждение «Defer offscreen images» — если LCP-элемент там есть, это баг.
4. Большой TTFB (Time to First Byte)
Если сервер медленно отвечает, LCP не может быть хорошим по определению. TTFB > 800 мс — критическое значение. Причины: медленный хостинг, отсутствие кеширования, тяжёлые запросы к БД. Решение: CDN (Cloudflare, Fastly), Redis-кеширование, HTTP/2 или HTTP/3, SSR вместо клиентского рендеринга для важных страниц.
5. Неоптимизированный формат и размер изображения
Изображения в JPEG/PNG размером 1–3 МБ — системная проблема. WebP даёт 25–34% экономии относительно JPEG при той же качестве. AVIF ещё эффективнее, но поддерживается не всеми браузерами. Правильная реализация:
<picture>
<source srcset="/hero.avif" type="image/avif">
<source srcset="/hero.webp" type="image/webp">
<img src="/hero.jpg" alt="Hero" width="1200" height="600"
fetchpriority="high">
</picture>Атрибуты width и height обязательны — они позволяют браузеру зарезервировать место до загрузки изображения (что также улучшает CLS).
Отдельный кейс — шрифты и LCP: если LCP-элемент текстовый (например, большой H1), использование
font-display: optional гарантирует, что браузер не будет ждать загрузки нестандартного шрифта. Если шрифт не кеширован — отобразится системный, и LCP не пострадает.INP: детальный разбор
INP vs FID: принципиальная разница
FID (First Input Delay) измерял только задержку первого взаимодействия — как правило, клика сразу после загрузки страницы, когда браузер наиболее нагружен. INP (Interaction to Next Paint) — принципиально иная метрика: она отслеживает все взаимодействия за сессию (клики, нажатия клавиш, тапы) и фиксирует наихудшее. FID мог быть зелёным на сайте, где всё нормально при загрузке, но при скролле и кликах на фильтры — лагает. INP такое уже не пропустит.
Технически INP измеряет interaction latency — время от начала взаимодействия до следующего кадра (paint), отражающего визуальный отклик. Задержка складывается из трёх компонентов: input delay (время от события до начала обработки), processing time (время выполнения event handler), presentation delay (время от завершения JS до следующего кадра).
Long Tasks и их роль в плохом INP
Главный поток браузера (main thread) выполняет всё: парсинг HTML, выполнение JS, layout, paint. JavaScript однопоточный — и если какой-то скрипт занимает главный поток на > 50 мс, это считается Long Task. Во время Long Task браузер не может обрабатывать входные события пользователя. Результат: пользователь кликнул, браузер «не ответил» ещё 200–800 мс — это фиксируется как плохой INP.
Как профилировать INP в Chrome DevTools
Откройте страницу → Chrome DevTools → вкладка Performance → нажмите Record → выполните взаимодействие (клик на кнопку, открытие дропдауна, сабмит формы) → остановите запись. На треке Main ищите оранжевые блоки с красным уголком — это Long Tasks. Кликнув на блок, вы увидите стек вызовов: какой именно скрипт и функция вызвали задержку.
Удобнее — вкладка Performance Insights в DevTools. Она сразу выводит топ взаимодействий с наибольшей задержкой и декомпозирует: сколько занимает input delay, processing, presentation.
На одном e-commerce проекте (~80 000 посетителей/мес) INP был 680 мс из-за популярного jQuery-плагина слайдера, который выполнял полный rerender при каждом клике. После миграции на CSS-анимацию INP упал до 140 мс. Позиции по транзакционным запросам выросли на 8–12% в течение двух месяцев.
Конкретные оптимизации INP
Debouncing event handlers: если обработчик события запускается на каждый символ ввода или каждый пиксель скролла — это гарантированный Long Task. Используйте debounce или throttle:
function debounce(fn, delay) {
let timer;
return (...args) => {
clearTimeout(timer);
timer = setTimeout(() => fn(...args), delay);
};
}
input.addEventListener('input', debounce(handleSearch, 300));Web Workers для тяжёлых вычислений: если страница выполняет сортировку больших массивов, обработку изображений или парсинг данных — выносите это в Web Worker:
const worker = new Worker('heavy-task.js');
worker.postMessage({ data: largeArray });
worker.onmessage = (e) => renderResult(e.data);scheduler.yield() для разбивки Long Tasks:
async function processLargeList(items) {
for (let i = 0; i < items.length; i++) {
processItem(items[i]);
if (i % 50 === 0) await scheduler.yield();
}
}Defer сторонних скриптов: Google Analytics, Facebook Pixel, Hotjar — каждый может добавить 50–200 мс к INP. Загружайте после события load через requestIdleCallback.
Совет: INP сильно зависит от устройства. Тестируйте на реальном Android-смартфоне среднего класса (Moto G Power, Samsung A-серия), а не только в DevTools. Плохой INP на desktop часто незаметен, но критичен для мобильной аудитории.
CLS: детальный разбор
Что вызывает смещение макета
CLS (Cumulative Layout Shift) — сумма баллов за все неожиданные сдвиги элементов страницы при загрузке и использовании. Каждый сдвиг оценивается формулой: Impact Fraction × Distance Fraction.
Impact Fraction — доля viewport, которую занимает смещённый элемент (и пространство, где он был до смещения). Distance Fraction — на какую долю высоты viewport он сместился. Например: баннер занимает 50% высоты viewport и смещается на 25% вниз → 0.5 × 0.25 = 0.125 за один сдвиг.
| Причина | Типичное проявление | Исправление |
|---|---|---|
| Изображения без размеров | Контент прыгает вниз при загрузке картинки | Явные width и height, CSS aspect-ratio |
| Рекламные баннеры без резервирования | Баннер появляется над текстом и толкает контент | min-height на контейнере до загрузки |
| FOUT/FOIT (загрузка шрифтов) | Текст перерисовывается, строки смещаются | font-display: optional или swap |
| Динамически вставленный контент | Cookie-баннер, попап появляются с задержкой | Рендер до загрузки или фиксация внизу |
| CSS-анимации через top/left/margin | Элементы двигаются и влияют на соседей | Заменить на transform: translate() |
Исправление CLS: конкретные техники
Explicit dimensions и CSS aspect-ratio:
.hero-image {
aspect-ratio: 16 / 9;
width: 100%;
object-fit: cover;
}
<img src="hero.webp" width="1200" height="675" alt="Hero">Font-display: optional vs swap: optional — строже: если шрифт не загружен за 100 мс — браузер использует системный и больше не пытается заменить. Сдвиг невозможен по определению. swap — мягче: сначала системный шрифт, потом замена. Сдвиг возможен, но минимален при правильном font size adjustment.
Совет по анимациям: анимации через
transform и opacity выполняются на GPU и не влияют на layout. Анимации через top, left, margin всегда вызывают reflow. Проверяйте через Chrome DevTools → Rendering → Layout Shift Regions.Инструменты измерения: Lighthouse vs CrUX
Полевые данные vs лабораторные: почему они различаются
Lighthouse (лабораторные данные): изолированная машина, симулированный 4G, Moto G4 в качестве CPU throttling. Идеальные условия, один прогон.
CrUX (полевые данные): агрегат реальных посещений за 28 дней. Включает старые устройства, медленный 3G, кешированные и некешированные страницы, сторонние расширения браузера.
| Параметр | Lighthouse | CrUX (GSC / PSI) |
|---|---|---|
| Источник данных | Симуляция (1 запуск) | Реальные пользователи (28 дней) |
| Стабильность | Варьируется между запусками | Стабильная агрегация |
| Влияние на ранжирование | Нет | Да (Page Experience) |
| Диагностика проблем | Детальная (waterfall, скриншоты) | Ограниченная |
| Минимальный трафик | Не нужен | ~1000 origins в CrUX |
WebPageTest: waterfall-анализ
WebPageTest — мощнейший бесплатный инструмент для глубокого анализа. Waterfall-диаграмма показывает последовательность загрузки каждого ресурса. Для LCP-оптимизации ищите: LCP-изображение загружается поздно, длинный TTFB, CSS или JS с длинным временем блокировки.
Совет: в WebPageTest выставляйте тест из локации, близкой к вашей аудитории (Frankfurt, Warsaw), и выбирайте реальное устройство вместо эмуляции — это даст наиболее точные результаты.
Приоритетная матрица: с чего начинать оптимизацию
Классическая ошибка — бросаться исправлять то, что Lighthouse отображает в первой строке отчёта. Lighthouse ранжирует подсказки по расчётному влиянию на Performance Score, а не по реальному влиянию на ранжирование. Правильный подход — матрица «усилие / влияние».
Три исправления из «зелёного» квадранта — убрать loading="lazy" с LCP-изображения, добавить явные width/height на картинки и поставить rel="preload" на LCP-ресурс — занимают в среднем 1–2 часа разработчика и дают заметный скачок и по LCP, и по CLS. Это не преувеличение: на типичном WordPress/OpenCart сайте только одно исправление lazy-loading на hero-изображении может улучшить LCP на 0.5–1.2 секунды.
Совет: конвертация в WebP — задача, которую можно автоматизировать раз и навсегда. В WordPress — плагины ShortPixel или Imagify. В OpenCart — расширения для WebP. После автоматической конвертации размер изображений уменьшается на 25–40% без ручного вмешательства для каждой новой загрузки.
Влияние CWV на ранжирование: реальные кейсы
Searchmetrics в исследовании 2021 года выявил корреляцию между Core Web Vitals и позициями — но корреляция не означает причинно-следственную связь. Google сам подчёркивает: CWV — один из многих факторов, и «отличный контент с плохими CWV всё равно может ранжироваться выше, чем плохой контент с отличными CWV».
Google в официальной документации прямо пишет: «Page Experience signal влияет на ранжирование, но качество контента остаётся более важным фактором». CWV — это тай-брейкер при равных условиях, а не самостоятельный двигатель позиций.
Когда сайты с плохим CWV всё равно ранжируются
- Доминирующий авторитет домена — Wikipedia, крупные медиа, государственные сайты имеют тысячи обратных ссылок, которые перекрывают слабые CWV
- Уникальность контента — если по запросу есть только 2–3 качественных результата, Google не имеет выбора
- Размер выборки CrUX — если сайт не имеет достаточного трафика для CrUX, Page Experience сигнал не применяется вообще
Приоритет исправлений зависит от конкурентной среды. Проверяйте CWV конкурентов через PageSpeed Insights перед планированием работ — если все в жёлтой зоне, первый, кто достигнет Good, получает преимущество.
С чего начать: порядок работы
Самая распространённая ошибка — браться за всё сразу. Правильный подход: сначала измерить, затем определить приоритет, затем исправить и верифицировать результат.
- Проверьте GSC — какой шаблон страниц в статусе «Плохо» (Poor).
- Если несколько метрик в красной зоне — начинайте с LCP: он чаще всего тянет другие показатели вниз.
- INP исправляйте вторым — он требует профилирования JS и работы разработчика.
- CLS обычно исправляется быстро и часто не требует привлечения backend-разработчика.
После внедрения изменений не проверяйте результат на следующий день. CrUX агрегирует данные за 28-дневное скользящее окно. Реальные полевые данные обновятся минимум через 28 дней после деплоя.
Как верифицировать результат после деплоя
Две стратегии верификации, которые работают параллельно.
Быстрая проверка (Lighthouse + PageSpeed Insights): сразу после деплоя проверьте лабораторные данные — они отразят изменения немедленно. Сравните LCP, TBT (Total Blocking Time — прокси для INP в лаборатории), CLS до и после. Если лабораторные данные улучшились — оптимизация сработала технически.
Реальный результат (CrUX): через 28 дней откройте PageSpeed Insights или GSC. CrUX покажет изменение на полевых данных. Важный нюанс: если улучшение было значительным (например, LCP с 5 с до 2.2 с), промежуточное 28-дневное окно будет содержать mix старых и новых сессий. «Чистый» результат виден только через два полных цикла, то есть через 56 дней.
Segment-specific проверка: если у вас разные шаблоны страниц (главная, карточки товаров, статьи блога), проверяйте каждый шаблон отдельно. В GSC отчёт Core Web Vitals группирует URL по шаблонам автоматически — смотрите, по каким группам статус изменился с Poor на Needs Improvement или с Needs Improvement на Good.
Мониторинг на постоянной основе: настройте Lighthouse CI в CI/CD пайплайне — каждый деплой автоматически запускает проверку и блокирует выкатку, если метрики деградируют. Это предотвращает регрессии: распространена ситуация, когда разработчик добавляет новый виджет и случайно ломает LCP новым render-blocking скриптом.
Инструменты мониторинга: DataDog и Lighthouse CI
Разовая проверка в PageSpeed Insights — это диагностика, а не мониторинг. Для полноценного контроля качества нужны инструменты, которые отслеживают метрики непрерывно.
Lighthouse CI интегрируется в CI/CD пайплайн (GitHub Actions, GitLab CI) и автоматически запускает проверку при каждом деплое. Если LCP или CLS деградируют относительно базового значения — сборка помечается как failed. Это предотвращает регрессии: типичная ситуация, когда разработчик добавляет новый виджет и случайно вставляет render-blocking скрипт или loading="lazy" на hero-изображение. Lighthouse CI поймает это до выкатки в продакшн.
DataDog Real User Monitoring (RUM) и аналогичные продукты (Sentry Performance, SpeedCurve) собирают реальные данные от ваших пользователей — аналогично CrUX, но с доступом к сырым событиям, сегментацией по типу устройств, странам, версиям браузера и конкретным маршрутам приложения. Для крупных e-commerce сайтов это незаменимый инструмент: можно сравнить INP на старых Android-устройствах и на Desktop, выявить конкретные страницы или компоненты с регулярными Long Tasks.
Минимальный стек мониторинга: Lighthouse CI в CI/CD (бесплатно) + CrUX Dashboard в Looker Studio (бесплатно) — достаточно для большинства проектов. DataDog RUM и SpeedCurve — для проектов с >50 000 визитов в месяц, где деградация метрик напрямую влияет на выручку.
Для небольших команд, которые не хотят настраивать Lighthouse CI с нуля, существует официальная web-vitals JavaScript library от Google. Подключив её на сайт, вы начнёте собирать реальные CWV-данные прямо в вашу систему аналитики — Google Analytics 4, BigQuery или кастомный endpoint. Это даёт те же данные, что CrUX, но без 28-дневной задержки: результаты видны в реальном времени по каждой странице и типу устройств. Особенно полезно при A/B-тестировании оптимизаций — можно в течение нескольких дней увидеть разницу в реальных INP и LCP между контрольной и тестовой группой пользователей.
Практический чеклист: что исправлять по каждой метрике
Сводная таблица для команды разработки или SEO-специалиста. Три колонки: метрика, наиболее частая причина, приоритетное исправление. Используйте её как постановку задач после аудита в Google Search Console.
| Метрика | Наиболее частая причина | Приоритетное исправление |
|---|---|---|
| LCP | Hero-изображение без preload или с loading="lazy" | Добавить rel="preload" и fetchpriority="high", убрать lazy с hero-img |
| LCP | TTFB свыше 800 мс | Подключить CDN, настроить серверное кеширование, HTTP/2 |
| LCP | Изображения в JPEG/PNG свыше 500 КБ | Конвертировать в WebP или AVIF, указать width и height |
| INP | Long Tasks свыше 200 мс в event handlers | Debounce обработчиков, разбивка через scheduler.yield() |
| INP | Сторонние скрипты (аналитика, чат, пиксели) | Отложить загрузку до события load или requestIdleCallback |
| INP | Тяжёлые вычисления в главном потоке | Вынести в Web Worker |
| CLS | Изображения без явных размеров | Добавить width/height или CSS aspect-ratio |
| CLS | Рекламный баннер без резервирования места | Установить min-height на контейнер до загрузки рекламы |
| CLS | Нестандартные шрифты без font-display | Добавить font-display: optional или swap в @font-face |
Часто задаваемые вопросы
Что такое Core Web Vitals и зачем они нужны?
Core Web Vitals — три метрики пользовательского опыта: LCP (скорость загрузки основного контента), INP (время отклика на взаимодействие), CLS (стабильность верстки). Google использует их как фактор ранжирования с 2021 года.
Какой LCP считается хорошим?
Хороший LCP — до 2.5 секунды. От 2.5 до 4 секунд — требует улучшения. Более 4 секунд — плохой показатель. Цель — чтобы 75% реальных посетителей (по данным CrUX) имели LCP до 2.5s.
Как быстро можно улучшить Core Web Vitals?
Базовые правки (сжатие изображений, отложенный JS) дают результат за 1–2 недели. Серьёзные улучшения через оптимизацию сервера — за 1–2 месяца. CLS исправляется за несколько дней, если причина — изображения без размеров.
Влияют ли Core Web Vitals на конверсию?
Да. По данным Google, улучшение LCP на 0.1s увеличивает конверсию в среднем на 8%. Плохой INP напрямую связан с отказами — если кнопка реагирует медленнее 200ms, часть пользователей уходит.
Нужна техническая оптимизация сайта?
Проведём аудит Core Web Vitals, определим приоритетные исправления и внедрим их в рамках SEO-стратегии. Без шаблонных отчётов — конкретные задачи для разработчика и контроль результата через CrUX.
