Core Web Vitals: как скорость сайта влияет на SEO и что исправлять

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

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

В этой статье разберем, как Core Web Vitals связаны с SEO-продвижением, что означают LCP, INP и CLS, почему одного PageSpeed Insights недостаточно и какие проблемы чаще всего приходится исправлять на проектах.

Коротко: что Core Web Vitals дают SEO

Хорошие показатели не поднимут страницу в топ автоматически. Они не заменяют семантику, полезный контент, правильную структуру, индексацию и внутреннюю перелинковку. Но плохая производительность создает сразу несколько проблем:

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

Google учитывает Core Web Vitals как часть общей оценки page experience. Для Яндекса не стоит механически переносить формулировки Google: официальная модель ранжирования не сводится к одному отчету PageSpeed. Но быстрый, стабильный и понятный сайт лучше решает задачу пользователя в любой поисковой системе.

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

Из чего состоят Core Web Vitals

Метрика	Что измеряет	Хороший результат
LCP	Скорость появления самого крупного элемента в первом экране	до 2,5 с
INP	Задержку реакции интерфейса на клики, нажатия и ввод	до 200 мс
CLS	Неожиданные сдвиги элементов на странице	до 0,1

Оценка обычно смотрится на 75-м перцентиле: важно, чтобы хороший опыт получало не только быстрое устройство разработчика, но и значительная часть реальных посетителей.

LCP — когда появился главный контент

Largest Contentful Paint отвечает на вопрос: «Как быстро человек увидел то, ради чего открыл страницу?» Это может быть заголовок, большой блок текста, изображение товара или первый экран лендинга.

На LCP влияют время ответа сервера, порядок загрузки ресурсов, размер изображения, CSS и шрифты. Частая ошибка — загружать огромный баннер в первом экране, хотя на телефоне он отображается в небольшом блоке.

INP — насколько быстро сайт отвечает

Interaction to Next Paint показывает, что происходит после клика или нажатия. Пользователь нажал «показать еще», открыл меню или начал заполнять форму — интерфейс должен быстро показать результат.

Главный источник плохого INP — длинные задачи JavaScript. Браузер занят выполнением тяжелого кода и не может вовремя обработать действие. Поэтому ускорение — это не только сжатие картинок: иногда сначала нужно убрать неиспользуемый JS и разбить большой бандл на части.

CLS — почему верстка «прыгает»

Cumulative Layout Shift фиксирует неожиданные перемещения элементов. Например, сначала текст занимает место, потом сверху появляется картинка без заданных размеров, и кнопка уезжает вниз.

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

Как проверить скорость загрузки сайта

У запроса «проверить скорость загрузки сайта» в Wordstat заметно больше спроса, чем у англоязычного Core Web Vitals. Но проверка должна быть не одной кнопкой, а последовательностью:

1. PageSpeed Insights — посмотреть лабораторный тест и полевые данные Chrome, если для URL есть накопленная статистика.
2. Google Search Console — найти группы URL с одинаковой проблемой Core Web Vitals, а не исправлять одну случайную страницу.
3. Lighthouse или Chrome DevTools — понять, какой ресурс блокирует загрузку и какая задача JavaScript задерживает взаимодействие.
4. Яндекс.Вебмастер и Метрика — оценить доступность, ошибки и поведение аудитории из российского трафика.
5. Повторный замер — проверить не только показатель, но и бизнес-результат: глубину просмотра, заявки, корзины и отказы.

PageSpeed Insights может показать низкий балл в лаборатории, хотя реальные пользователи проходят Core Web Vitals, и наоборот. Поэтому не стоит гнаться за 100/100 на одной странице: важнее исправлять проблемы шаблона и смотреть полевые данные.

Что чаще всего замедляет сайты

В проектах проблема обычно не в одной «медленной кнопке», а в накопившихся решениях, которые когда-то добавили временно.

Неактуальные карты загрузки

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

Такие сценарии нужно искать в логике запросов, состояниях компонентов и сетевых ошибках, а не просто «ускорять сервер».

Неиспользуемый JavaScript

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

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

Несжатые изображения и видео

Фотография из исходника, баннер в два-три мегабайта или видео на фоне без адаптивной версии быстро становятся главным элементом LCP. Для разных экранов нужны разные размеры, а не один максимальный файл для всех.

Обычно проверяем:

• WebP или AVIF вместо тяжелого JPEG/PNG, когда формат подходит;
• размеры изображения под реальный блок;
• srcset и ленивую загрузку для контента ниже первого экрана;
• постер и облегченный вариант фонового видео;
• наличие ширины и высоты, чтобы не провоцировать CLS.

Медленный ответ сервера и лишние запросы

Даже идеальная картинка не спасет сайт, если HTML долго ждет базу данных или сервер отправляет десятки блокирующих запросов. Проверяем TTFB, кэширование, серверный рендеринг, порядок подключения CSS и шрифтов.

Как исправлять Core Web Vitals без бессмысленной гонки за баллами

Мы начинаем с реальных шаблонов страниц и приоритета для бизнеса:

1. выбираем страницы, которые уже получают органический трафик или приводят заявки;
2. фиксируем базовые LCP, INP, CLS и список узких мест;
3. сначала убираем блокирующие ресурсы, бесконечные loading-сценарии и тяжелый первый экран;
4. затем оптимизируем медиа, JavaScript, шрифты и серверные запросы;
5. повторяем замер на мобильных устройствах и сравниваем не только отчет, но и поведение пользователей.

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

Что мы уже учитываем в проектах Flowweb

В разработке на Next.js мы используем серверный рендеринг, оптимизацию изображений и разделение кода, но не выдаем сам стек за гарантию зеленых метрик. Важно, что именно реально загружается на странице и как это работает на устройстве посетителя. В статье о разработке сайтов на Next.js мы показывали отчет по Flowweb и честно отмечали, что один из показателей еще можно улучшать.

Для магазинов скорость связана с каталогом и SEO-структурой. В кейсе «Матушка-Земля» оптимизация изображений и кода шла вместе с пересборкой категорий и карточек — нельзя ускорить страницу, если сама структура не помогает пользователю найти товар. Другие типовые технические ошибки разбираем в чек-листе SEO-аудита.

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

Вывод

Core Web Vitals — это способ перевести разговор о «медленном сайте» в измеримые проблемы: главный контент появляется поздно, интерфейс не отвечает или верстка прыгает. Для SEO это важная часть технического качества, но не самостоятельная стратегия продвижения.

Начните с реальных страниц и мобильной аудитории, сравните полевые данные с Lighthouse и исправляйте причины по приоритету. Если нужен не общий совет, а список конкретных правок по вашему сайту, можно заказать SEO-продвижение и технический аудит в Flowweb или написать нам в Telegram.