Core Web Vitals: улучшение показателей и почему это влияет на позиции в 2026
Core Web Vitals — три метрики, которые Google использует в алгоритме ранжирования с 2021 года. К 2026 году сайты с плохими показателями системно проигрывают конкурентам в выдаче, даже при сопоставимом контенте. Это не косметика, а инфраструктурный вопрос, влияющий на видимость в поиске.
Три метрики Core Web Vitals и их пороги
LCP (Largest Contentful Paint) — скорость загрузки главного контента. Порог: ≤ 2,5 сек. Измеряется от начала навигации до момента, когда на экран попадает самый крупный видимый элемент (изображение, видео, текстовый блок).
INP (Interaction to Next Paint) — отклик на действия пользователя. Заменил FID в 2024 году. Порог: ≤ 200 мс. Измеряет задержку между кликом/тапом и визуальным ответом страницы.
CLS (Cumulative Layout Shift) — стабильность вёрстки. Порог: ≤ 0,1. Суммирует все неожиданные сдвиги элементов во время загрузки страницы.
Google собирает реальные данные через Chrome User Experience Report (CrUX) — это метрики от миллионов пользователей Chrome, а не лабораторные симуляции.
LCP: как ускорить загрузку главного контента
Три основные причины высокого LCP:
1. Тяжёлые изображения без оптимизации. Формат WebP вместо JPEG/PNG снижает вес на 25–34%. Атрибут loading="eager" для hero-изображения обязателен, иначе браузер откладывает загрузку. Исследование HTTP Archive показало, что медиа-ресурсы составляют 50–60% от общего размера страницы.
2. Медленный TTFB (Time to First Byte). Если сервер отвечает дольше 800 мс, LCP никогда не будет зелёным. Решение — CDN, кэширование на уровне сервера, оптимизация запросов к БД. На сайтах с TTFB > 1 сек LCP редко опускается ниже 3 сек.
3. Блокирующие ресурсы. CSS и JS, загружаемые в <head> без defer или async, задерживают рендеринг. Критический CSS нужно инлайнить, остальное — откладывать. Каждый блокирующий скрипт добавляет 100–300 мс к LCP.
PageSpeed Insights покажет конкретные причины торможения. Проверяйте отдельно для мобильных — там пороги жёстче из-за медленных соединений.
INP: почему сайт «тупит» при кликах
INP измеряет задержку между действием пользователя и визуальным ответом. Порог 200 мс — граница, выше которой человек чувствует торможение.
Основные причины высокого INP:
- •Тяжёлые JavaScript-обработчики событий блокируют главный поток браузера. Длинные задачи (Long Tasks > 50 мс) замораживают интерфейс.
- •Сторонние скрипты (чаты, пиксели, аналитика) — каждый добавляет 20–150 мс. WebAIM обнаружил, что средний сайт загружает 50+ сторонних скриптов.
- •Неоптимизированные компоненты React/Vue с лишними ре-рендерами. Компонент, который ре-рендерится без необходимости, может добавить 100–500 мс к INP.
Диагностика: Chrome DevTools → Performance → запишите сессию с кликами. Красные полосы (Long Tasks) — первые кандидаты на оптимизацию.
CLS: когда вёрстка «прыгает»
CLS выше 0,1 — это когда пользователь тянется к кнопке, а она уезжает вниз из-за подгрузившегося баннера. Это снижает конверсии и увеличивает отказы.
Практические решения:
- •Задайте размеры всем медиа-элементам — атрибуты
widthиheightу изображений и видео обязательны. Это резервирует место до загрузки. - •Резервируйте место под рекламу и виджеты через
min-heightдо их загрузки. - •Избегайте динамической вставки контента выше видимой области без явного триггера пользователя.
- •Шрифты: используйте
font-display: swapи предзагружайте критические шрифты через<link rel="preload">. Это предотвращает FOUT (Flash of Unstyled Text).
Инструменты для диагностики
- •PageSpeed Insights — лабораторные данные с конкретными рекомендациями
- •Google Search Console → Core Web Vitals — реальные данные CrUX по вашему сайту
- •Lighthouse в Chrome DevTools — детальный аудит с разбивкой по причинам
- •WebPageTest — расширенное тестирование с waterfall-диаграммой и видео загрузки
Часто задаваемые вопросы
Насколько сильно Core Web Vitals влияют на позиции?
Google называет их «tiebreaker» — когда два сайта равны по контенту и ссылкам, побеждает тот, у кого лучше пользовательский опыт. На практике разница в LCP на 1–2 секунды может стоить 3–5 позиций в конкурентных нишах. Это не единственный фактор, но игнорировать его — значит играть с форой у конкурента.
Можно ли улучшить Core Web Vitals на WordPress или Tilda?
Частично — через плагины кэширования и оптимизации изображений. Но архитектурные ограничения этих платформ не позволяют стабильно держать зелёные метрики на сложных сайтах. Поэтому мы не пересаживаем чужой WordPress или Tilda, а строим новые сайты на собственном стеке Next.js + Vercel, где зелёные Core Web Vitals — из коробки.
Как часто нужно проверять Core Web Vitals?
Минимум раз в месяц через Google Search Console. После каждого крупного обновления сайта — обязательно. CrUX обновляется каждые 28 дней, поэтому улучшения отразятся в данных не мгновенно.
LCP в PageSpeed Insights «зелёный», но в Search Console — «требует улучшения». Почему?
PageSpeed Insights показывает лабораторные данные (симуляция на десктопе), Search Console — реальные данные CrUX с реальных устройств. Мобильные устройства с медленным соединением (3G, 4G) дают другую картину. Ориентируйтесь на Search Console — это то, что видит Google.
Влияют ли Core Web Vitals на Яндекс?
Яндекс не использует CrUX и не декларирует CWV как прямой фактор ранжирования. Но скорость загрузки и поведенческие факторы (отказы, время на сайте) влияют на позиции косвенно. Оптимизируя под Google CWV, вы автоматически улучшаете поведенческие метрики — это работает для обоих поисковиков.
Именно поэтому мы строим сайты на Next.js + Vercel: PageSpeed 95+ из коробки, тогда как у конкурентов на WordPress и Битрикс типично 30–60. На СпецГидроТех это дало 1065 проиндексированных страниц за 2 месяца и 55% трафика из органики, а Влобовик с быстрой базой получил 647 визитов и 87 обращений в первый месяц.