Core Web Vitals 2026

TL;DR

В 2026 Google использует три CWV-метрики как часть Page Experience сигнала: LCP < 2.5s, INP < 200ms, CLS < 0.1. Самая часто проваленная — INP (43% сайтов в красной зоне). Сайты, прошедшие все три, имеют −24% bounce rate и измеримый рост позиций. Этот playbook — пошаговая оптимизация каждой метрики с конкретными техниками.

ℹГде смотреть свои метрики

PageSpeed Insights (pagespeed.web.dev) — даёт лабораторные значения. CrUX (Chrome User Experience Report) — реальные данные пользователей, доступны в GSC → Core Web Vitals. Google ранжирует по CrUX, а не PageSpeed.

Этап 1. Замер baseline

Прежде чем оптимизировать — зафиксируй текущие значения.

Замер исходных метрик

0 из 5 (0%)

• Прогон ключевых страниц (главная + 3-5 типовых посадочных) через PageSpeed Insights
• Mobile и Desktop отдельно — разные пороги, разные узкие места
• Скриншот / экспорт результатов как baseline
• Открыт CrUX в Google Search Console → Core Web Vitals
• Зафиксировано: % URL в красной/жёлтой/зелёной зоне для LCP, INP, CLS

Этап 2. LCP — Largest Contentful Paint

LCP — время до отрисовки самого крупного видимого элемента (обычно hero-картинка или H1).

Порог 2026: хорошо < 2.5s, плохо > 4s.

Главные виновники плохого LCP

• Тяжёлое hero-изображение без оптимизации
• TTFB > 1s (медленный сервер)
• Блокирующий JS перед отрисовкой
• Шрифты без font-display: swap (FOIT)

Оптимизация LCP

0 из 9 (0%)

• Hero-изображение preload: <link rel="preload" as="image" href="...">
• Hero в WebP/AVIF (на 30-50% меньше JPEG)
• Адаптивные размеры через srcset/sizes
• CDN для статики (Cloudflare/Fastly)
• TTFB < 800ms (проверь Server-Timing header)
• SSR/SSG вместо client-side rendering на critical path
• font-display: swap для всех @font-face
• Inline critical CSS (above-the-fold)
• Defer/async для не-критичного JS

💡Совет

Если LCP-элемент — картинка, добавь ей атрибут fetchpriority="high". Это новый стандарт (Chrome 101+), и он работает лучше, чем preload-link.

Этап 3. INP — Interaction to Next Paint

INP — время от взаимодействия пользователя (клик, тап, ввод) до следующей отрисовки UI. Заменил FID в марте 2024.

Порог 2026: хорошо < 200ms, плохо > 500ms.

Главные виновники плохого INP

• Тяжёлые обработчики кликов с длинными JS-задачами (>50ms)
• Синхронные операции с DOM
• Third-party скрипты (chat-виджеты, A/B-test, аналитика)
• React state updates без startTransition / useDeferredValue
• Большие useEffect chains на mount

Оптимизация INP

0 из 9 (0%)

• Прогнан Performance профайлинг в DevTools — выявлены long tasks (>50ms)
• Lazy-load для third-party (chat-виджеты, аналитика) — после первого взаимодействия
• Разбиение long tasks через scheduler.yield() или setTimeout(0)
• Web Workers для CPU-heavy вычислений
• React: useDeferredValue / startTransition для non-urgent updates
• requestIdleCallback для not-critical работы
• Удалить или отложить heavy listeners (scroll, resize) — passive: true
• Виртуализация для больших списков (react-window)
• Дебаунс/тротлинг для частых событий (input, scroll)

⚠INP — самая сложная метрика

INP измеряется во всём жизненном цикле страницы, а не только при первом клике. Один тяжёлый клик на 600ms убивает метрику. Используй DevTools → Performance Insights (или Chrome 120+ Performance panel) → ищи warning «Long task» на interactions.

Этап 4. CLS — Cumulative Layout Shift

CLS — сумма всех сдвигов вёрстки во время загрузки. Текст «прыгнул» под рекламой, кнопка переместилась → клик мимо.

Порог 2026: хорошо < 0.1, плохо > 0.25.

Главные виновники плохого CLS

• Изображения без width/height (или aspect-ratio)
• Реклама и embed’ы без зарезервированного места
• Шрифты без font-display: swap (FOIT/FOUT)
• Динамически вставляемый контент сверху страницы
• iframe без явного размера

Оптимизация CLS

0 из 8 (0%)

• Все <img> имеют атрибуты width и height (или CSS aspect-ratio)
• Все iframe имеют width/height
• Под рекламные блоки зарезервировано место через min-height
• Embed-блоки (YouTube, Twitter) с фиксированным aspect-ratio контейнером
• font-display: swap + font-size-adjust для уменьшения FOUT-сдвига
• Контент не вставляется сверху уже видимого (хедер не растёт)
• CSS transform для анимаций вместо top/left
• Skeleton-screens вместо пустых блоков (резервируют место)

Этап 5. Проверка после правок

После всех оптимизаций — повторный замер. Изменения в CrUX появляются через 28 дней (rolling window), поэтому сразу не увидишь в GSC.

Проверка результатов

0 из 5 (0%)

• PageSpeed Insights → все три метрики в зелёной зоне (mobile)
• Lighthouse в DevTools → score > 90 на mobile
• Сравнение до/после задокументировано
• GSC → Core Web Vitals → проверка через 4 недели
• Real User Monitoring (RUM) подключен (web-vitals.js или Vercel Analytics)

💡RUM лучше лабораторных тестов

PageSpeed даёт лабораторные значения (имитация устройства), а Google ранжирует по реальным данным CrUX. Установи библиотеку web-vitals.js и шли метрики в свою аналитику — увидишь данные с реальных устройств твоих пользователей.

Анти-паттерны

• ❌ Гнаться за PageSpeed 100/100 — теряешь UX-фичи (анимации, виджеты) ради «зелёных циферок». Цель — зелёная зона (> 75% URL), а не идеал.
• ❌ Тяжёлый chat-виджет на каждой странице — даже если оптимизировать всё остальное, Intercom/Crisp/Tawk.to съест INP. Лазь-лоадь после взаимодействия.
• ❌ Третьи стороны без аудита — Google Tag Manager сам по себе ОК, но если в нём 30 тегов — они синхронно блокируют. Аудит тегов раз в квартал.
• ❌ Игнор INP, фокус на LCP — раньше так и было (FID почти всегда зелёный). INP жёстче. Сейчас приоритет: INP > LCP > CLS.

Следующие шаги

• Технический аудит 2026 — общий фундамент
• Schema.org JSON-LD — структурированная разметка