Оптимизация Core Web Vitals: LCP, INP и CLS

Оптимизация Core Web Vitals не означает шлифовать микросекунды. Она означает попадание в три чётких пороговых значения: LCP ниже 2,5 секунды, INP ниже 200 миллисекунд, CLS ниже 0,1. По данным HTTP Archive Web Almanac 2024 на мобильных устройствах этому соответствуют только 43 процента origins, на desktop, 54 процента. Тот, кто корректно измеряет показатели и расставляет приоритеты, получает измеримое преимущество в ранжировании и конверсии.

Что такое Core Web Vitals в 2026 году?

Core Web Vitals, это три ориентированные на пользователя метрики производительности, с помощью которых Google измеряет реальный опыт на странице. На 2026 год это LCP, INP и CLS. INP с 12 марта 2024 года официально заменяет более старый показатель FID. Данные поступают из Chrome User Experience Report, то есть из реальных сессий браузера, а не из лабораторных значений.

Важно: Google оценивает по 75-му процентилю. Это значит, что трое из четырёх Ваших посетителей должны попасть в пороговые значения, а не только среднестатистический пользователь. Это определение зафиксировано в официальных статьях на web.dev про LCP. Оно объясняет, почему хорошие лабораторные данные всё равно могут давать красный отчёт PageSpeed.

Кроме того, Vitals являются частью более широкого сигнала Page Experience от Google. Они работают не изолированно. Безопасный HTTPS, мобильная адаптация и навязчивые межстраничные баннеры учитываются вместе с ними.

Какие три показателя Вы должны знать

Три значения, три вопроса.

LCP, сокращение от Largest Contentful Paint, отвечает: когда пользователь видит основное содержимое? Чаще всего это hero-изображение, заголовок или баннер. Целевое значение: 2,5 секунды или быстрее.

INP, Interaction to Next Paint, измеряет время реакции на протяжении всей сессии. Клик, тап, ввод с клавиатуры. Максимальная цель: 200 миллисекунд.

CLS, Cumulative Layout Shift, проверяет визуальную стабильность. Уходит ли кнопка из-под курсора при загрузке? Сдвигается ли текст из-за подгружаемой рекламы? Допустимы значения ≤ 0,1, как указано в web.dev: CLS.

Как правильно измерять Core Web Vitals?

Самый надёжный источник, это полевые данные из Chrome User Experience Report (CrUX). Они отражают, что реальные пользователи испытали за последние 28 дней, и обрабатываются по 75-му процентилю. Лабораторные инструменты вроде Lighthouse, напротив, симулируют одно устройство в стандартных условиях. Оба подхода дополняют друг друга, но решающим для Google остаётся поле CrUX с задокументированной 28-дневной методологией.

В аудитах производительности в Evelan я часто вижу одну и ту же ошибку: команды оптимизируют до тех пор, пока Lighthouse не станет зелёным, и удивляются, что Google Search Console по-прежнему пишет «требует улучшения». Причина в 75-м процентиле по реальным устройствам, а не в одном тесте на быстром ноутбуке.

Какими инструментами я пользуюсь на практике?

Прагматичный набор инструментов для среднего бизнеса:

• PageSpeed Insights для быстрой диагностики. Показывает полевые и лабораторные данные в одном представлении.
• Google Search Console, раздел «Core Web Vitals». Здесь Вы видите агрегированные группы URL со статусом «плохо», «требует улучшения», «хорошо».
• Lighthouse или панель Performance в DevTools Chrome для глубокого анализа отдельной страницы.
• CrUX Dashboard или CrUX API для отслеживания трендов на горизонте нескольких месяцев.

Важно не метаться между инструментами постоянно. Выберите один источник как «единый источник истины», как правило Search Console, а Lighthouse используйте только для проверки конкретных гипотез. Если Вы хотите глубже разобраться, как скорость влияет на конверсию, в материале Молниеносный сайт превращает посетителей в покупателей Вы найдёте дополнительные цифры из нашей практики.

Какие значения действительно хороши в 2026 году?

Официальная таблица пороговых значений не менялась с момента запуска INP в марте 2024 года. Google различает три уровня оценки для каждой метрики и проверяет 75-й процентиль отдельно для Mobile и Desktop. Источник: web.dev/articles/lcp, web.dev/articles/inp, web.dev/articles/cls.

Страница должна быть «хорошей» по всем трём показателям, чтобы Google пометил группу URL в целом как «хорошую». Это делает дисциплину требовательной. По данным HTTP Archive Web Almanac 2024 с метрикой INP только 43 процента мобильных origins выполняют все три значения, на desktop, 54 процента.

Что многие упускают: статус «требует улучшения», это не нейтральная середина. Google трактует его в отчётах Search Console как предупреждение. Тот, кто надолго оседает в этой зоне, теряет позиции в конкурентных ключевых словах против быстрее оптимизированных соперников. На практике это означает: целенаправленно стремитесь к зелёной зоне, а не к жёлтой.

Почему Google вообще вознаграждает быстрые сайты?

Google хочет быстро привести пользователя к результату. Сайт, которому нужно три секунды, ощутимо теряет клики и конверсии. Официальные документы PageSpeed Insights показывают, насколько тесно связаны время загрузки, показатель отказов и видимость. Медленный сайт теряет позиции не через секунды, а уже в первые их доли. Это напрямую меняет поисковый доход.

Отсюда следует двойной эффект. Во-первых, Core Web Vitals входят в сигнал Page Experience, задокументированный фактор ранжирования. Во-вторых, быстрые сайты влияют на время пребывания, отказы и конверсию. Оба эффекта усиливают друг друга, но измеряются независимо.

Что это значит для сайтов среднего бизнеса?

Из более чем 60 проектов с компаниями среднего бизнеса я знаю: тот, кто снижает LCP на одну секунду, как правило сразу видит лучший CTR из Google Discover и мобильного поиска. Эффекты по отдельности не кажутся впечатляющими, но суммируются на горизонте кварталов. Особенно выигрывают B2B-сайты с длинным циклом продаж, поскольку повторные посетители воспринимают более быстрый сайт как «более качественный».

К этому добавляется аспект, который многие недооценивают. Производительность, это косвенный показатель тщательности. Сайт, который грузится с hero-изображением, аккуратной типографикой и без скачков верстки, демонстрирует компетентность ещё до того, как прочитано первое слово. В B2B это работает особенно сильно, потому что решение редко принимается при первом визите.

Каковы наиболее частые причины плохих Core Web Vitals?

В моих аудитах постоянно всплывают три причины: неоптимизированные изображения, нагрузка от JavaScript и медленный сервер. Кто работает с этими тремя точками, обычно закрывает крупнейшие узкие места до того, как браться за тонкую настройку. Официальные руководства Optimize LCP и Optimize INP на web.dev называют те же главные темы: Time to First Byte, блокирующие рендеринг скрипты, крупные изображения и длинные задачи основного потока.

Как влияют изображения и медиа?

Неоптимизированные hero-изображения, самый частый убийца LCP. JPEG-файл на 3 МБ из зеркальной камеры заметно блокирует рендеринг. Решение: современные форматы вроде AVIF или WebP, корректные srcset, ленивая загрузка для изображений ниже сгиба и атрибут fetchpriority со значением «high» на LCP-элементе.

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

Сколько вреда наносят скрипты и плагины?

JavaScript, главный фактор для INP. Каждый неиспользуемый скрипт трекинга, каждый загрузчик чат-виджета, каждый сниппет A/B-теста блокирует основной поток. Следствие: клики реагируют вяло, INP уходит за 200 миллисекунд.

Конкретные рычаги: свести сторонние скрипты к минимуму, выстроить consent-слой так, чтобы неэссенциальные скрипты загружались только после согласия, а тяжёлые компоненты подключать через code-splitting. Мы почти всегда видим эффект в тот же день в отчёте Search Console. Кто хочет глубже разобраться технически, в сравнении Headless CMS против классической CMS найдёт обзор того, почему современные архитектуры упрощают контроль над INP.

Какую роль играет хостинг?

Медленный отклик сервера прямо отражается на LCP, поскольку браузер не может ничего отрендерить до получения HTML. TTFB выше 800 миллисекунд, это тревожный сигнал. Частые причины: дешёвый shared-хостинг, отсутствие CDN, отсутствие HTTP/2 или HTTP/3, отсутствие серверного кэша. Часто достаточно перехода на edge-хостинг вроде Vercel, Netlify или выделенного облачного сервера с Cloudflare перед ним.

Почему Google различает Mobile и Desktop?

Google оценивает оба класса устройств отдельно в отчёте Search Console. Это не деталь. Доля мобильных origins, которые проходят все три Vitals, по данным HTTP Archive Web Almanac 2024 заметно ниже, чем на desktop. Мобильное железо медленнее, мобильные сети нестабильны, а сенсорные взаимодействия оцениваются иначе, чем клики мышью.

На практике это означает: сайт может светиться зелёным на desktop и проваливаться на mobile. В моей аудиторской практике это правило, а не исключение. Тот, кто серьёзно относится к CWV, оптимизирует mobile-first, а desktop-значения использует только как проверку правдоподобия.

Какие устройства учитывает датасет CrUX?

Chrome User Experience Report агрегирует анонимизированные полевые данные пользователей Chrome, давших согласие на телеметрию. Разделение идёт по form-factor (Phone, Tablet, Desktop) и скорости соединения. Даже если у Вас преимущественно B2B-продукт, мобильные значения игнорировать нельзя. Исследование и первый контакт всё чаще происходят на смартфоне, даже когда финальная конверсия наступает на desktop.

Как пошагово оптимизировать Core Web Vitals?

Существует проверенный порядок, который я рекомендую каждой компании среднего бизнеса: измерить, расставить приоритеты, начать с самого сильного рычага, затем контролировать. Без базового замера Вы оптимизируете вслепую. Без приоритизации Вы распыляетесь. Без контроля Вы не знаете, действительно ли мера сработала. В качестве диагностического инструмента я обычно использую PageSpeed Insights как первую точку входа, потому что он объединяет полевые и лабораторные данные в одном представлении.

Шаг 1: Снять честный baseline

Запишите для каждого типа страниц (главная, страница продукта, категория, блог) актуальные значения LCP, INP и CLS в 75-м процентиле. Источник: Search Console или CrUX Dashboard, не Lighthouse. Этот baseline станет точкой отсчёта для каждого изменения.

Шаг 2: Починить изображения и LCP-элемент

Рычаг LCP, как правило, самый большой и самый быстрый в реализации. Сжать hero-изображение, конвертировать в AVIF или WebP, отдавать корректные размеры, выставить атрибут fetchpriority в «high», подключать веб-шрифты со стратегией font-display «swap». Неделя работы, нередко секунда выигрыша по LCP.

Шаг 3: Снизить нагрузку от JavaScript

Инвентаризируйте все сторонние скрипты. Вычеркните всё, что активно не используется. Перенесите трекинг за consent-слой. Подключайте через ленивую загрузку тяжёлые компоненты вроде чат-виджетов, карт или вкладок. Ожидаемый эффект: INP часто падает на 100, 300 миллисекунд.

Шаг 4: Закрыть источники CLS

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

Шаг 5: Настроить мониторинг

Оптимизация без мониторинга надёжно ведёт к откату. Плагины добавляются, трекинг достраивается, новое изображение проскакивает в hero. Уже через три месяца старые значения возвращаются. Мой совет: еженедельный взгляд в отчёт Core Web Vitals в Search Console и ежемесячное сравнение значений CrUX по типам страниц.

На крупных сайтах окупается автоматизированный real-user monitoring (RUM), который собирает полевые данные напрямую через собственный тег. Это даёт раннее оповещение, не реагирующее с задержкой в 28 дней. Кто хочет совместить это с прочной SEO-основой, в материале Основы SEO: как сделать Ваш сайт видимым найдёт стратегический контекст.

Какие меры приносят мало или вообще ничего?

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

Во-первых: универсальные «speed-плагины» для WordPress. Они часто упаковывают много функций, по отдельности полезных, но в сумме приносят дополнительную сложность и потенциал конфликтов. Без чёткой диагностики, какой рычаг действительно работает, активность превращается в ловушку.

Во-вторых: HTTP/3 как единственное решение. Современная настройка протокола даёт в среднем несколько миллисекунд TTFB, то есть не заменяет структурных мер по изображениям или скриптам. Это вишенка на торте, а не фундамент.

В-третьих: преждевременный апгрейд сервера. Кто застрял на слабом тарифе, должен сменить его. Но кто пытается решить проблему LCP «более мощной машиной», не трогая hero-изображение и JavaScript, обычно покупает пару процентов улучшения за большие деньги. Порядок остаётся прежним: проверить контент, оптимизировать код, и только потом масштабировать инфраструктуру.

Связанные статьи Evelan

• Молниеносный сайт превращает посетителей в покупателей
• Основы SEO: как сделать Ваш сайт видимым
• Как распознать SEO-ошибки и эффективно оптимизировать сайт
• Headless CMS против классической CMS

Источники

• Google web.dev: Largest Contentful Paint (LCP) (2024)
• Google web.dev: Interaction to Next Paint (INP) (2024)
• Google web.dev: Cumulative Layout Shift (CLS) (2024)
• Google web.dev: INP is now a Core Web Vital (2024, блог)
• Google Search Central: Page Experience (2024)
• HTTP Archive: Web Almanac 2024, Performance Chapter (2024)
• Chrome for Developers: CrUX Methodology (2024, документация)
• Google: PageSpeed Insights (2024, инструмент)