Core Web Vitals 2026: LCP, INP, CLS Guide & Fixes

Только 42% веб-сайтов проходят все три порога Core Web Vitals. Это значит, что более половины интернета обеспечивает посредственный пользовательский опыт — и потенциально теряет позиции в поисковой выдаче. Если вы не пересматривали свою стратегию Core Web Vitals с тех пор, как Google заменил First Input Delay на Interaction to Next Paint в марте 2024 года, вы оптимизируете метрику, которой больше не существует. Вот всё, что изменилось, и как именно исправить каждую метрику в 2026 году.

Что такое Core Web Vitals в 2026 году — обновлённые пороговые значения и метрики

Core Web Vitals (CWV) — это стандартизированный набор из трёх метрик производительности от Google, которые измеряют реальный пользовательский опыт в интернете. Они напрямую влияют на систему ранжирования Google по качеству страниц и основаны на полевых данных, собранных от реальных пользователей Chrome через Chrome UX Report (CrUX). Не лабораторные симуляции — реальные визиты реальных людей на реальных устройствах.

По состоянию на 2026 год, три метрики Core Web Vitals и их пороговые значения:

Пороговые значения не менялись с момента введения INP, но общий процент прохождения немного вырос. Согласно данным HTTP Archive, доля источников, проходящих все три метрики, увеличилась примерно с 39% в начале 2024 года до приблизительно 42% к началу 2025 года. Прогресс есть, но медленный. Главным узким местом остаётся LCP — только около 53% источников укладываются в порог «хорошо», тогда как для CLS этот показатель составляет 92%, а для INP — 65%. Мобильная производительность отстаёт от десктопной на 10–15 процентных пунктов по всем метрикам, что крайне важно, учитывая, что Google использует mobile-first индексацию.

Понимание текущего положения каждой метрики — первый шаг. Следующий шаг — разобраться, что именно изменилось.

Что изменилось — INP заменил FID и новые API для измерений

Самый значительный сдвиг в ландшафте Core Web Vitals произошёл 12 марта 2024 года, когда INP официально заменил FID в качестве метрики отзывчивости. Это была не косметическая правка — а фундаментальное изменение того, что Google считает «интерактивностью».

FID измерял задержку только первого взаимодействия пользователя. Если ваша страница тормозила на десятом клике, но была быстрой на первом, FID это не волновало. INP измеряет задержку каждого взаимодействия на протяжении всего жизненного цикла страницы и отчитывается по худшему результату (технически — по 98-му перцентилю). Как сказал Барри Поллард из команды Google Chrome: «INP — гораздо более репрезентативная метрика реального пользовательского опыта, чем FID. FID измерял задержку только первого взаимодействия — INP фиксирует полную задержку всех взаимодействий, и именно это чувствуют пользователи».

Это важно, потому что многие сайты, которые легко проходили FID, теперь проваливают INP. Сторонние скрипты — аналитика, реклама, чат-виджеты — занимают примерно 57% времени выполнения JavaScript на среднестатистической странице согласно HTTP Archive Web Almanac, и они влияют на взаимодействия ещё долго после первоначальной загрузки страницы.

Помимо замены метрики, два важных изменения API влияют на диагностику проблем в 2026 году:

• Long Animation Frames (LoAF) API заменил Long Tasks API в качестве рекомендуемого инструмента для отладки INP. LoAF предоставляет детальные данные атрибуции, показывающие, какие именно скрипты вызывают медленные кадры, что делает его гораздо более практичным.
• Измерение CLS использует сессионные окна — подход с паузой в 1 секунду и ограничением в 5 секунд, который точнее отражает воспринимаемую пользователем нестабильность макета. Это изменение перестало несправедливо штрафовать долгоживущие одностраничные приложения.

Кроме того, Speculation Rules API для предварительного рендеринга и предзагрузки значительно развился в Chrome 121+, позволяя почти мгновенно загружать последующие страницы, что фактически обнуляет LCP, INP и CLS при навигации.

Как исправить LCP — оптимизация Largest Contentful Paint

LCP — самая сложная для прохождения метрика Core Web Vitals, а медианное значение LCP на мобильных устройствах составляет примерно 3,4 секунды по всему миру — значительно выше порога «хорошо» в 2,5 секунды, согласно данным HTTP Archive по скорости загрузки. Поскольку изображения составляют примерно 72% элементов LCP в интернете согласно главе Web Almanac о производительности, оптимизация изображений — ваш самый эффективный рычаг.

Вот список приоритетов для оптимизации LCP:

1. Правильно отметьте LCP-изображение. Добавьте fetchpriority="high" к LCP-элементу и никогда не используйте loading="lazy" для него. Собственные A/B-тесты Google показывают, что fetchpriority="high" улучшает LCP на 5–12% на крупных сайтах.

2. Сделайте LCP-ресурс обнаруживаемым в HTML. Если LCP-изображение задано через CSS background-image или внедряется через JavaScript, браузер не сможет найти его при первичном парсинге HTML. Либо переместите изображение в тег <img>, либо добавьте подсказку для предзагрузки:

<head>
  <!-- Предзагрузка LCP-изображения, чтобы браузер обнаружил его немедленно -->
  <link rel="preload" href="/hero.avif" as="image" 
        fetchpriority="high" type="image/avif">

  <!-- Используйте Speculation Rules для мгновенных последующих навигаций -->
  <script type="speculationrules">
  {
    "prerender": [
      { "where": { "href_matches": "/*" }, "eagerness": "moderate" }
    ]
  }
  </script>
</head>

<body>
  <img src="/hero.avif" alt="Hero" width="1200" height="600"
       fetchpriority="high" decoding="async">
</body>

3. Сократите время ответа сервера. Стремитесь к Time to First Byte (TTFB) менее 200 мс. Используйте CDN, включите кэширование на edge-серверах и рассмотрите потоковый серверный рендеринг через фреймворки вроде Next.js 14+ или Astro.

4. Устраните ресурсы, блокирующие рендеринг. Встройте критический CSS инлайн, отложите загрузку некритичных стилей и переместите скрипты в конец страницы или добавьте атрибуты defer/async.

5. Используйте современные форматы изображений. AVIF обеспечивает файлы на 30–50% меньше, чем WebP, и значительно лучшее сжатие по сравнению с JPEG. Используйте цепочку fallback AVIF → WebP → JPEG через <picture> или согласование контента на уровне CDN.

Как исправить INP — лучшие практики Interaction to Next Paint

INP — это метрика, с которой большинство сайтов испытывают наибольшие трудности в 2026 году, потому что она вскрывает проблему, которая всегда существовала, но раньше оставалась невидимой: главный поток перегружен. Каждый клик, касание или нажатие клавиши конкурирует с выполнением JavaScript, и если браузер занят длительной задачей, взаимодействие пользователя вынуждено ждать.

Самая эффективная стратегия — разбиение длительных задач, чтобы браузер мог обрабатывать пользовательский ввод между фрагментами работы. Современный способ сделать это — scheduler.yield(), доступный в Chrome 129+:

async function handleUserClick(event) {
  // Немедленная визуальная обратная связь — укладывайтесь в 50 мс
  updateButtonState(event);

  // Уступаем управление, чтобы браузер отрисовал изменения и обработал другой ввод
  if ('scheduler' in window && 'yield' in scheduler) {
    await scheduler.yield();
  } else {
    await new Promise(resolve => setTimeout(resolve, 0));
  }

  // Продолжаем с неприоритетной работой
  sendAnalyticsEvent(event);
  await scheduler.yield();
  updateSecondaryContent(event);
}

Помимо разбиения задач через yield, вот ключевые стратегии для INP:

• Безжалостно проверяйте сторонние скрипты. Используйте LoAF API в панели Performance Chrome DevTools, чтобы определить, какие скрипты больше всего блокируют взаимодействия. Откладывайте, удаляйте или переносите тяжёлые скрипты — чат-виджеты, аналитику — в Web Workers с помощью инструментов вроде Partytown.
• Снижайте стоимость гидратации. Если вы используете React, Vue или Angular, процесс гидратации может блокировать главный поток на сотни миллисекунд. Рассмотрите частичную гидратацию, архитектуру островов (Astro) или React Server Components, чтобы отправлять меньше JavaScript на клиент.
• Используйте content-visibility: auto для секций за пределами видимой области. Это указывает браузеру пропустить рендеринг невидимого контента, освобождая главный поток для обработки взаимодействий.
• Выносите вычисления из главного потока. Web Workers могут выполнять обработку данных, сортировку, фильтрацию и другие ресурсоёмкие операции, не блокируя пользовательский ввод.

Цель проста: ни одна задача в главном потоке не должна выполняться дольше 50 миллисекунд. Если выполняется — разбивайте её.

Как исправить CLS — предотвращение сдвигов макета раз и навсегда

CLS имеет самый высокий показатель прохождения среди трёх Core Web Vitals — 92%, но сайты, которые его проваливают, часто проваливают его сильно — а сдвиги макета являются одним из самых раздражающих аспектов пользовательского опыта в интернете. Страница, которая «прыгает», пока вы пытаетесь читать или нажать кнопку, мгновенно подрывает доверие.

Обновлённый подход измерения через сессионные окна (пауза 1 секунда, ограничение 5 секунд) означает, что CLS теперь более справедливо отражает восприятие пользователей. Как объяснила Энни Салливан из команды Chrome Speed Metrics: «Оконный подход измеряет то, что пользователи действительно воспринимают как нестабильность», а не несправедливо накапливает мелкие сдвиги за долгие сессии.

Вот исправления в порядке убывания эффекта:

1. Всегда задавайте явные размеры для медиаэлементов. Каждый <img>, <video> и <iframe> должен иметь атрибуты width и height. Браузер использует их для расчёта соотношения сторон и резервирования места до загрузки ресурса.

<!-- Хорошо: размеры предотвращают сдвиг макета -->
<img src="/photo.webp" alt="Product" width="800" height="600">

<!-- Тоже хорошо: CSS aspect-ratio как запасной вариант -->
<style>
  .video-wrapper { aspect-ratio: 16 / 9; }
</style>

2. Резервируйте место для динамического контента. Реклама, баннеры согласия на cookie и панели уведомлений — главные виновники. Используйте min-height на контейнерах, где появится динамический контент. Если вы внедряете рекламу через JavaScript, задайте размеры контейнера до загрузки рекламного блока.

3. Правильно работайте с веб-шрифтами. Смена шрифта вызывает мигание невидимого текста (FOIT) или мигание неоформленного текста (FOUT), и то и другое провоцирует сдвиги макета. Используйте font-display: optional, чтобы полностью предотвратить сдвиги, или предзагружайте самые важные файлы шрифтов с помощью <link rel="preload" as="font" crossorigin>.

4. Отдавайте предпочтение анимациям на основе transform. CSS-свойства top, left, width и height запускают перерасчёт макета. Используйте вместо них transform: translateX() или transform: scale() — эти свойства обрабатываются на GPU и никогда не вызывают сдвигов макета.

5. Избегайте вставки контента выше существующего. Если вам нужно показать баннер или уведомление, накладывайте его поверх страницы (используя position: fixed), а не сдвигайте существующий контент вниз.

Инструменты для измерения и мониторинга Core Web Vitals

Нельзя улучшить то, что не измеряешь, а в случае Core Web Vitals существует принципиальное различие между полевыми данными (реальные пользовательские метрики из CrUX) и лабораторными данными (синтетические тесты из Lighthouse). Сигнал ранжирования Google использует исключительно полевые данные, поэтому именно они — ваш источник истины.

Основные бесплатные инструменты:

• PageSpeed Insights — Отправная точка. Показывает как полевые данные CrUX, так и лабораторные данные Lighthouse для любого URL. Секция полевых данных вверху — это то, что влияет на ваши позиции в поиске.
• Chrome UX Report (CrUX) — Исходный набор данных, лежащий в основе PageSpeed Insights. Доступ через BigQuery для массового анализа или через CrUX API для программных проверок. Данные на уровне источника обновляются ежемесячно.
• Панель Performance в Chrome DevTools — Ваш отладочный командный центр. Версия 2025+ включает атрибуцию INP на основе LoAF, показывающую, какой именно скрипт вызвал медленное взаимодействие и сколько длилась каждая фаза (задержка ввода, обработка, задержка отрисовки).
• web-vitals.js — Официальная JavaScript-библиотека Google для измерения CWV в полевых условиях. Добавьте её на свой сайт для сбора реальных пользовательских данных и отправки их в вашу аналитическую платформу.
• Расширение Web Vitals для Chrome — Показывает оверлей в реальном времени с LCP, INP и CLS во время просмотра, что упрощает обнаружение проблем при ручном тестировании.

Платные инструменты мониторинга, заслуживающие внимания:

• DebugBear — Непрерывный синтетический мониторинг с интеграцией CrUX, идеален для отслеживания трендов CWV во времени.
• SpeedCurve — Сочетает синтетическое тестирование с мониторингом реальных пользователей (RUM) и предлагает конкурентный бенчмаркинг.
• WebPageTest — Глубокий анализ каскадных диаграмм с покадровым просмотром, незаменим для диагностики сложных проблем с LCP.
• Calibre — Бюджеты производительности и система оповещений, полезен для обнаружения регрессий в CI/CD-пайплайнах.

Рекомендуемый рабочий процесс: используйте PageSpeed Insights для быстрой проверки, CrUX для отслеживания трендов и Chrome DevTools для глубокой отладки при проваленной метрике.

Core Web Vitals и SEO — насколько сильно они влияют на ранжирование?

Давайте ответим на вопрос, который задаёт каждый SEO-специалист: насколько Core Web Vitals реально влияют на позиции в поиске? Честный ответ — это реальный сигнал, но не доминирующий.

Собственная документация Google говорит об этом прямо: «Core Web Vitals — один из множества сигналов, которые используют наши системы ранжирования. Отличный пользовательский опыт на странице не перевешивает наличие качественного и релевантного контента. Однако при наличии нескольких страниц с сопоставимой релевантностью пользовательский опыт на странице может стать гораздо более важным фактором для видимости в Поиске».

На практике CWV работает как решающий фактор при прочих равных. Если качество и релевантность вашего контента сопоставимы с конкурентами, лучшие показатели Core Web Vitals могут вывести вас вперёд. В конкурентных выдачах — особенно в электронной коммерции, медиа и локальных сервисах — эти marginal gains накапливаются.

Однако бизнес-эффект выходит далеко за рамки ранжирования. Исследование Google показывает, что пользователи на страницах, проходящих все Core Web Vitals, на 24% реже покидают их до завершения загрузки. Кейсы Vodafone, Agrofy и NDTV, опубликованные на web.dev, демонстрируют улучшение конверсии из поиска на 15–20% после перехода CWV из категории «плохо» в «хорошо».

Таким образом, хотя CWV сами по себе не катапультируют страницу с тонким контентом на первую позицию, совокупный эффект от лучших позиций, сниженного показателя отказов и более высокой конверсии делает оптимизацию более чем оправданной. Сайты, которые относятся к производительности как к продуктовой функции, а не просто к галочке в SEO-чеклисте, стабильно опережают тех, кто этого не делает.

Следующие шаги — проведите аудит Core Web Vitals уже сегодня

Вот ваш план действий:

1. Проведите проверку CrUX прямо сейчас. Откройте PageSpeed Insights, введите свой URL и посмотрите на секцию полевых данных. Если какая-либо метрика жёлтая или красная, вы теперь точно знаете, к какому разделу этого руководства обращаться.
2. В первую очередь займитесь LCP — у этой метрики самый низкий показатель прохождения и наибольшее влияние на воспринимаемую скорость. Начните с hero-изображения: добавьте fetchpriority="high", убедитесь, что оно в современном формате, и при необходимости настройте предзагрузку.
3. Проведите аудит JavaScript для INP. Откройте Chrome DevTools, перейдите в панель Performance, повзаимодействуйте со страницей и найдите длинные кадры анимации. Сторонние скрипты почти наверняка будут вашим главным виновником.
4. Задайте размеры для каждого медиаэлемента, чтобы предотвратить CLS. Это самое простое исправление в списке, и зачастую оно занимает менее часа.
5. Настройте непрерывный мониторинг. Добавьте web-vitals.js на сайт и направьте данные в вашу аналитику. Регрессии CWV происходят постепенно — к тому моменту, когда вы заметите их в CrUX, вы уже потеряете месяц данных.

Core Web Vitals никуда не денутся, и планка будет только расти по мере того, как всё больше сайтов оптимизируются. Хорошая новость: каждое улучшение, которое вы вносите, приносит пользу и вашей видимости в поиске, и опыту ваших пользователей. Это редкое совпадение интересов в SEO.

Хотите увидеть, как именно обстоят дела с вашим сайтом по всем трём Core Web Vitals — с приоритизированными и практичными рекомендациями? Запустите бесплатный аудит на checkseo.site и получите чёткий план действий по исправлению LCP, INP и CLS раньше ваших конкурентов.