Bcorrections

Core Web Vitals 2026: какие метрики реально важны

Обновлённый набор Core Web Vitals 2026 (LCP, INP, CLS) — что меряют, какие пороги, как улучшать и почему скорость загрузки в 2026 году важнее чем в 2020-м.

Core Web Vitals — набор метрик производительности сайтов, который Google использует как один из факторов ранжирования с 2021 года. К 2026 году метрики менялись несколько раз: исчез FID, появился INP, ужесточились пороги. И в очередной раз доказано: скорость загрузки сайта — это не только UX-метрика, но и прямой денежный фактор.

В этой статье — текущий набор Core Web Vitals 2026, актуальные пороги, и практические шаги по улучшению каждой метрики.

Текущий состав Core Web Vitals

С марта 2024 года Google официально заменил FID (First Input Delay) на INP (Interaction to Next Paint). Современный набор:

МетрикаЧто меряетХорошоТребует улучшенийПлохо
LCP (Largest Contentful Paint)Время до отрисовки самого крупного видимого элемента< 2.5 сек2.5–4.0 сек> 4.0 сек
INP (Interaction to Next Paint)Время отклика страницы на действие пользователя< 200 мс200–500 мс> 500 мс
CLS (Cumulative Layout Shift)Сдвиг элементов страницы во время загрузки< 0.10.1–0.25> 0.25

Сайт считается «прошедшим Core Web Vitals», если все три метрики на 75-м процентиле визитов попадают в зелёную зону. То есть для 75% посетителей все три показателя должны быть «хорошо». Это не равно «среднему» — это даже не равно «медиане». Это требование к большинству пользователей, в том числе на медленных устройствах.

Влияние на ранжирование

Прямое влияние Core Web Vitals на позиции в Google умеренное — это один из примерно 200 факторов ранжирования, и не из самых весомых. Но косвенное влияние огромное:

  • Pogosticking: пользователь открыл медленный сайт, не дождался загрузки, вернулся в выдачу и кликнул на конкурента. Поисковик это видит и понижает позиции.
  • Bounce rate: высокий показатель отказов из-за медленной загрузки → сигнал «контент не цепляет» → понижение.
  • Mobile-first индексация: на мобильных устройствах разница между быстрым и медленным сайтом гораздо заметнее, а Google индексирует именно мобильную версию.

В Яндексе влияние через те же поведенческие сигналы. Скорость загрузки не выделяется отдельным фактором, но через поведение это один из самых сильных косвенных рычагов.

Денежная сторона: исследования Google показывают, что замедление LCP с 1 до 3 секунд увеличивает bounce rate примерно на 32%. Для e-commerce это прямые потери выручки, для лидогенерации — потери заявок.

LCP: как улучшить

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

Топ-причины медленного LCP:

Большие неоптимизированные картинки

Самая частая причина в 2026 году. Hero-картинка весом 2 МБ — это +1.5 секунды к LCP на мобильном.

Решение:

  • Конвертация в WebP или AVIF (экономия 30–60% от JPEG/PNG)
  • Корректный srcset для responsive-изображений
  • fetchpriority="high" на главной hero-картинке (атрибут, поддерживаемый с 2023 года)
  • preload ключевых ресурсов в <head>

Render-blocking ресурсы

CSS и JS, загружающиеся в <head> без async/defer, блокируют рендеринг страницы до полной загрузки.

Решение:

  • Inline критического CSS (для above-the-fold блока) прямо в HTML
  • Остальной CSS подгружать асинхронно через <link rel="preload" as="style">
  • JS — defer или async где это безопасно

Медленный сервер

Если TTFB (Time to First Byte) > 600 мс, никакая клиентская оптимизация LCP в зелёную зону не вытянет.

Решение:

  • CDN для статических ресурсов
  • Edge caching для HTML (если контент позволяет)
  • Server-side рендеринг → static export где возможно (Next.js, Astro)
  • Оптимизация backend-запросов и БД

Замедление через сторонние скрипты

Аналитика, чаты, рекламные сети — все они тормозят страницу.

Решение:

  • Аудит сторонних скриптов — что реально нужно, что можно отключить
  • Загрузка через <script async> или <script defer>
  • Загрузка не-критичных скриптов через requestIdleCallback

INP: новая метрика взамен FID

INP заменил FID в марте 2024 года, и это была не косметика. FID мерял только первое взаимодействие (первый клик), INP — все взаимодействия в течение сессии. Это значительно более жёсткая метрика.

Что считается «interaction»:

  • Клик мышью или тап на тач-устройстве
  • Нажатие клавиши клавиатуры
  • Любое JS-событие, требующее ответа интерфейса

INP меряет от момента взаимодействия до следующего отрисованного кадра — то есть как быстро интерфейс отвечает.

Топ-причины плохого INP:

Тяжёлые JavaScript-задачи

Если onClick-обработчик блокирует main thread на 300+ мс — INP в красной зоне. В 2026 году с тяжёлыми React-приложениями это частая проблема.

Решение:

  • Разбиение длинных задач на куски через requestIdleCallback
  • Use server components / RSC для уменьшения объёма клиентского JS
  • Web Workers для тяжёлых вычислений
  • Profile в Chrome DevTools → Performance, поиск Long Tasks

Размер JS-бандла

Каждый дополнительный мегабайт JS — это лишнее время на парсинг, компиляцию, выполнение. К 2026 году типовой React-сайт легко набирает 2-4 МБ JS, и это слишком много.

Решение:

  • Code splitting по роутам (Next.js делает автоматически)
  • Tree shaking — удаление неиспользуемого кода
  • Lazy loading тяжёлых компонентов
  • Аудит зависимостей: «нужен ли нам действительно lodash целиком?»

Forced layouts / reflows

JS, который меняет DOM и сразу читает геометрию, заставляет браузер пересчитать всю компоновку синхронно.

Решение:

  • Group reads + writes (сначала прочитать все размеры, потом записать)
  • CSS contain: layout style для изолированных компонентов
  • transform и opacity для анимаций вместо top/left/width/height

CLS: визуальная стабильность

CLS показывает, насколько элементы страницы «прыгают» во время загрузки. Высокий CLS = пользователь промахивается мимо кнопок, читает шифтнутый текст, бесится.

Топ-причины высокого CLS:

Картинки без размеров

Если в HTML картинка без width и height, браузер не знает её размер до загрузки и выделяет 0 места. Потом, когда картинка загрузилась, элементы ниже сдвигаются.

Решение:

  • ВСЕГДА указывать width и height для всех картинок
  • Для responsive — использовать аспект-ratio CSS
  • Для Next.js — <Image> компонент с обязательным указанием размеров

Шрифты, подгружающиеся поздно

Загрузка кастомного шрифта приводит к тому, что текст сначала отображается системным, потом перерисовывается кастомным с другой шириной. Каждое такое перерисовывание — потенциальный CLS.

Решение:

  • font-display: optional или font-display: swap с FOUC fallback
  • size-adjust, ascent-override, descent-override в @font-face для подгонки fallback-шрифта под размеры кастомного
  • Hosting шрифтов на собственном сервере (не Google Fonts) для предсказуемой скорости

Реклама, чаты, баннеры

Поздно подгружающиеся внешние блоки выпрыгивают и двигают контент.

Решение:

  • Зарезервировать min-height для контейнера рекламы заранее
  • Не загружать above-the-fold баннеры из-за их CLS-вклада

Реальная история одного сайта

Типичный сценарий: интернет-магазин на готовом движке. До оптимизации:

  • LCP: 4.8 сек (мобильные)
  • INP: 380 мс
  • CLS: 0.18

После трёх недель работ (компоновка hero, lazy-loading картинок, code splitting, fixed sizes на всё):

  • LCP: 1.9 сек
  • INP: 145 мс
  • CLS: 0.04

Эффект на бизнес-метрики:

  • Bounce rate упал на 23%
  • Глубина просмотров выросла на 31%
  • Конверсия в добавление в корзину выросла на 18%
  • Позиции в Яндексе выросли по 60% от семантического ядра

И всё это — без единой новой страницы или ссылки. Просто компиляция кода и медиа.

Чек-лист аудита для 2026

  1. Открыть PageSpeed Insights на ключевых страницах (главная, услуги, статьи, корзина). Записать LCP, INP, CLS на мобильных.
  2. Если LCP > 2.5 сек — аудит изображений и render-blocking ресурсов.
  3. Если INP > 200 мс — Chrome DevTools Performance → поиск Long Tasks, аудит сторонних скриптов.
  4. Если CLS > 0.1 — аудит размеров изображений, шрифтов, динамически вставляемых блоков.
  5. Регулярный мониторинг в Google Search Console → Core Web Vitals (для индекса, по 28-дневному окну).
  6. Real User Monitoring (RUM) — установить инструмент типа Yandex Metrika Webvisor с записью метрик производительности или собственный сборщик. Лабораторные метрики (PageSpeed) часто отличаются от полевых на 30-50%.

Резюме

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

Если вы не уверены в текущих показателях вашего сайта или знаете о проблемах, но не понимаете куда копать — напишите нам. Бесплатный экспресс-аудит производительности за 2 рабочих дня.

Веб-разработка

Это часть нашей услуги Разработка сайтов

Сайты под ключ, сразу готовые к SEO и AI-поиску

Перейти к услуге →
Идём дальше?

Нужна пара экспертных глаз на ваш проект?

Делаем экспресс-аудит за 2 рабочих дня: показываем где сайт теряет трафик и что исправить в первую очередь.

Обсудить проект