Как улучшить Core Web Vitals: 7 шагов для LCP, INP и CLS

Как улучшить Core Web Vitals: найдите в Google Search Console группы URL со статусом «Низкая скорость» или «Нужно увеличить скорость», разберите типовую страницу каждой группы в PageSpeed Insights и Chrome DevTools, исправьте общий шаблон по трем метрикам (LCP, INP, CLS), проверьте правки на тестовой копии и нажмите «Начать отслеживание» в отчете. Дальше Google 28 дней наблюдает за данными реальных посетителей и подтверждает исправление.

Ниже эти семь шагов расписаны подробно. Для работы вам понадобятся доступ к ресурсу в Google Search Console, браузер Google Chrome с панелью DevTools и доступ к коду сайта или панели управления CMS. Если отчет в Search Console по мобильным устройствам и компьютерам уже показывает все URL в статусе «Хорошо», выполнять инструкцию целиком не нужно: достаточно следить за отчетом.

Что такое Core Web Vitals и почему они важны для сайта

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

В набор входят Largest Contentful Paint (LCP — время отрисовки самого крупного видимого элемента), Interaction to Next Paint (INP — насколько быстро страница реагирует на клики, касания и нажатия клавиш) и Cumulative Layout Shift (CLS — суммарное неожиданное смещение элементов макета). В марте 2024 года INP официально заменил прежнюю метрику FID (First Input Delay). В отличие от FID, который учитывал только задержку первого ввода, INP оценивает отклик на взаимодействия в течение всего посещения страницы.

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

Главная особенность, которую часто упускают, — источник данных. Отчет в Search Console строится на полевых данных Chrome User Experience Report (CrUX), то есть на посещениях реальных пользователей Chrome. Согласно web.dev, страница считается соответствующей рекомендациям, если пороговое значение выполняется для 75-го процентиля загрузок, отдельно для мобильных устройств и компьютеров. В Search Console значения по группам URL считаются по 75 % посещений за последние 28 дней. Поэтому один удачный тест на мощном компьютере не меняет статус: нужно, чтобы большинство реальных визитов укладывалось в пороги.

Метрика	Что измеряет	Хорошо	Нужно увеличить скорость	Низкая скорость
LCP (Largest Contentful Paint)	Время отрисовки самого крупного элемента	≤ 2,5 с	≤ 4 с	> 4 с
INP (Interaction to Next Paint)	Отклик на действия пользователя	≤ 200 мс	≤ 500 мс	> 500 мс
CLS (Cumulative Layout Shift)	Визуальная стабильность макета	≤ 0,1	≤ 0,25	> 0,25

Пороги и названия статусов приведены по справке Search Console на русском языке; статус группы URL определяется по худшей из метрик.

Что подготовить перед оптимизацией Core Web Vitals

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

Элемент подготовки	Где взять	Что будет без него
Доступ к Google Search Console	Аккаунт владельца или выданные права	Не видно групп проблемных URL, нельзя запустить проверку исправлений
Браузер Google Chrome	Официальный дистрибутив	Недоступны панели Performance и Lighthouse в DevTools
Резервная копия темы и базы	Панель хостинга или плагин резервного копирования	Нет быстрого отката, если правка стилей сломает отображение
Тестовая копия сайта (staging)	Хостинг или локальный веб-сервер	Правки придется проверять прямо на рабочем сайте

Шаг 1: Найти проблемные группы URL в Search Console

Цель шага — найти страницы, которые не проходят пороги Core Web Vitals у реальных посетителей, и понять, какие шаблоны сайта за это отвечают. Если вы еще не работали с консолью, начните с обзора как пользоваться Google Search Console.

Откройте Google Search Console и в левом меню выберите отчет «Основные интернет-показатели» (Core Web Vitals). На обзорной странице есть две диаграммы: для мобильных устройств и для компьютеров. Нажмите «Открыть отчет» рядом с диаграммой мобильных устройств: проблемы со скоростью на смартфонах встречаются чаще из-за более слабых процессоров и нестабильной мобильной сети.

В таблице «Почему у этих страниц недостаточно высокое качество» перечислены проблемы со статусом «Низкая скорость» или «Нужно увеличить скорость» и указано, какая метрика не проходит. Нажмите на строку проблемы. Откроется страница сведений с таблицей «Примеры»: каждый URL в ней представляет группу похожих страниц. Нажмите на URL, чтобы увидеть другие страницы этой группы и значения LCP, INP и CLS по группе. Скопируйте один типовой адрес для разбора на следующем шаге.

Схема ниже показывает порядок работы с группами URL.

Результат шага — короткий список типовых URL, по одному на каждый проблемный шаблон (например, карточка товара, статья блога, главная страница).

Типичная ошибка — разбирать каждый адрес по отдельности. Search Console объединяет в группу страницы со схожим уровнем удобства, и, по справке, у них, скорее всего, общий фреймворк и общие причины проблем. Исправив общий шаблон, вы улучшаете сразу все страницы группы. Справка также советует начинать с URL в начале списка группы: они отсортированы по числу показов и сильнее влияют на статус.

Шаг 2: Диагностировать причины через PageSpeed Insights и DevTools

Цель шага — найти конкретные элементы, стили и скрипты, из-за которых страдают LCP, INP и CLS на выбранных страницах.

Откройте PageSpeed Insights и вставьте типовой URL из первого шага. В отчете есть два блока: полевые данные CrUX (опыт реальных пользователей) и лабораторный аудит Lighthouse. Полевые данные показывают, есть ли проблема, а лабораторная диагностика подсказывает причину: какой элемент стал элементом LCP и какие блоки смещаются.

Для поиска причин плохого INP откройте страницу в Chrome в режиме инкогнито и запустите DevTools (Ctrl+Shift+I, на macOS Cmd+Option+I). Перейдите на вкладку «Performance». В настройках записи включите замедление процессора (CPU throttling) и ограничение сети, чтобы приблизить условия к бюджетному смартфону. Нажмите кнопку записи, выполните действия, которые пользователи делают чаще всего (мобильное меню, фильтры, кнопка заказа), и остановите запись.

На дорожке «Interactions» найдите самые долгие взаимодействия. Длинные задачи (Long Tasks) — это задачи основного потока дольше 50 мс; DevTools отмечает их красным углом на дорожке «Main». Выберите задачу: во вкладке «Summary» и в дереве вызовов видно, какие функции JavaScript заблокировали основной поток.

Результат шага — список причин: селектор элемента LCP, перечень смещающихся блоков и файлы скриптов, которые тормозят отклик.

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

Шаг 3: Ускорить LCP и ответ сервера

Цель шага — сократить время отрисовки главного контента первого экрана до порога «Хорошо» (не более 2,5 с).

Схема ниже помогает выбрать метод в зависимости от того, что именно является элементом LCP на вашей странице.

Если элементом LCP служит главное изображение (hero image) или фото товара, сообщите браузеру о нем заранее: добавьте в <head> тег link с атрибутами rel="preload", as="image" и fetchpriority="high", а в атрибуте адреса укажите путь к этому изображению. В самом теге <img> добавьте fetchpriority="high" и уберите loading="lazy". Отложенная загрузка для изображения первого экрана заставляет браузер начинать его загрузку позже, чем нужно.

Переведите графику первого экрана в современные форматы WebP или AVIF и подберите размер файла под реальный размер на экране. На WordPress для этого подойдут плагины оптимизации изображений или настройки сервера.

Если задержка вызвана медленным ответом сервера (Time to First Byte, TTFB), включите кэширование страниц на стороне сервера (например, FastCGI Cache, Redis или Varnish) и подключите CDN. Так готовая HTML-копия страницы отдается без тяжелых запросов к базе данных при каждом визите.

Результат проверяется повторным аудитом в PageSpeed Insights: в лабораторных данных LCP должен попасть в зеленую зону.

Типичная ошибка — слайдер на JavaScript вместо статичного баннера на первом экране. Пока библиотека карусели не инициализируется, главное изображение не отрисовывается. Для первого экрана надежнее обычный тег <img> в HTML.

Шаг 4: Устранить сдвиги макета (CLS)

Цель шага — убрать неожиданные скачки интерфейса при загрузке и удержать CLS в пределах 0,1.

Откройте файлы шаблона темы. Для каждого тега <img>, <video> и <iframe> явно укажите ширину и высоту:

<img src="/images/catalog-item.webp" width="400" height="300" alt="Название товара">

Даже при адаптивной верстке браузер рассчитывает соотношение сторон по атрибутам width и height еще до загрузки файла и резервирует место. Для динамических блоков используйте CSS-свойство aspect-ratio.

Для рекламных баннеров, виджетов соцсетей и уведомлений заранее зарезервируйте место минимальной высотой контейнера (значение подберите под реальный размер блока):

.ad-banner-slot {
  min-height: 250px;
  display: block;
}

Если баннер не загрузится или будет заблокирован, место останется зарезервированным, и текст под ним не прыгнет.

Для веб-шрифтов задайте font-display: swap в правилах @font-face и используйте параметры подгонки метрик (size-adjust, ascent-override), чтобы резервный системный шрифт занимал столько же места, сколько основной.

Результат проверяется в DevTools: при медленной сети блоки контента сразу занимают свои места, без резких скачков при появлении изображений и рекламы.

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

Условный пример (вымышленный): у новостного сайта статьи «прыгали» при загрузке рекламы. Разработчики нашли в DevTools смещающиеся блоки, задали рекламным контейнерам min-height, а встроенным фреймам виджетов — фиксированные размеры. После выкладки сдвиги при прокрутке ленты прекратились, и через период отслеживания группа статей в Search Console перешла в статус «Хорошо».

Когда технические барьеры сняты, рост органического трафика зависит от контента. Модуль Orova SEO подключается к Google Search Console и GA4, предлагает ключевые слова, по которым сайт уже показывается в поиске, пишет по ним статьи с изображениями и публикует их на WordPress по расписанию.

Шаг 5: Улучшить INP и разбить длинные задачи

Цель шага — убрать зависания интерфейса при кликах, касаниях и нажатиях клавиш и довести INP до порога «Хорошо» (не более 200 мс).

С марта 2024 года INP заменил FID в составе Core Web Vitals. INP измеряет время от действия пользователя до отрисовки следующего кадра, включая обработку события. Разница между метриками — в таблице.

Параметр	FID (First Input Delay, заменен)	INP (Interaction to Next Paint)
Какие взаимодействия учитываются	Только первое взаимодействие	Взаимодействия в течение всего посещения
Что входит в замер	Только задержка до начала обработки	Задержка ввода + выполнение обработчиков + отрисовка следующего кадра
Тяжелые задачи после первого клика	Не влияли на метрику	Ухудшают метрику
Как исправлять	Освободить основной поток при загрузке	Держать основной поток свободным все время работы страницы

Чтобы улучшить INP, найдите и разбейте длинные задачи JavaScript (дольше 50 мс). Если обработчик клика фильтрует большой список или перестраивает DOM, сначала покажите пользователю отклик, а тяжелую работу отложите — с помощью scheduler.yield() там, где он поддерживается, или через setTimeout:

async function handleFilterClick() {
  showLoadingSpinner();
  // Передаем управление браузеру, чтобы он отрисовал индикатор
  await new Promise(resolve => setTimeout(resolve, 0));
  executeHeavyDomCalculations();
}

Второстепенные скрипты (счетчики аналитики, рекламные пиксели, онлайн-чаты, виджеты обратного звонка) подключайте с атрибутом defer или загружайте после первого взаимодействия пользователя. Это освобождает основной поток для обработки кликов по навигации.

Результат проверяется на вкладке «Performance» в DevTools: при кликах по меню и фильтрам на дорожке «Main» не должно быть длинных задач, а время взаимодействий на дорожке «Interactions» — укладываться в порог.

Типичная ошибка — анимации на JavaScript там, где хватит CSS-свойств transform и opacity. Анимация на JavaScript занимает основной поток и откладывает отрисовку следующего кадра.

Шаг 6: Проверить изменения на тестовой копии сайта

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

Разверните обновленные стили, скрипты и шаблоны на тестовом сервере (staging) или локально. Очистите серверный кэш и кэш плагинов оптимизации.

Откройте вкладку «Lighthouse» в DevTools, выберите режим «Mobile» и категорию «Performance», нажмите «Analyze page load». Сравните результат с замером до правок: LCP, Total Blocking Time (TBT — лабораторный ориентир для INP) и CLS должны улучшиться и попасть в зеленую зону.

Дополнительно можно установить расширение Web Vitals из Chrome Web Store: оно показывает значения метрик прямо во время прокрутки и кликов по странице.

Результат шага — подтверждение стабильности: нет ошибок JavaScript в консоли, верстка корректна на разных размерах экрана, метрики в лабораторных замерах лучше исходных.

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

Заодно убедитесь, что тестовая копия закрыта от поисковых роботов: о правилах сканирования подробно рассказано в материале о настройке файла robots.txt.

Шаг 7: Запустить проверку исправлений в Search Console

Цель шага — сообщить Google, что проблема исправлена, и запустить период отслеживания для группы URL.

Перенесите проверенные правки на рабочий сервер и откройте в Search Console отчет «Основные интернет-показатели». Нажмите «Открыть отчет» для нужного типа устройств и выберите строку исправленной проблемы.

На странице сведений о проблеме нажмите «Начать отслеживание». По справке Search Console, в течение 28 дней Google наблюдает, не проявится ли проблема снова. Если за этот период проблема не обнаружится ни по одному из URL, она будет считаться решенной. Запуск отслеживания не означает переиндексации: Google просто заново начинает период сбора данных CrUX для этой проблемы.

Ход проверки смотрите по кнопке «Подробности» в разделе статуса проверки. Возможные статусы: «Начато», «Ошибки исправлены», «Подтверждено», «Ошибка». Если проверка не пройдена, устраните оставшиеся проблемы и нажмите «Начать новую проверку».

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

Распространенная ошибка — перезапускать проверку через несколько дней «для ускорения». Новая проверка начинает период отслеживания заново, поэтому запускайте ее только после того, как действительно устранили оставшиеся проблемы.

Сводный чек-лист оптимизации Core Web Vitals

Сводная таблица поможет отметить выполненные шаги. Колонку «Готово» заполните сами.

Шаг	Главная задача	Признак завершения	Готово
1. Отчет в Search Console	Найти проблемные группы URL	Есть список типовых URL по шаблонам	☐
2. Диагностика	Найти элемент LCP, смещающиеся блоки, длинные задачи	Причины записаны по каждому шаблону	☐
3. LCP	Preload и fetchpriority, сжатие графики, кэширование	LCP в лабораторном замере в зеленой зоне	☐
4. CLS	Размеры медиа, резерв места под баннеры, шрифты	Нет заметных скачков макета при загрузке	☐
5. INP	Разбить длинные задачи, отложить сторонние скрипты	Нет длинных задач при основных кликах	☐
6. Тестирование	Проверка на staging без расширений	Метрики лучше исходных, нет ошибок в консоли	☐
7. Проверка исправлений	«Начать отслеживание» в Search Console	Статус проверки «Начато»	☐

Для разработчиков ниже — критерии приемки по каждой метрике.

Метрика	Задача	Сложность	Критерий приемки
LCP	Preload для изображения первого экрана	Легкая	В <head> есть <link rel="preload"> с fetchpriority="high"
LCP	Формат и сжатие изображений	Легкая	Изображение первого экрана в WebP или AVIF и по размеру соответствует месту на экране
LCP	Серверное кэширование	Средняя	Типовые страницы отдаются из кэша, TTFB в PageSpeed Insights не отмечен как проблема
CLS	Размеры медиаконтента	Легкая	Все <img> и <iframe> содержат width и height
CLS	Резерв места под рекламу	Легкая	У рекламных контейнеров задан min-height
CLS	Загрузка шрифтов	Средняя	В @font-face указан font-display: swap
INP	Разбиение длинных задач JavaScript	Сложная	На панели Performance нет длинных задач при кликах
INP	Отложенная загрузка сторонних скриптов	Средняя	Сторонние скрипты не блокируют основной поток при загрузке

Распространенные ошибки при оптимизации Core Web Vitals

Ошибка	Типичная причина	Как исправить
В PageSpeed Insights высокий балл, а в Search Console статус «Низкая скорость»	Лабораторный тест не отражает устройства и сети реальных посетителей	Ориентироваться на полевые данные CrUX и проверять страницу с замедлением процессора
Изображение первого экрана появляется позже остального	На нем стоит loading="lazy"	Убрать loading="lazy" и добавить fetchpriority="high"
Сдвиги макета только на мобильных	Адаптивные баннеры меняют высоту без зарезервированного места	Задать пропорции через aspect-ratio в мобильных медиазапросах
INP ухудшился после подключения онлайн-чата	Виджет загружает тяжелый JavaScript в основной поток	Загружать скрипт чата по клику или после первого взаимодействия
Проверка в Search Console завершилась статусом «Ошибка»	Часть страниц группы осталась с проблемой	Проверить, что правка попала во все шаблоны группы, и нажать «Начать новую проверку»
Текст мигает и перестраивается при загрузке шрифта	Браузер скрывает текст до загрузки файла шрифта	Указать font-display: swap и подобрать похожий резервный шрифт

Чтобы не терять накопленную историю страниц, обновляйте старые материалы вместо создания дублей. В Orova SEO можно массово оптимизировать опубликованные статьи с сохранением URL и следить за результатами Search Console в одном месте; пользоваться модулем можно бесплатно до 7 июля 2027 года.

Как измерить результат оптимизации

Лабораторные замеры в DevTools и Lighthouse меняются сразу после выкладки правок: так вы проверяете, что причина устранена. Для Google решающими остаются полевые данные CrUX, поэтому статус в отчете Search Console меняется постепенно, по мере накопления посещений за скользящее окно в 28 дней.

Следите за тремя вещами: числом URL в статусах «Низкая скорость», «Нужно увеличить скорость» и «Хорошо» на диаграмме отчета, статусом запущенной проверки и значениями LCP, INP и CLS по группам на странице сведений. Улучшение технической базы поддерживает общую поисковую оптимизацию сайта, но позиции по-прежнему зависят и от качества контента. Если вы сводите данные Search Console и аналитики в один отчет, пригодится инструкция по созданию отчетов в Looker Studio.

Что делать после технической оптимизации: работа с контентом в Orova SEO

Core Web Vitals убирают технические барьеры, но рост органического трафика дальше зависит от контента. Модуль Orova SEO не исправляет код сайта; он помогает с контентной частью работы. Модуль подключается к Google Search Console и GA4, чтобы вы видели результаты в одном месте, и предлагает ключевые слова, по которым сайт уже показывается в поиске на позициях 8–30.

На вкладке Write собран список ключевых слов: у каждого виден статус и адрес опубликованной статьи. Слова можно добавить по одному кнопкой «+ Add keyword» или загрузить списком через «Import from Excel».

Публикация статей по ключевым словам

По каждому ключевому слову Orova SEO пишет статью с изображениями в заданном вами стиле бренда и публикует ее на WordPress через Application Password, без установки плагина. При добавлении ключевого слова вы выбираете, публиковать ли статью сразу («Publish as soon as possible») или по расписанию («Schedule publishing»).

Для уже опубликованных материалов модуль умеет массово оптимизировать старые статьи, сохраняя их URL, поэтому ссылки и накопленная история страниц не теряются.

Если нужно быстро проверить отдельную страницу, на orova.vn есть инструмент Orova SEO Check: вставьте ссылку, и он покажет технический отчет, данные PageSpeed и обратные ссылки на уровне домена без входа в аккаунт.

Тренды Core Web Vitals в ближайшие годы: мнение автора

По моим наблюдениям, требования к производительности будут смещаться от разовых замеров загрузки к контролю всего посещения. Я выделяю три направления.

Контроль непрерывной интерактивности. Замена FID на INP уже заставила разработчиков думать не только о первом клике, а обо всей сессии. Я думаю, что со временем внимание к плавности прокрутки и анимаций в сложных веб-приложениях будет расти. Уже сейчас стоит предпочитать нативные CSS-свойства тяжелым JavaScript-библиотекам анимации. Это предположение может не оправдаться, если браузерные движки сами научатся сглаживать последствия тяжелого клиентского кода.

ИИ в инструментах сборки сайтов. По моему мнению, автоматическая оптимизация кода с помощью ИИ постепенно станет обычной функцией сборщиков и CMS: генерация критического CSS, подсказки по разбиению тяжелых функций. Ошибиться в этой оценке я могу, если тяжелые клиентские ИИ-виджеты сами начнут создавать дополнительную нагрузку на мобильные устройства и сведут улучшения на нет.

Полевые данные как часть регулярной поддержки. Я полагаю, что мониторинг полевых данных станет такой же обязательной частью технической поддержки сайта, как резервное копирование, а не задачей, о которой вспоминают после просадки трафика. Прогноз может не оправдаться, если владельцы сайтов продолжат опираться только на разовые лабораторные тесты.

Часто задаваемые вопросы о Core Web Vitals

Почему PageSpeed Insights показывает высокий балл, а в Search Console метрики красные?

Балл производительности в PageSpeed Insights — это лабораторный замер Lighthouse в момент проверки. Search Console показывает полевые данные CrUX реальных посетителей за 28 дней, к тому же по группам URL, а не по одной странице. Если ваши посетители заходят со слабых смартфонов или через медленную мобильную сеть, полевые метрики будут хуже лабораторных.

Как найти элемент, из-за которого высокий INP, в Chrome DevTools?

Откройте вкладку «Performance», включите замедление процессора и запишите взаимодействие со страницей. На дорожке «Interactions» выберите самое долгое взаимодействие, а затем изучите длинные задачи на дорожке «Main» и вкладку «Summary»: там видно, какие функции JavaScript заняли основной поток.

Сколько времени нужно Search Console, чтобы обновить статус на «Хорошо»?

После нажатия «Начать отслеживание» Google в течение 28 дней следит, не проявится ли проблема снова. Это связано с тем, что значения по группам считаются по данным CrUX за последние 28 дней.

Может ли искусственный интеллект сам исправить ошибки Core Web Vitals?

ИИ помогает найти проблемные места в коде, предложить разбиение тяжелых функций и правила для стилей. Но внедрять правки в шаблон, настраивать сервер и кэширование и проверять результат все равно нужно техническому специалисту.

Гарантирует ли статус «Хорошо» первое место в поиске?

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

С чего начать оптимизацию Core Web Vitals

Если на сайте сотни страниц с предупреждениями, не пытайтесь переписать весь код за один раз. Начните с шаблона, который приносит больше всего органического трафика (например, статья блога или карточка товара): возьмите типовой URL этой группы из отчета, откройте страницу в режиме инкогнито и разберите первый экран в DevTools.

Для сайтов на популярных CMS первым шагом станет ревизия модулей и плагинов: отключите неиспользуемые слайдеры, уберите дублирующиеся счетчики и включите конвертацию изображений в WebP.

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