В корзине пусто!
С марта 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 — не ракетная наука, но работа, требующая профилирования, расстановки приоритетов и терпения. LCP — preload + WebP + TTFB. INP — всегда JS-аудит и разбивка Long Tasks. CLS — в основном отсутствующие размеры и неправильный порядок загрузки ресурсов. Между метриками есть связи: медленный TTFB ухудшает LCP, тяжёлый JS ухудшает и INP, и LCP.
Три исправления из «быстрых побед» — убрать lazy с LCP-изображения, добавить preload и указать размеры изображениям — занимают в среднем 1–2 часа разработчика и дают заметный прирост по всем трём метрикам одновременно. Важно понимать: Core Web Vitals не работают изолированно. Сайт с хорошими CWV, но слабым контентом или слабой ссылочной массой не выйдет в топ только за счёт технического совершенства. И наоборот — сильный по контенту сайт с плохими CWV теряет позиции там, где конкуренты уже привели показатели в норму. Правильный подход — рассматривать Core Web Vitals как неотъемлемую часть комплексной SEO-стратегии, а не как отдельный разовый проект. Команда SEO-Factory включает техническую оптимизацию в работы по SEO-продвижению.
Нужна техническая оптимизация сайта?
Проведём аудит Core Web Vitals, определим приоритетные исправления и внедрим их в рамках SEO-стратегии. Без шаблонных отчётов — конкретные задачи для разработчика и контроль результата через CrUX.
