Core Web Vitals — это не абстрактная «оценка от Google», которую приятно показать на созвоне с разработчиками. Это набор метрик, которые отражают реальный пользовательский опыт: насколько быстро человек видит основной контент, как быстро сайт реагирует на действия и не прыгает ли интерфейс у него перед глазами. Сейчас в Core Web Vitals входят LCP, INP и CLS, а хорошими считаются значения: LCP до 2,5 секунды, INP менее 200 мс и CLS менее 0,1. Google также рекомендует оценивать их по 75-му перцентилю реальных визитов, а не по одному удачному прогону в лаборатории.
Самая частая ошибка при работе с Core Web Vitals — пытаться «подкрасить цифры» вместо того, чтобы чинить реальную причину тормозов. Сайт может выглядеть прилично в Lighthouse на хорошем ноутбуке и хорошем интернете, но при этом проваливаться в Search Console, потому что там используются данные реальных пользователей. Отчет Core Web Vitals в Search Console строится именно на field data, группирует похожие URL и показывает статус по худшей из метрик в группе. Поэтому ситуация «у меня в тесте 95 баллов, а в Google все плохо» — не редкость, а обычная жизнь.
С чего начинать, если сайт тормозит
Начинать нужно не с хаотичного «давайте все сожмем», а с диагностики. Сначала смотрят Search Console, чтобы понять, какие группы URL реально плохие у пользователей. Потом берут PageSpeed Insights, Chrome DevTools или WebPageTest и уже на конкретных страницах ищут узкое место: медленный сервер, тяжелый hero-блок, забитый JavaScript, прыгающие баннеры или криво подключенные шрифты. Google прямо указывает, что лабораторные тесты полезны для диагностики, но не заменяют данных реальных пользователей.
Хорошая новость в том, что Core Web Vitals почти всегда улучшаются не «магией оптимизации», а очень приземленными вещами. Плохая новость — иногда эти приземленные вещи живут в коде, шаблонах, CMS, рекламных скриптах и фронтенде одновременно. То есть проблема редко бывает в одном-единственном файле, который кто-то сейчас героически откроет и спасет проект за двадцать минут.
Как улучшить LCP
LCP отвечает за то, как быстро пользователь увидит главный контент страницы. Обычно это большой баннер, hero-изображение, крупный заголовок или основной блок первого экрана. Хороший LCP — до 2,5 секунды как минимум для 75% визитов. При этом Google отдельно подчеркивает, что быстрый LCP редко достигается одной точечной правкой: нужно смотреть на весь путь загрузки страницы.
На практике LCP ломают четыре вещи: медленный ответ сервера, позднее обнаружение главного ресурса, низкий приоритет его загрузки и блокирующие рендер стили или скрипты. Если главный баннер подгружается через JavaScript, скрыт за data-src, лениво грузится или вообще становится видимым только после выполнения клиентского кода, браузер слишком поздно понимает, что это и есть самый важный элемент. В результате пользователь успевает посмотреть на пустоту, загрузочный экран или философски осмыслить брендовую палитру фона.
Чтобы улучшить LCP, обычно работают в таком порядке:
-
Ускоряют TTFB: оптимизируют сервер, кэширование и подключают CDN.
-
Делают LCP-ресурс обнаруживаемым прямо из исходного HTML.
-
Повышают приоритет загрузки главного изображения через fetchpriority="high" или preload там, где это уместно.
-
Убирают loading="lazy" у LCP-изображения.
-
Сокращают или выносят из критического пути тяжелые CSS и JavaScript.
-
Уменьшают вес самого ресурса: современные форматы, корректные размеры, компрессия, аккуратные шрифты.
Особенно часто LCP убивает «красивый» первый экран. На макете он выглядит как произведение цифрового искусства: огромная картинка, видео, веб-шрифт на 6 начертаниях, карусель, анимация, скрипт аналитики, два чата и баннер акции. На реальном телефоне это уже не первый экран, а испытание на веру в бренд. Если хотите быстрый LCP, главный контент должен быть простым для обнаружения, легким для загрузки и важным для браузера с первой секунды.
Как улучшить INP
INP измеряет отзывчивость страницы: насколько быстро сайт реагирует на клик, тап или нажатие клавиши. Хорошее значение — менее 200 мс. В отличие от старого FID, INP учитывает не только первую реакцию, а взаимодействия в течение всей жизни страницы, и смотрит на полную задержку до следующей отрисовки. Это делает метрику намного ближе к реальному ощущению пользователя: «сайт шустрый» или «сайт завис и делает вид, что занят».
Плохой INP почти всегда связан с перегруженным main thread. Когда браузер занят длинной задачей, тяжелым JavaScript, массовым ререндером или сложной обработкой событий, пользователь нажимает кнопку, а интерфейс отвечает с паузой. Именно поэтому Google и web.dev постоянно возвращаются к одной и той же мысли: длинные задачи нужно разбивать, лишний JavaScript — убирать, тяжелые обновления интерфейса — сокращать.
Если говорить совсем практично, INP улучшают такие действия:
-
разбивают длинные задачи на более короткие;
-
уменьшают объем клиентского JavaScript;
-
откладывают неважные вычисления;
-
сокращают тяжелые рендер-обновления;
-
упрощают обработчики событий;
-
убирают сторонние скрипты, которые блокируют поток;
-
проверяют, какие именно действия пользователя дают наихудшую задержку в field data и в профилировщике.
Очень часто плохой INP живет не на лендинге, а внутри сайта: в фильтрах каталога, корзине, калькуляторе, личном кабинете, выпадающих меню и тяжелых формах. То есть на страницах, где маркетинг уже ушел домой, а пользователь наконец начал что-то делать. Поэтому если бизнес смотрит только на главную, он может пропустить место, где сайт на самом деле раздражает людей сильнее всего.
Как улучшить CLS
CLS отвечает за визуальную стабильность. Проще говоря, если человек хотел нажать одну кнопку, а страница в этот момент дернулась и он случайно оформил подписку, это уже не «микросмещение интерфейса», а маленькое бытовое предательство. Хороший CLS — меньше 0,1.
Самые частые причины плохого CLS давно всем знакомы, но сайты продолжают повторять их с завидным упорством. Картинки и iframe без заранее заданных размеров, рекламные блоки, которые внезапно вырастают посреди контента, cookie-баннеры, выезжающие сверху и толкающие страницу вниз, поздно подгружаемые шрифты и анимации CSS-свойств, влияющих на layout. web.dev отдельно отмечает, что анимации и переходы свойств вроде margin или border часто ухудшают CLS, а страницы с layout-inducing анимациями заметно реже показывают хороший результат.
Здесь работает довольно прямой набор правил:
-
Всегда задавайте ширину и высоту для изображений, видео, embed-блоков и iframe.
-
Резервируйте место под рекламу, виджеты, баннеры и уведомления заранее.
-
Не вставляйте новый контент над уже отрисованным блоком без явной необходимости.
-
Не анимируйте свойства, которые вызывают перерасчет layout.
-
Осторожно работайте со шрифтами и их подменой при загрузке.
-
Следите за баннерами, попапами и sticky-элементами, которые появляются «внезапно, но по плану».
Если упростить, CLS — это про уважение к пальцам и нервной системе пользователя. Интерфейс не должен жить своей жизнью. Особенно в момент, когда человек уже навел курсор на кнопку «Купить».
Почему нельзя ориентироваться только на Lighthouse
Потому что Core Web Vitals — в первую очередь полевые метрики. web.dev прямо пишет, что лабораторные измерения важны, но не заменяют field measurement, а производительность сайта может сильно меняться в зависимости от устройства, сети, фоновой нагрузки и того, как именно пользователь взаимодействует со страницей. Search Console и CrUX показывают реальную картину, а Lighthouse помогает понять, почему она такая. Нормальная стратегия — использовать оба источника, а не спорить, какой «правильнее».
Это особенно важно для интернет-магазинов, медиа и сервисов с большой мобильной аудиторией. На хорошем офисном MacBook сайт может быть «почти космос», а на среднем Android с неидеальным интернетом — уже вполне земной опыт с паузами, скачками и задумчивыми кнопками. Google смотрит именно туда, где пользователи настоящие, а не туда, где у разработчика открыт мощный ноутбук и спокойная совесть.
Что дает самый быстрый эффект
Если не распыляться, самые частые точки роста такие: ускорить ответ сервера через CDN и кэширование, вытащить LCP-ресурс в HTML и поднять его приоритет, убрать lazy-load с главного изображения, порезать тяжелый JavaScript, разбить длинные задачи, а для CLS — задать размеры всем нестабильным блокам и перестать двигать интерфейс без спроса. Это не весь список возможных работ, но именно он чаще всего двигает метрики заметно, а не символически.
Как выстроить работу без хаоса
Рабочий порядок обычно такой. Сначала определяют проблемные группы страниц в Search Console. Затем на 3–5 типовых URL смотрят PageSpeed Insights и DevTools, чтобы найти повторяющийся паттерн. После этого задачи делят по метрикам: отдельно LCP, отдельно INP, отдельно CLS. И только потом превращают это в backlog, где есть быстрые победы, средние доработки и тяжелые инфраструктурные задачи. Иначе получается классическая история: все что-то оптимизировали, все устали, а хуже всего по-прежнему живет каталог на мобильных.
Улучшение Core Web Vitals — это не про «порадовать Google», а про то, чтобы сайт быстрее показывал главное, быстрее реагировал и меньше бесил движущимися блоками. Для LCP важны сервер, критический путь и главный ресурс первого экрана. Для INP — контроль над JavaScript и main thread. Для CLS — предсказуемый интерфейс без прыжков и сюрпризов. Если смотреть на реальные данные пользователей, а не только на красивые лабораторные баллы, работа становится гораздо менее романтичной, зато гораздо более полезной для бизнеса.