Core Web Vitals 2026: пороговые значения LCP, INP и CLS

Google оценивает пользовательский опыт веб-сайтов с помощью трех основных показателей, подкрепленных метриками серверного уровня, такими как Time to First Byte (TTFB). Каждая метрика содержит три оценки производительности: Хорошо, Требует улучшения и Плохо. Google рассчитывает эти показатели независимо для мобильных и настольных посещений, используя данные реальных пользователей, собранные в отчете Chrome User Experience Report.

• Largest Contentful Paint (LCP): Хорошо — 2,5 секунды или меньше; Плохо — более 4,0 секунд.
• Interaction to Next Paint (INP): Хорошо — 200 миллисекунд или меньше; Плохо — более 500 миллисекунд.
• Cumulative Layout Shift (CLS): Хорошо — 0,1 или меньше; Плохо — более 0,25.
• Time to First Byte (TTFB): Хороший целевой показатель — 0,8 секунды или меньше для поддержки начальной доставки ответа.

Чтобы получить проходной балл в отчетах Search Console, 75 процентов посещений страниц, записанных в течение 28-дневного окна, должны достигать порога «Хорошо» для каждой метрики. Если хотя бы одна метрика на 75-м процентиле попадает в категорию «Требует улучшения» или «Плохо», URL не проходит общую оценку.

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

Порог 75-го процентиля гарантирует, что большинство посетителей получают высокопроизводительный веб-опыт. Если 74 процента мобильных сессий загружаются менее чем за 2,5 секунды, но 26 процентов испытывают более длительное время ожидания, страница попадает в категорию «Требует улучшения». Этот подход побуждает технические команды создавать устойчивые сайты, которые стабильно работают на бюджетных устройствах и при более медленных соединениях.

Largest Contentful Paint отслеживает время, необходимое для отрисовки основного элемента контента в области просмотра пользователя, такого как изображение главного баннера, миниатюра видео или большой текстовый блок. Высокие значения LCP обычно связаны с медленным временем ответа сервера, рендерингом, блокирующим CSS или JavaScript, и задержкой загрузки ресурсов. Стремитесь к Time to First Byte (TTFB) 0,8 секунды или меньше, чтобы дать браузеру достаточно времени для загрузки критических ресурсов.

В типичном интернет-магазине с изображениями высокого разрешения главное изображение на страницах продуктов часто служит элементом LCP. Когда веб-страницы применяют отложенную загрузку (lazy loading) к медиа в первом экране, браузеры задерживают загрузку этих ресурсов до завершения выполнения JavaScript. Чтобы ускорить загрузку, удалите отложенную загрузку с главных изображений заголовка и примените атрибут fetchpriority=”high” непосредственно к HTML-тегу.

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

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

Чтобы удерживать INP ниже 200 миллисекунд, фронтенд-код должен избегать выполнения длительных задач, превышающих 50 миллисекунд. Разработчики могут разбивать монолитные функции на более мелкие асинхронные блоки выполнения, используя нативные API-опции, такие как setTimeout или scheduler.yield(). Это позволяет основному потоку браузера быстро обрабатывать события пользователя между шагами выполнения.

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

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

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

• Укажите явные атрибуты ширины и высоты для всех HTML-элементов изображений и видео или определите явные соотношения сторон с помощью CSS.
• Зарезервируйте выделенные контейнеры макета для динамического контента, такого как рекламные баннеры и панели уведомлений, чтобы предотвратить прыжки окружающих элементов.
• Используйте font-display: swap или font-display: optional вместе с предварительной загрузкой шрифтов, чтобы устранить сдвиги текста, вызванные задержками загрузки веб-шрифтов.
• Избегайте внедрения нового HTML-контента поверх существующих видимых элементов после рендеринга страницы, если это явно не инициировано прямым действием пользователя.