- Что такое Core Web Vitals и зачем они нужны
- Три метрики 2026 года: LCP, INP, CLS
- Как проверить Core Web Vitals сайта
- Как улучшить LCP (скорость загрузки)
- Как улучшить INP (отзывчивость)
- Как исправить CLS (стабильность)
- Core Web Vitals для WordPress-сайтов
- Частые ошибки при оптимизации
- FAQ: ответы на частые вопросы
- Итог и чек-лист
1. Что такое Core Web Vitals и зачем они нужны
Core Web Vitals — это три метрики, которыми Google измеряет реальный пользовательский опыт на сайте: скорость загрузки контента, отзывчивость на действия пользователя и визуальную стабильность страницы при рендеринге. Они являются частью более широкого сигнала page experience и учитываются в ранжировании с июня 2021 года.
Важно: Core Web Vitals не считаются синтетически (например, в Lighthouse). Google берёт данные Chrome User Experience Report (CrUX) — это анонимная статистика реальных посещений из браузера Chrome. Сайт считается «хорошим» по метрике, если 75% визитов укладываются в нужный порог. Это называется 75-я перцентиль.
Почему это важно для SEO в 2026 году
- В марте 2026 Google усилил вес производительности в алгоритме — сайты, проходящие пороги, получают прирост позиций, не проходящие — просадку
- Core Web Vitals — это tiebreaker: при равном качестве контента Google отдаёт предпочтение более быстрому сайту
- Плохие метрики напрямую влияют на бизнес: каждая секунда задержки сверх LCP 2.5 секунды увеличивает показатель отказов на 32%
- Мобильные показатели Google использует как основной сигнал — даже для десктопного ранжирования
Страницы со временем загрузки до 2 секунд имеют показатель отказов около 9%. При загрузке 5+ секунд отказы достигают 38%. Для интернет-магазина это прямая потеря выручки: 1 секунда задержки снижает конверсию в покупку на 7%.
2. Три метрики 2026 года: LCP, INP, CLS
Раньше Core Web Vitals включали LCP, FID и CLS. В марте 2024 года Google окончательно заменил FID (First Input Delay) на INP (Interaction to Next Paint) — более точную метрику отзывчивости. В 2026 году именно INP — самая проблемная из трёх: её не проходят около 43% сайтов в мире.
| Метрика | Что измеряет | Хорошо | Плохо |
|---|---|---|---|
| LCP (Largest Contentful Paint) | Время до отрисовки главного элемента страницы (картинка, заголовок, видео) | ≤ 2,5 сек | > 4,0 сек |
| INP (Interaction to Next Paint) | Время отклика на действия пользователя (клики, тапы, ввод) | ≤ 200 мс | > 500 мс |
| CLS (Cumulative Layout Shift) | Суммарное смещение элементов страницы во время загрузки | ≤ 0,1 | > 0,25 |
Что нужно знать о различиях
- LCP обычно упирается в картинки, шрифты, медленный хостинг, блокирующий CSS/JS. Чаще страдают главные страницы и посты блога с большими hero-изображениями
- INP — про JavaScript: тяжёлые обработчики событий, блокировка главного потока, избыточные скрипты. Страдают формы, фильтры, корзины интернет-магазинов, интерактивные элементы
- CLS — про визуальную стабильность: баннеры без размеров, динамически подгружающиеся рекламные блоки, шрифты без fallback. Страдают любые страницы с отложенной загрузкой контента
3. Как проверить Core Web Vitals сайта
Есть несколько инструментов для проверки. Лучше использовать комбинацию: один показывает полевые данные от реальных пользователей, другой — синтетические для диагностики.
PageSpeed Insights
pagespeed.web.dev — бесплатный инструмент от Google. Показывает полевые данные CrUX (если сайт в них есть) и синтетический Lighthouse-тест. Лучшая отправная точка для любого анализа.
Google Search Console
Раздел «Опыт работы» → «Основные интернет-показатели». Показывает проблемные URL-группы по всему сайту. Данные обновляются с задержкой 28 дней (скользящее окно).
Web Vitals Extension
Расширение для Chrome от Google. Показывает LCP, INP и CLS в реальном времени при просмотре любой страницы. Удобно для быстрой проверки отдельных URL.
Chrome DevTools
Вкладка Performance в инструментах разработчика (F12). Показывает детальную раскладку по всем событиям рендеринга. Используется для глубокой диагностики INP.
DebugBear / SpeedCurve
Платные сервисы для постоянного мониторинга. Алерты при ухудшении метрик, история изменений, сравнение с конкурентами. Для крупных проектов обязательная вещь.
CrUX Dashboard
Бесплатный дашборд на основе публичных данных CrUX. Показывает динамику метрик вашего сайта за несколько месяцев и позволяет сравнивать с другими доменами.
Всегда проверяйте в первую очередь мобильные данные. В 2026 году 60%+ поисковых запросов идут с мобильных устройств, и Google использует именно мобильные показатели как основной ранжирующий сигнал. Сайт может идеально работать на MacBook, но проваливаться на среднем Android-смартфоне с 4G.
4. Как улучшить LCP (скорость загрузки)
LCP зависит от четырёх вещей: время ответа сервера, блокирующие ресурсы (CSS/JS), скорость загрузки LCP-элемента (обычно картинки) и время рендеринга. Работаем по каждому пункту.
Ускорьте ответ сервера (TTFB)
Сервер должен отдавать HTML быстрее 600 мс. Если дольше — меняйте хостинг, включайте серверное кэширование, используйте CDN (Cloudflare, BunnyCDN). Для WordPress обязательны плагины WP Rocket или LiteSpeed Cache.
Оптимизируйте главное изображение
Используйте современные форматы WebP и AVIF — они весят на 30–50% меньше JPEG/PNG. Задавайте точный размер изображения с помощью srcset и sizes. Для hero-картинки используйте <link rel=»preload» as=»image»> в head.
Уберите блокирующие CSS и JS
Критический CSS (для первого экрана) встраивайте прямо в HTML. Остальной CSS — асинхронно через media=»print» onload. JavaScript помечайте атрибутами async или defer, чтобы он не блокировал рендеринг.
Не ленитесь с ленивой загрузкой
loading=»lazy» — только для изображений ниже первого экрана. Если применить к hero-картинке, LCP ухудшится в разы. Для LCP-элемента используйте fetchpriority=»high».
Уберите лишние шрифты
Каждый кастомный шрифт — это дополнительная задержка. Ограничьтесь 1–2 шрифтами и используйте font-display: swap, чтобы текст появлялся с системным шрифтом, пока грузится кастомный.
5. Как улучшить INP (отзывчивость)
INP — самая сложная метрика в 2026 году. Её невозможно починить одним плагином или сжатием картинки. Нужно менять архитектуру JavaScript. Главная причина плохого INP — долгие задачи в основном потоке браузера, которые блокируют отклик на действия пользователя.
Что делать на уровне кода
- Разбивайте длинные задачи. Любая задача в main thread, которая занимает больше 50 мс, — это риск плохого INP. Используйте setTimeout, requestIdleCallback или scheduler.yield() для передачи управления браузеру
- Дебаунс и тротлинг. Обработчики событий input, scroll, resize должны запускаться не на каждое событие, а раз в 100–200 мс. Без дебаунса любой ввод в поле поиска может поднять INP до 500+ мс
- Минимизируйте сторонние скрипты. Чат-виджеты, счётчики, трекеры — главные виновники плохого INP. Проверьте, какие реально нужны, остальные отключайте или загружайте после взаимодействия
- Упрощайте DOM. Страницы с 3000+ узлов в DOM дают долгие циклы рендеринга. Оптимальный размер — до 1500 узлов
- Код-сплиттинг. Для React/Vue/Angular разбивайте бандлы по маршрутам, чтобы на каждой странице грузился только нужный JS
Большинство WordPress-плагинов для «оптимизации скорости» улучшают только LCP (кэш, сжатие картинок) и никак не трогают INP. Для INP нужно отключать тяжёлые сторонние скрипты (чаты, попапы, трекеры) и дорабатывать тему. Универсальной кнопки «починить INP» не существует.
6. Как исправить CLS (стабильность)
CLS — самая простая из трёх метрик. Её можно починить без глубокого программирования, просто проставив размеры элементов.
Обязательные правила
- Все изображения с атрибутами width и height. Даже если размеры задаются через CSS, в HTML должны быть width и height — браузер резервирует место
- Фиксированные размеры для видео и iframe. То же правило, что и для картинок
- Резервирование места под рекламу и виджеты. Если блок 300×250 — оборачиваете его в div с min-height: 250px
- font-display: swap + fallback-шрифт. Текст не «прыгает» при подгрузке кастомного шрифта — он сразу появляется с fallback, потом плавно заменяется
- Никакого контента, вставляемого выше существующего. Баннеры, кнопки «согласиться с cookie», уведомления — только поверх контента (position: fixed) или в зарезервированных блоках
Если у вас WordPress и сайт «прыгает» при загрузке — почти всегда виноваты рекламные блоки, поп-апы и изображения без размеров. Начинайте диагностику с них. Chrome DevTools → Performance → Layout Shifts покажет конкретные элементы, которые дают сдвиги.
7. Core Web Vitals для WordPress-сайтов
WordPress — самая распространённая CMS, и для неё наработано много решений по оптимизации. Базовый набор плагинов и настроек закрывает 80% проблем с Core Web Vitals.
| Инструмент | Что закрывает |
|---|---|
| WP Rocket (платный) | Кэширование, lazy-load, минификация CSS/JS, критический CSS, WebP-конвертация |
| LiteSpeed Cache (бесплатный) | Всё то же, но только на хостингах с LiteSpeed Server (у многих казахстанских провайдеров есть) |
| ShortPixel / Imagify | Автоматическое сжатие картинок и конвертация в WebP/AVIF |
| Autoptimize | Минификация CSS/JS, инлайн критического CSS — если не пользуетесь WP Rocket |
| Cloudflare (бесплатный план) | CDN для статики, HTTPS, защита от ботов — серьёзно ускоряет TTFB |
Базовый план оптимизации для WordPress
- Установите кэширующий плагин и включите все рекомендованные настройки
- Подключите CDN (Cloudflare бесплатный план закрывает большинство задач)
- Сконвертируйте все картинки в WebP, удалите оригиналы PNG/JPEG после проверки
- Отключите неиспользуемые плагины — каждый добавляет JS и CSS
- Проверьте тему на тяжесть: если главная страница весит 3+ МБ, меняйте тему на более лёгкую (GeneratePress, Kadence, Astra)
- Удалите лишние встроенные шрифты Google Fonts, оставьте 1–2
- Отключите эмодзи и встраивания WordPress, если не используете (Disable Embeds + Disable Emojis)
8. Частые ошибки при оптимизации
Ошибка 1. Гоняться за 100/100 в Lighthouse
Lighthouse — синтетический тест, а Google ранжирует по полевым данным CrUX. Идеальный Lighthouse не гарантирует хорошие Core Web Vitals. Правильный путь: смотреть Search Console → «Основные интернет-показатели» и полевые данные в PageSpeed Insights.
Ошибка 2. Оптимизировать только десктоп
Google использует мобильные метрики как основной сигнал. Если мобильный LCP 4 секунды, а десктопный 2 секунды — вы не проходите по Core Web Vitals. Начинайте оптимизацию с мобильной версии.
Ошибка 3. Игнорировать INP
Многие SEO-специалисты до сих пор работают по старой схеме: ускорил загрузку — и готово. В 2026 году именно INP чаще всего становится причиной просадки. Минимум раз в месяц смотрите отчёт по INP в Search Console.
Ошибка 4. Оптимизировать одну страницу вместо группы
Google ранжирует URL-группы, а не отдельные страницы. Если главная загружается идеально, а 500 страниц блога — плохо, сайт всё равно получит минус в ранжировании. Оптимизация должна быть системной, а не точечной.
Ошибка 5. Отключать всё без разбора
«Отключили все плагины, удалили аналитику, убрали шрифты — стало быстрее». Да, но бизнесу это не нужно. Правильный путь: найти медленные компоненты и заменить их на лёгкие альтернативы, а не вырезать функционал.
9. FAQ: ответы на частые вопросы
Насколько сильно Core Web Vitals влияют на ранжирование?
Это один из многих сигналов. Сами по себе Core Web Vitals не перевесят плохой контент или отсутствие ссылок. Но при сопоставимом качестве контента быстрый сайт получит преимущество. В конкурентных нишах это решающий фактор.
Можно ли пройти Core Web Vitals на дешёвом хостинге?
Сложно. Дешёвый shared-хостинг часто даёт TTFB свыше 1 секунды — это автоматически ломает LCP. Минимум для серьёзного проекта — managed WordPress hosting, VPS с SSD или облачный хостинг (DigitalOcean, Hetzner).
Как часто обновляются данные в Search Console?
CrUX-данные идут скользящим 28-дневным окном. Изменения на сайте отображаются в Search Console с задержкой 7–14 дней. Если оптимизировали вчера — не ждите мгновенного результата.
Что важнее: пройти все три метрики или одну идеально?
Нужно пройти все три. Google применяет «худший из трёх» — если LCP и CLS хорошие, а INP плохой, общий статус страницы «Плохо». Работайте над самой слабой метрикой в первую очередь.
Нужно ли вручную править код или хватит плагинов?
Для LCP и CLS в большинстве случаев хватает плагинов (WP Rocket, LiteSpeed) и правильного хостинга. Для INP плагины помогают слабо — часто нужна ручная работа с JavaScript и темой.
Сколько времени занимает оптимизация сайта?
Базовая оптимизация WordPress-сайта — 1–3 дня работы. Глубокая с переделкой темы и исправлением INP — 2–4 недели. Результат в Search Console увидите через 2–4 недели после внедрения изменений.
10. Итог: чек-лист для самопроверки
Проверьте свой сайт по этому списку:
- Проверены метрики в PageSpeed Insights для мобильной и десктопной версии
- Открыт отчёт «Основные интернет-показатели» в Google Search Console
- LCP укладывается в 2,5 секунды на мобильных
- INP не превышает 200 мс
- CLS меньше 0,1
- Подключено серверное кэширование или кэширующий плагин
- Картинки сжаты и переведены в WebP/AVIF
- Все изображения имеют атрибуты width и height
- Настроено CDN (хотя бы бесплатный Cloudflare)
- Критический CSS инлайнится, остальной асинхронно
- JavaScript помечен async или defer
- Сторонние скрипты (чаты, виджеты) минимизированы
- font-display: swap установлен для всех шрифтов
- Рекламные блоки обёрнуты в контейнеры с фиксированными размерами
- Core Web Vitals проверяются минимум раз в месяц
Улучшим Core Web Vitals вашего сайта под ключ
Команда IPROD проводит технический SEO-аудит, чинит проблемы с LCP, INP и CLS, оптимизирует WordPress и WooCommerce под требования Google 2026. Работаем с бизнесом по всему Казахстану: Алматы, Астана, Шымкент, Караганда и другие города.
Обсудить проект →
