Core Web Vitals : оптимизация скорости и UX
8 min
Core Web Vitals (LCP, INP, CLS) — официальные факторы ранжирования в Google. Хорошие пороги : LCP менее 2,5 с, INP менее 200 мс, CLS менее 0,1. Абсолютный приоритет : оптимизация изображений и откладывание некритичного JavaScript.
С 2021 года Google включает Core Web Vitals в алгоритм ранжирования. В 2026 году эти метрики влияют не только на позиции, но и на право показа расширенных результатов на мобильных устройствах. Разберёмся, как ими управлять.
Три метрики, которые действительно важны
Google выбрал три сигнала для измерения реального пользовательского опыта : LCP (Largest Contentful Paint), INP (Interaction to Next Paint) и CLS (Cumulative Layout Shift). Каждый из них измеряет отдельный аспект воспринимаемого качества.
INP заменил FID в марте 2024 года — он измеряет общую отзывчивость на все взаимодействия со страницей, тогда как FID фиксировал только первый клик.
- LCP : время до отрисовки самого крупного видимого элемента. Хороший порог : менее 2,5 с.
- INP : задержка ответа на взаимодействия клавиатуры/мыши/тач. Хороший порог : менее 200 мс.
- CLS : визуальная нестабильность макета. Хороший порог : менее 0,1.
Частые причины низкой производительности
Плохой LCP чаще всего вызван неподгруженным заранее главным изображением, медленным сервером или клиентским рендерингом (отсутствие SSR). Тег <link rel="preload">, нацеленный на главное изображение, нередко улучшает этот показатель на 30–50 %.
CLS почти всегда обусловлен изображениями без явных размеров, веб-шрифтами, отображаемыми после загрузки, или баннерами, динамически вставляемыми в верхнюю часть страницы.
Для INP главными виновниками являются сторонние скрипты (аналитика, чат, реклама), блокирующие основной поток и задерживающие ответ на клики.
Страницы, достигающие «хороших» порогов по всем трём метрикам, показывают показатель отказов на 15–25 % ниже, чем страницы с «плохими» оценками.
Отраслевые исследования 2025–2026 года по пользовательскому опыту в вебе
План действий по приоритетности
Начните с измерения данных о реальных пользователях в Google Search Console (отчёт «Удобство страниц»), а не лабораторных данных : только данные CrUX влияют на ранжирование.
Определив приоритетные страницы, действуйте в следующем порядке : сжатие и изменение размеров изображений, активация долгосрочного кэша браузера, затем аудит и откладывание сторонних скриптов.
- Отдавать изображения в формате WebP или AVIF с адаптивным srcset.
- Активировать сжатие Brotli на сервере и CDN для снижения TTFB.
- Использовать font-display: swap и предзагружать основной шрифт.
- Проверить каждый сторонний скрипт и загружать его в режиме defer или async.
Постоянный мониторинг
Core Web Vitals меняются с каждым деплоем. Интегрируйте Lighthouse CI в пайплайн развёртывания, чтобы выявлять регрессии до выхода в продакшн.
Настройте оповещения в Search Console или через API CrUX, чтобы получать уведомления, когда URL переходит в зону «требует улучшения» или «плохо».
FAQ
Являются ли Core Web Vitals важным фактором ранжирования ?
Google характеризует их как «слабый сигнал ранжирования» по сравнению с релевантностью контента. Они могут сыграть решающую роль между двумя страницами одинакового качества, но никогда не компенсируют слабый контент.
Измерять метрики на мобильных или на десктопе ?
Google использует преимущественно мобильные данные в рамках mobile-first индексации. Сосредоточьте усилия на мобильных устройствах, даже если большая часть вашего трафика приходит с десктопа.
Достаточно ли PageSpeed Insights для аудита Core Web Vitals ?
PageSpeed Insights показывает как лабораторные данные (симуляция), так и данные о реальных пользователях CrUX, если трафик достаточен. Для полного аудита сочетайте его с Search Console и расширением Chrome Web Vitals.
Сколько времени до появления эффекта на позиции после исправления ?
Google обновляет данные CrUX ежемесячно. Улучшения, внесённые сегодня, как правило, отражаются в ранжировании через четыре–восемь недель.