Core Web Vitals в 2026: пороги и что изменилось
Метрики в этом году не поменялись. Инструменты вокруг них поменялись изрядно. Разбираем, что верно прямо сейчас.
Три метрики, и те же самые с 2024 года. Largest Contentful Paint должен укладываться в 2,5 секунды или меньше, Interaction to Next Paint — в 200 миллисекунд или меньше, Cumulative Layout Shift — в 0,1 или меньше. Каждая оценивается по 75-му процентилю реальных загрузок страницы, отдельно для мобильных и десктопа.
Какие пороги у Core Web Vitals в 2026 году
Цифры взяты прямо со страниц метрик на web.dev, где Google публикует определения. Всё считается по 75-му процентилю загрузок: порог пройден, когда хороший результат получают три четверти реальных посетителей, а не ваш ноутбук.
| Метрика | Что измеряет | Хорошо | Требует улучшения | Плохо |
|---|---|---|---|---|
| LCP | Загрузка: момент, когда дорисовался самый крупный видимый элемент | 2,5 секунды или меньше | от 2,5 до 4,0 секунды | больше 4,0 секунды |
| INP | Отзывчивость на всех взаимодействиях со страницей | 200 мс или меньше | больше 200 мс и до 500 мс | больше 500 мс |
| CLS | Визуальная стабильность: худшая серия неожиданных сдвигов | 0,1 или меньше | больше 0,1 и до 0,25 | больше 0,25 |
Менялись ли Core Web Vitals в 2026 году
Нет. Ни набор метрик, ни один порог. Последнее структурное изменение случилось 12 марта 2024 года, когда Interaction to Next Paint стала стабильной метрикой Core Web Vitals, а First Input Delay был выведен из состава, о чём web.dev сообщил в записи INP becomes a Core Web Vital. С тех пор набор состоит из трёх стабильных метрик, и никакой экспериментальной или готовящейся замены не названо. Собственное правило Google гласит, что стабильные Core Web Vitals меняются не чаще одного раза в год, и 2025-й с 2026-м прошли без изменений.
Что действительно сдвинулось, так это слой измерений. В release notes Chrome UX Report на Chrome for Developers зафиксировано, что подчасти LCP-изображения и типы LCP-ресурсов появились в CrUX API в январе 2025 года, что в том же выпуске измерение ECT убрали из BigQuery, а старый CrUX Dashboard был признан устаревшим в конце ноября 2025 года. Отдельно работа над мягкими навигациями дошла до Chrome 151: одностраничные приложения теперь могут относить LCP, INP и CLS к отдельным сменам маршрута, а не к одному бесконечному просмотру страницы. В документации прямо сказано, что способ учёта мягких навигаций в CrUX пока не определён, так что на ваши цифры в Search Console это ещё не влияет.
Если вам сказали, что в этом году появилась новая метрика, спросите, какая именно. Её нет.
Как исправить медленный LCP
Почти всякий плохой LCP — это проблема обнаружения ресурса. Руководство по главным исправлениям на web.dev ставит вперёд три вещи: LCP-ресурс должен быть виден в исходном HTML, а не подставляться скриптом; ему нужен атрибут fetchpriority="high"; Time to First Byte стоит сократить с помощью CDN, который кэширует сам документ. Дальше стремитесь к мгновенным переходам через кэш назад-вперёд или правила спекулятивной загрузки, чтобы следующая страница была готова ещё до клика.
Как исправить высокий INP
INP раскладывается на три части: задержка ввода до запуска обработчика, длительность работы самого обработчика и задержка до отрисовки следующего кадра. Итоговая оценка — это примерно худшее взаимодействие на странице, причём один выброс на каждые пятьдесят взаимодействий отбрасывается. Рекомендуемые исправления: чаще уступать управление, чтобы длинные задачи не блокировали основной поток; изначально отдавать меньше JavaScript; держать обновления рендеринга небольшими за счёт скромного DOM и CSS containment. Проверьте свой менеджер тегов. Обычно дело в нём.
Как убрать сдвиги макета
CLS смотрит на худшую серию сдвигов: это сдвиги с интервалом меньше секунды внутри окна не длиннее пяти секунд. Задавайте явные width и height или соотношение сторон каждому изображению и встраиваемому блоку, резервируйте место под всё, что подгружается позже, вроде баннеров и панелей согласия, сохраняйте страницу пригодной для кэша назад-вперёд и анимируйте через transform, а не через свойства, которые заставляют пересчитывать макет.
Где измерять Core Web Vitals
Всегда сначала полевые данные. Лабораторные инструменты нужны, чтобы ловить регрессии до релиза, и web.dev прямо говорит, что заменой реальным пользователям на реальных устройствах они не служат. Полевой набор данных — это Chrome User Experience Report. И PageSpeed Insights, и отчёт Core Web Vitals в Search Console читают именно его, а JavaScript-библиотека web-vitals даёт ваши собственные цифры с куда меньшей задержкой, чем скользящее окно в 28 дней. Chrome DevTools и Lighthouse закрывают лабораторную сторону. Пользуйтесь и тем и другим, но зачёт ставят только полевые данные.
Влияют ли Core Web Vitals на позиции в Google
Google Search Central по-прежнему описывает Core Web Vitals как часть page experience: это метрики реального пользовательского опыта, и они согласуются с тем, что стремятся вознаграждать основные системы ранжирования. Формулировка намеренно мягче, чем «фактор ранжирования». Считайте это тайбрейкером между сопоставимыми в остальном страницами и вещью, которая заметно влияет на конверсию независимо от того, что делает поиск. Та же логика касается всего технического фундамента, а его как раз проверяет наш чекер AI-готовности.
Одно замечание тем, кто гонится за идеальным баллом: пройденные все три порога на 75-м процентиле — это финиш. Уровня выше не предусмотрено. Как только всё зелёное, следующий час полезнее потратить на вопрос, доберутся ли краулеры до страницы вообще, а это пятиминутная проверка в вашем robots.txt.