Core Web Vitals 2026: что изменилось и как починить

Core Web Vitals 2026: что изменилось и как починить

Если вы занимаетесь веб-разработкой или SEO, вы наверняка слышали про Core Web Vitals. Но вот проблема: большинство материалов в рунете до сих пор описывают метрики 2023 года. А Google с тех пор серьёзно пересмотрел подход. FID больше нет — его заменил INP. Пороговые значения ужесточились. Инструменты обновились. И если ваш сайт «зелёный» по старым критериям — это ещё не значит, что он проходит проверку по новым.

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

Почему Core Web Vitals критичны именно сейчас

Давайте начнём с контекста. Google использует Core Web Vitals как фактор ранжирования с 2021 года. Но в 2025–2026 годах произошло несколько событий, которые резко повысили значимость этих метрик:

1. Полный переход на mobile-first индексацию — Google оценивает CWV по мобильной версии сайта, где проблемы с производительностью проявляются в 3–5 раз острее.
2. Замена FID на INP — метрика стала строже и охватывает весь жизненный цикл страницы, а не только первое взаимодействие.
3. Рост конкуренции в поисковой выдаче — при прочих равных сайт с лучшими метриками получает преимущество в 3–8 позиций.
4. Изменение пользовательских ожиданий — по данным исследований Google, 53% мобильных пользователей уходят со страницы, если она загружается дольше 3 секунд. В 2026 году этот порог снизился до 2 секунд.

Результаты наших клиентов подтверждают: оптимизация CWV с «красной» до «зелёной» зоны даёт рост органического трафика на 15–40% в течение 2–3 месяцев. Не только за счёт прямого ранжирования — улучшенный пользовательский опыт снижает отказы и увеличивает глубину просмотра.

Три кита Core Web Vitals в 2026 году

LCP — Largest Contentful Paint

LCP измеряет, когда самый крупный видимый элемент на экране полностью отрисовывается. Это может быть hero-изображение, заголовок, видео-постер или большой блок текста.

Пороговые значения 2026:

• Хорошо: до 2.5 секунд
• Требует улучшения: 2.5–4.0 секунды
• Плохо: более 4.0 секунд

Google в 2025 году уточнил методологию подсчёта LCP: теперь учитываются и элементы внутри shadow DOM, а также изображения, загруженные через CSS background-image с ленивой загрузкой. Это означает, что некоторые сайты, ранее показывавшие хороший LCP, могут обнаружить ухудшение показателей без фактических изменений кода.

Ещё одно важное уточнение: LCP-элемент может меняться в процессе загрузки. Например, сначала LCP-элементом является текстовый заголовок (отрисовывается быстро), но затем загружается hero-изображение — и оно становится LCP-элементом с худшим временем. Google фиксирует финальный LCP-элемент, поэтому оптимизировать нужно именно его.

Что чаще всего ломает LCP:

• Неоптимизированные hero-изображения (PNG вместо WebP/AVIF, отсутствие размеров, нет preload)
• Медленный серверный ответ (TTFB > 600 мс)
• Блокирующие ресурсы: синхронный CSS и JS в head
• Web-шрифты без font-display: swap
• Рендер-блокирующие сторонние скрипты (чат-виджеты, аналитика)
• Каскадные цепочки запросов: HTML → CSS → шрифт → изображение (каждый шаг ждёт завершения предыдущего)
• Клиентский рендеринг SPA без SSR/SSG — браузер сначала загружает JS, потом рендерит контент

CLS — Cumulative Layout Shift

CLS отслеживает визуальную стабильность: насколько элементы страницы «прыгают» во время загрузки и взаимодействия. Каждый сдвиг получает оценку — произведение размера сдвинувшейся области на расстояние сдвига.

Пороговые значения 2026:

• Хорошо: до 0.1
• Требует улучшения: 0.1–0.25
• Плохо: более 0.25

Важное изменение 2025 года: Google перешёл на оконный подход к подсчёту CLS. Теперь считается максимальная сумма сдвигов в любом окне длительностью 5 секунд с интервалом не более 1 секунды между сдвигами. Это означает, что единичный небольшой сдвиг при загрузке менее критичен, но серия мелких сдвигов при скролле может обрушить показатель.

Практическое следствие: раньше можно было «пережить» один большой сдвиг от рекламного баннера. Теперь 10 мелких сдвигов от lazy-loaded изображений при скролле — куда более серьёзная проблема. Мы видели сайты с CLS 0.45, где 80% вклада давали не баннеры, а подгружаемые картинки в ленте новостей без заданных размеров.

Типичные причины плохого CLS:

• Изображения и видео без заданных width/height
• Динамически вставляемые рекламные блоки
• Шрифты, вызывающие перерасчёт макета (FOUT)
• Баннеры с cookie-согласием, появляющиеся с задержкой
• Контент, подгружаемый AJAX без плейсхолдеров
• Верхние баннеры (top bar), вставляемые после рендеринга основного контента
• Динамический контент, вставляемый через A/B-тестирование (Google Optimize, VWO)

INP — Interaction to Next Paint (замена FID)

Это главное изменение последних двух лет. В марте 2024 года Google окончательно заменил First Input Delay на Interaction to Next Paint. И это не просто переименование — метрика принципиально другая.

FID измерял задержку только первого взаимодействия пользователя со страницей. Если первый клик обрабатывался быстро, а десятый — с трёхсекундной задержкой, FID этого не видел. INP фиксирует все взаимодействия (клики, тапы, нажатия клавиш) за весь жизненный цикл страницы и берёт наихудший результат (точнее — «высокий перцентиль», обычно 98-й).

Пороговые значения INP:

• Хорошо: до 200 мс
• Требует улучшения: 200–500 мс
• Плохо: более 500 мс

Анатомия INP: каждое взаимодействие состоит из трёх фаз:

1. Input delay — задержка от момента взаимодействия до начала выполнения обработчика (основная причина — занятый main thread)
2. Processing time — время выполнения обработчика события
3. Presentation delay — время от завершения обработчика до отрисовки следующего кадра

INP — это сумма всех трёх фаз для наихудшего взаимодействия. Оптимизировать нужно каждую фазу отдельно.

Почему INP важнее FID:

FID давал ложное чувство безопасности. Мы видели десятки сайтов с идеальным FID и ужасным пользовательским опытом — потому что тяжёлые обработчики событий блокировали отрисовку на 300–800 мс после каждого клика. INP ловит эти проблемы.

По данным Chrome UX Report, при переходе с FID на INP около 30% сайтов, ранее имевших «зелёный» статус, оказались в «жёлтой» или «красной» зоне. Если вы не проверяли свой INP — самое время это сделать.

Реальный пример: интернет-магазин с каталогом на 5 000 товаров. FID был 45 мс (отлично). INP — 680 мс (красная зона). Причина: при каждом клике по фильтру JavaScript пересортировывал весь массив товаров в основном потоке, блокируя отрисовку на 400–600 мс. Пользователи жаловались на «подвисание» — но FID этого не видел.

Инструменты диагностики: что использовать в 2026 году

PageSpeed Insights

Остаётся основным бесплатным инструментом. Показывает и лабораторные данные (Lighthouse), и полевые данные (CrUX). Ключевое: смотрите на полевые данные в первую очередь — они отражают реальный опыт пользователей.

На что обращать внимание:

• Секция «Core Web Vitals Assessment» — проходите или нет
• Поле «Origin Summary» — общие показатели домена
• Раздел «Diagnostics» — конкретные рекомендации
• Вкладка «Treemap» — визуализация JavaScript-бандлов для поиска «тяжёлых» зависимостей

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

Chrome UX Report (CrUX)

CrUX — это база полевых данных от реальных пользователей Chrome. Доступна через BigQuery, CrUX API и CrUX Dashboard (Data Studio). Для мониторинга достаточно дашборда — он бесплатный и обновляется ежемесячно.

Когда CrUX незаменим:

• Когда лабораторные тесты «зелёные», а реальные пользователи жалуются на медленность
• Когда нужно отследить динамику метрик за месяцы
• Когда нужно сравнить показатели по устройствам (desktop vs mobile)
• Когда нужно убедиться, что оптимизация дала результат (данные обновляются с задержкой 28 дней)

Важно: CrUX собирает данные только от пользователей Chrome, которые дали согласие на отправку анонимной статистики. Это около 50–60% вашего трафика. Для полной картины дополняйте web-vitals.js.

Библиотека web-vitals.js

Для точечной диагностики и непрерывного мониторинга подключите web-vitals.js. Версия 4.x полностью поддерживает INP и позволяет отправлять метрики в любую систему аналитики.

Что даёт web-vitals.js:

• Реальные метрики с каждого пользователя (не семплированные)
• Привязка к конкретным страницам и действиям
• Атрибуция: какой именно элемент вызвал проблему
• Интеграция с Google Analytics 4, Sentry, собственными дашбордами

Мы рекомендуем отправлять данные web-vitals в GA4 через пользовательские события. Это позволяет строить отчёты по LCP, CLS и INP в разрезе страниц, устройств и источников трафика.

Практический совет по настройке: включите режим атрибуции (attribution build). Он увеличивает размер библиотеки на ~1.5 КБ, но даёт критически важную информацию — какой конкретно элемент стал LCP, какой обработчик вызвал длинную задачу при INP, какой элемент сдвинулся при CLS. Без этих данных оптимизация превращается в гадание.

Chrome DevTools

Performance-панель в Chrome DevTools — лучший инструмент для глубокого анализа. Записывайте профиль при взаимодействии и ищите:

• Long Tasks (>50 мс) — основной виновник плохого INP
• Layout Shifts — визуально отмечены на таймлайне
• LCP element — подсвечивается в разделе Timings
• Network waterfall — каскадные зависимости загрузки ресурсов

Совет: используйте троттлинг CPU (4x slowdown) и сети (Slow 3G) для имитации условий мобильных пользователей. Ваш MacBook Pro не репрезентативен для среднего пользователя с Android-смартфоном 2022 года.

Продвинутый приём: включите «Web Vitals» overlay в DevTools (Settings → Experiments → Enable Web Vitals overlay). Это покажет LCP, CLS и INP прямо на странице в реальном времени, с подсветкой элементов.

Search Console

Google Search Console показывает CWV-данные в разрезе всего сайта. Это единственный инструмент, который напрямую отражает, как Google оценивает ваш сайт.

Отчёт Core Web Vitals в Search Console:

• Группировка URL по статусу (Good, Needs Improvement, Poor)
• Разделение на мобильные и десктопные
• Детализация до конкретных URL-паттернов
• Уведомления об ухудшении метрик

Пошаговая оптимизация LCP

Шаг 1: ускорьте серверный ответ

TTFB (Time to First Byte) — фундамент LCP. Если сервер отвечает за 1.5 секунды, LCP физически не может быть меньше 1.5 секунды.

Что делать:

• Включите серверное кеширование (Redis, Varnish)
• Используйте CDN — Cloudflare, AWS CloudFront, KeyCDN
• Оптимизируйте базу данных: индексы, кеш запросов, пулы соединений
• Рассмотрите Edge-рендеринг (Cloudflare Workers, Vercel Edge Functions)
• Проверьте, что хостинг справляется с нагрузкой — виртуальный хостинг на 100 сайтов не подойдёт
• Настройте HTTP/2 или HTTP/3 — мультиплексирование запросов критически важно для мобильных

Пример из практики: интернет-магазин с TTFB 1 800 мс. Причина — неоптимизированные запросы к PostgreSQL при генерации каталога. Каждая страница каталога выполняла 47 SQL-запросов, из которых 12 были дублирующими. После добавления индексов, устранения N+1 запросов и внедрения Redis-кеша TTFB упал до 180 мс, LCP — с 5.2 до 1.9 секунды. Конверсия выросла на 23% в первый же месяц.

Шаг 2: оптимизируйте LCP-элемент

Определите, что является LCP-элементом на каждом типе страницы (PageSpeed Insights покажет это).

Для изображений:

• Конвертируйте в WebP или AVIF (экономия 30–60% веса). AVIF даёт лучшее сжатие, но кодируется медленнее — подходит для предгенерированных изображений
• Задайте явные width и height
• Используйте атрибут fetchpriority="high" для hero-изображения
• Добавьте preload: link rel="preload" as="image" href="..."
• Используйте srcset для адаптивных размеров — не грузите десктопное изображение 2000x1000 на мобильный экран 375px
• Рассмотрите генерацию placeholder (LQIP — Low Quality Image Placeholder) для мгновенного отображения

Для текстовых элементов:

• Инлайните критический CSS (то, что нужно для рендеринга первого экрана)
• Подгружайте шрифты с font-display: swap или font-display: optional
• Preconnect к шрифтовым CDN: link rel="preconnect" href="https://fonts.googleapis.com"
• Рассмотрите self-hosting шрифтов — это устраняет дополнительное DNS-разрешение и TLS-хэндшейк

Шаг 3: устраните блокирующие ресурсы

• Перенесите некритический JS в конец body или используйте defer/async
• Разбейте CSS на критический (inline) и некритический (асинхронная загрузка через media="print" onload="this.media='all'")
• Отложите загрузку сторонних скриптов (чат, аналитика, рекламные пиксели) на событие взаимодействия пользователя
• Используйте preload для критических ресурсов: CSS, основной JS-бандл, hero-изображение
• Настройте preconnect для доменов, с которых загружаются ресурсы

Реальный кейс: корпоративный сайт с LCP 4.8 секунды. Причина: 12 синхронных скриптов в head, включая jQuery, 3 аналитики и виджет чата. Общий размер блокирующих ресурсов — 780 КБ. После перевода на defer/async и отложенную загрузку чата LCP стал 1.6 секунды. При этом функциональность сайта не изменилась — пользователь просто получал интерактивный чат через 2 секунды после загрузки, а не сразу.

Шаг 4: оптимизируйте каскад загрузки

Частая проблема: ресурсы загружаются последовательно, хотя могли бы параллельно. Это называется «resource chain» или «waterfall problem».

Типичный каскад: HTML → CSS → @import CSS → @font-face → LCP Image. Каждый шаг ждёт завершения предыдущего. На медленном мобильном соединении каждый шаг — это 200–500 мс.

Решение:

• Устраните @import в CSS — вместо этого используйте несколько link-тегов
• Preload шрифты и LCP-изображение прямо в HTML
• Инлайните критический CSS
• Используйте 103 Early Hints (HTTP-заголовок, который CDN отправляет до основного ответа)

Пошаговая оптимизация CLS

Шаг 1: зарезервируйте пространство для медиа

• Всегда указывайте width и height для img и video
• Используйте aspect-ratio в CSS для контейнеров
• Для рекламных блоков задайте min-height контейнера
• Для iframe (YouTube, Vimeo, карты) указывайте размеры контейнера заранее

Пример CSS для отзывчивого контейнера: Оберните медиа-элемент в div с aspect-ratio: 16/9 и overflow: hidden. Это зарезервирует место до загрузки содержимого.

Шаг 2: стабилизируйте шрифты

• Используйте font-display: optional (предпочтительно) или font-display: swap
• Preload основных шрифтов: link rel="preload" as="font" type="font/woff2" crossorigin
• Убедитесь, что fallback-шрифт максимально близок по метрикам к основному (используйте @font-face с size-adjust, ascent-override, descent-override)
• Инструмент fontaine автоматически генерирует метрически совместимые fallback-шрифты

Шаг 3: обработайте динамический контент

• Cookie-баннеры: выносите в фиксированную позицию (position: fixed), чтобы не сдвигали контент
• Lazy-loaded изображения: оборачивайте в контейнер с заданными размерами
• Динамические списки: используйте CSS-анимации opacity вместо изменения высоты
• Вставка рекламы: резервируйте слот заранее
• Top bar уведомления: используйте CSS transform вместо margin/padding для анимации появления
• A/B-тесты: применяйте изменения на сервере или до первого рендеринга, а не через JavaScript после загрузки

Пример: медиа-сайт с CLS 0.35. Основная причина — рекламные баннеры, вставляемые после загрузки, и уведомление о cookie, сдвигающее весь контент вниз на 60 пикселей. После добавления min-height: 250px к контейнерам баннеров и перевода cookie-уведомления на position: fixed — CLS упал до 0.04. Это заняло 3 часа работы разработчика и дало видимый эффект в CrUX через 28 дней.

Шаг 4: предотвратите сдвиги при скролле

Новая методология подсчёта CLS наказывает за сдвиги не только при загрузке, но и при взаимодействии. Типичные сценарии:

• Подгрузка контента при бесконечном скролле — резервируйте место скелетонами
• Раскрытие аккордеонов — используйте CSS transition высоты вместо мгновенного появления
• Вставка «рекомендуемых материалов» в ленту — загружайте их до того, как пользователь проскроллит до этого места

Пошаговая оптимизация INP

INP — наиболее сложная метрика для оптимизации, потому что она зависит от JavaScript и архитектуры приложения.

Шаг 1: найдите медленные взаимодействия

Используйте Chrome DevTools Performance panel:

1. Откройте вкладку Performance
2. Начните запись
3. Кликайте по интерактивным элементам (кнопки, выпадающие меню, фильтры)
4. Остановите запись и найдите Long Tasks (>50 мс)

Библиотека web-vitals.js с атрибуцией покажет, какой именно элемент и обработчик вызывает задержку.

Практический совет: составьте карту интерактивных элементов на ключевых страницах. Для каждого измерьте INP. Обычно 80% проблем сосредоточены в 2–3 местах: фильтры каталога, выпадающие меню навигации, формы с валидацией.

Шаг 2: разбейте длинные задачи

Главное правило: ни один обработчик события не должен выполняться дольше 50 мс. Если ваш onClick-обработчик работает 200 мс — пользователь ощущает задержку.

Техники разбиения:

• yield to main thread — используйте scheduler.yield() (нативный API в Chrome 129+) или setTimeout(0) для возврата управления браузеру между блоками работы
• requestIdleCallback — для некритичных обновлений (аналитика, логирование)
• Web Workers — выносите тяжёлые вычисления (сортировка, фильтрация большого массива) в отдельный поток
• Виртуализация списков — для каталогов с сотнями элементов используйте react-window или подобные библиотеки
• isInputPending — проверяйте, ждёт ли пользователь ответа, и при необходимости прерывайте длинную задачу

Пример оптимизации: допустим, при клике на кнопку «Применить фильтр» происходит: валидация (5 мс) → фильтрация массива (120 мс) → сортировка (80 мс) → обновление DOM (50 мс). Суммарно 255 мс. Решение: после валидации сделать yield (отдать визуальный фидбек — спиннер), затем фильтрацию в Web Worker, затем yield, затем рендеринг. Итоговый INP: 60–80 мс.

Шаг 3: оптимизируйте фреймворк

React:

• Используйте React.memo, useMemo, useCallback для предотвращения лишних ререндеров
• Переходите на useTransition для некритичных обновлений состояния — это позволяет React «уступить» main thread при обновлении
• Рассмотрите React Server Components для уменьшения клиентского JavaScript
• Профилируйте через React DevTools Profiler: найдите компоненты, которые ререндерятся при каждом клике без необходимости

Vue:

• Используйте v-once для статических поддеревьев
• Применяйте shallowRef и shallowReactive для больших объектов
• Ленивая загрузка компонентов через defineAsyncComponent
• Используйте computed с кешированием вместо methods для тяжёлых вычислений

Vanilla JS:

• Делегирование событий вместо индивидуальных обработчиков
• Debounce для инпутов (200–300 мс)
• requestAnimationFrame для визуальных обновлений
• Batch DOM updates — группируйте изменения DOM, чтобы браузер выполнял layout один раз

Шаг 4: уменьшите объём JavaScript

Каждый килобайт JavaScript — это время на парсинг, компиляцию и выполнение. На среднем мобильном устройстве 1 МБ JavaScript парсится ~2 секунды.

• Проведите аудит бандла (webpack-bundle-analyzer, source-map-explorer)
• Удалите неиспользуемые зависимости (depcheck, knip)
• Настройте code splitting по маршрутам
• Рассмотрите замену тяжёлых библиотек: moment.js (330 КБ) на date-fns (дерево-сотрясаемая, ~12 КБ для типичного использования), lodash (70 КБ gzipped) на нативные методы
• Проверьте tree shaking — убедитесь, что бандлер действительно удаляет неиспользуемый код
• Настройте dynamic import для «тяжёлых» страниц (дашборды, редакторы, калькуляторы)

Кейс: SPA-приложение с INP 450 мс на странице каталога. Причина — фильтрация 3 000 товаров в основном потоке при каждом клике по чекбоксу. Каждый клик запускал полный ререндер списка. Решение: вынесение фильтрации в Web Worker + debounce 150 мс + виртуализация списка (отрисовка только видимых 20 элементов вместо 3 000). Результат: INP снизился до 80 мс, а ещё исчезли «замирания» интерфейса, на которые жаловались менеджеры по продажам.

Core Web Vitals и SEO: реальное влияние

Google использует Core Web Vitals как сигнал ранжирования с 2021 года. Но насколько сильно они влияют?

Честный ответ: Core Web Vitals — один из сотен факторов. Контент, ссылки, релевантность по-прежнему важнее. Но при прочих равных сайт с хорошими метриками получает преимущество.

Что мы видим на практике:

• Улучшение CWV с «красного» до «зелёного» давало рост позиций на 3–8 пунктов в конкурентных нишах
• Основной эффект — не прямое ранжирование, а поведенческие факторы: пользователи дольше остаются на быстром сайте, реже возвращаются в поисковую выдачу
• В мобильной выдаче влияние CWV заметнее, чем в десктопной
• Сайты с хорошими CWV получают больше sitelinks и расширенных сниппетов — косвенное, но измеримое преимущество

Кейс из нашей практики: два конкурирующих интернет-магазина бытовой техники, похожие по ссылочному профилю и контенту. Один оптимизировал CWV (LCP 1.2 с, CLS 0.03, INP 90 мс), другой — нет (LCP 4.1 с, CLS 0.28, INP 380 мс). За 3 месяца первый обошёл второго по 67% совпадающих ключевых запросов, средний рост позиций — 5.3 пункта.

Если ваш сайт нуждается в комплексной оптимизации производительности и SEO-продвижении, начните с аудита сайта — мы покажем, какие метрики проседают и что исправить в первую очередь.

Частые ошибки при оптимизации CWV

Ошибка 1: оптимизация только лабораторных данных

Lighthouse показывает 95 баллов, а в CrUX — красная зона. Причина: Lighthouse не учитывает реальные условия пользователей, A/B-тесты, персонализацию, рекламные блоки.

Решение: всегда сверяйте лабораторные данные с полевыми. Настройте web-vitals.js для непрерывного мониторинга.

Ошибка 2: фокус на главной странице

Многие оптимизируют только главную, а 80% трафика идёт на страницы каталога, карточки товаров и блог. Google оценивает CWV для каждой страницы отдельно.

Решение: проверьте топ-20 страниц по трафику и оптимизируйте их.

Ошибка 3: чрезмерный lazy loading

Когда lazy loading применяется к LCP-элементу — парадокс: вы ухудшаете метрику, пытаясь оптимизировать. Изображение загружается позже, LCP растёт.

Решение: hero-изображение и первые 2–3 изображения на экране должны загружаться без lazy loading, с fetchpriority="high".

Чек-лист: оптимизация Core Web Vitals за 1 спринт

Неделя 1 — диагностика:

• Проверить все ключевые страницы через PageSpeed Insights
• Настроить web-vitals.js с отправкой данных в аналитику
• Составить список проблем с приоритетами
• Определить LCP-элемент на каждом типе страницы

Неделя 2 — LCP и CLS:

• Оптимизировать изображения (WebP/AVIF, preload hero, srcset)
• Устранить блокирующие ресурсы
• Задать размеры всем медиа-элементам
• Стабилизировать шрифты и рекламные блоки
• Настроить CDN и серверное кеширование

Неделя 3 — INP:

• Найти и разбить Long Tasks
• Настроить code splitting
• Оптимизировать обработчики событий
• Провести аудит бандла
• Внедрить виртуализацию для длинных списков

Неделя 4 — мониторинг:

• Настроить алерты при ухудшении метрик
• Проверить CrUX-данные через 28 дней
• Зафиксировать базовые показатели для дальнейшего сравнения
• Добавить CWV-мониторинг в CI/CD (Lighthouse CI)

Что делать прямо сейчас

Откройте PageSpeed Insights, вбейте адрес вашего сайта и посмотрите на полевые данные. Если хотя бы одна из трёх метрик в красной зоне — действуйте. Начните с самой проблемной метрики и двигайтесь по шагам из этого гайда.

А если вам нужна профессиональная помощь — обращайтесь в Lead.Media. Мы оптимизируем Core Web Vitals в рамках создания сайтов и технических аудитов. Наш подход — не «покрасить в зелёный ради галочки», а реально улучшить пользовательский опыт и конверсию.