Три полевые метрики, которые реальные пользователи Chrome генерируют при каждом посещении — и почему вся остальная работа по производительности в этом пилларе в конечном счёте сводится к этим трём числам.
Страница загружается. Появляется hero-фото. Пользователь тапает кнопку и ждёт. Реклама врывается сверху и текст прыгает — пользователь тапает не на ту ссылку. Всё в этом пилларе — event loop, пайплайн рендера, V8, гидратация — порождает именно такой опыт. Три полевые метрики его измеряют, и по ним Google ранжирует страницы. Через десять минут ты будешь знать, какая метрика ловит какой сбой — и почему lab-оценка с твоей машины не та, что влияет на ранжирование.
Три метрики — по одному вопросу каждая.
Прежде чем чинить проблему производительности, нужно знать, какой из трёх пользовательских вопросов она нарушает. Каждая Core Web Vital отвечает ровно на один:
LCP — Largest Contentful Paint — быстро ли появился главный контент? Хорошо: ≤2.5 с.
INP — Interaction to Next Paint — отвечает ли страница, когда я тапаю или печатаю? Хорошо: ≤200 мс.
CLS — Cumulative Layout Shift — стояло ли всё на месте, или кнопка выпрыгнула из-под пальца? Хорошо: ≤0.1 (безразмерная оценка).
Каждый порог измеряется на 75-м перцентиле реальных пользователей. Это важно: оптимизация только под быстрые устройства прячет медленную четверть аудитории — а именно её отражает оценка.
Метафора магазина.
Зайти в магазин — самый чёткий фрейм для этих трёх метрик. LCP — сколько времени, прежде чем вы видите, что продаёт магазин: если полки ещё заполняют, вы ждёте у двери. INP — отвечает ли продавец сразу, когда вы задаёте вопрос: хороший магазин отвечает немедленно, плохой заставляет повторять. CLS — стоит ли пол на месте: представьте, что тянетесь за товаром, и полка съезжает вбок ровно в этот момент — вы хватаете не то. Хорошая страница — хороший магазин.
Откуда берутся числа — и почему это важно.
Core Web Vitals в том виде, в котором их оценивает Google, берутся с реальных пользователей Chrome в поле, а не из тестового прогона на машине разработчика. Публичный датасет называется CrUX — Chrome User Experience Report. Он агрегирует визиты от пользователей Chrome, давших согласие на отчётность, и именно field p75 из CrUX использует ранжирование в поиске. Отличный Lighthouse-score на ноутбуке и плохие field vitals — вполне совместимые вещи. Именно field-число имеет значение.
На практике это означает: каждый фикс производительности в этом пилларе в конечном счёте живёт или умирает в зависимости от того, двигает ли он field p75 для реальных пользователей. Лабораторные инструменты (Lighthouse, DevTools) — для отладки и перехвата регрессий; CrUX — вердикт.
Хорошие пороги Core Web Vitals (при field p75)
LCP — Largest Contentful Paint
≤2.5 с
INP — Interaction to Next Paint
≤200 мс
CLS — Cumulative Layout Shift
≤0.1
Один пользовательский опыт, три фазы. Быстро ли появилось (LCP)? Отвечает ли на тап (INP)? Стоит ли на месте (CLS)? Каждая vital оценивает одну фазу, все на field p75 реальных пользователей Chrome.▸Почему это работает
INP заменила First Input Delay (FID) как Core Web Vital в марте 2024. FID измерял только задержку до старта обработчика первого ввода — она пропускала весь остальной жизненный цикл страницы. INP измеряет полную задержку input-to-paint каждого взаимодействия на протяжении всей сессии и репортит высокий перцентиль из них — это куда ближе к тому, что пользователь реально чувствует, используя страницу, а не просто заходя на неё.
Расставь шаги по порядку
Completed
Сопоставьте жалобу пользователя с Core Web Vital — расставьте в порядке LCP, INP, CLS.
1LCP — «страница вечность показывала статью»
2INP — «я тапнул кнопку, и секунду ничего не происходило»
3CLS — «текст прыгнул, я потерял место / тапнул не туда»
Викторина
Completed
Пользователь тапает кнопку, и страница видимо не отвечает почти секунду. Какая Core Web Vital это ловит?
Heads-up LCP измеряет, когда самый крупный контент впервые появляется при загрузке. Задержанный отклик на тап — это про интерактивность, это INP.
Heads-up CLS измеряет неожиданное движение лейаута. Медленный отклик — не движение, а задержка, это INP.
Heads-up TTFB — сетевая метрика для первого байта от сервера. Задержка кнопки случается намного позже, в браузере.
Викторина
Completed
Откуда берутся числа Core Web Vitals, когда Google использует их для ранжирования в поиске?
Heads-up Лабораторный тест — один синтетический прогон. Core Web Vitals в том виде, в каком их оценивает Google, — полевые данные, агрегированные с реальных пользователей.
Heads-up Локальный DevTools — лабораторный инструмент. Он полезен для отладки, но оцениваемые vitals берутся из полевых данных реальных пользователей.
Heads-up Серверные логи не захватывают тайминг отрисовки или задержку взаимодействия в браузере. Vitals измеряются на клиенте с реальных пользователей.
Закончи аналогию
Completed
В метафоре магазина одна vital про то, стоит ли пол на месте — съезжает ли полка вбок ровно когда вы тянетесь за товаром, заставляя схватить не то. Какая это Core Web Vital?
Answer
CLS — CLS — Cumulative Layout Shift — измеряет, насколько неожиданно лейаут страницы движется. Классическая причина — контент, грузящийся поздно (картинка без зарезервированного места, реклама, смена веб-шрифта), и сдвигающий всё ниже вниз. Пользователю это ощущается как съезжающий пол магазина: он тянется к кнопке, а она вдруг в другом месте, и он тапает не туда. Хороший CLS означает, что лейаут стабилен: вещи грузятся в место, зарезервированное под них заранее.
Посчитай
Completed
«Хороший» LCP достигается, когда самый крупный контент рисуется в пределах скольки секунд, на 75-м перцентиле реальных пользователей?
секунды
Answer · 2.5 секунды
2.5 секунды — «хороший» порог LCP. Самый крупный contentful-элемент — обычно hero-картинка или блок заголовка — должен нарисоваться в пределах 2.5 с для 75% реальных визитов. Между 2.5 с и 4 с — «нужно улучшение»; больше 4 с — «плохо». 75-й перцентиль важен: оптимизация только под быстрые устройства прячет медленную четверть ваших пользователей, и именно её отражает оценка.
Вспомните перед уходом
01
Что измеряет каждая Core Web Vital — одной фразой на метрику?
02
Почему порог на 75-м перцентиле полезнее среднего для этих метрик?
03
Что такое CrUX и почему он важнее Lighthouse для SEO?
Итог
Core Web Vitals — это три полевые метрики, отвечающие на то, что замечают реальные пользователи: LCP (появился ли главный контент за 2.5 с), INP (ответила ли страница на тап за 200 мс), CLS (стоял ли лейаут на месте, оценка ≤0.1). Они измеряются на 75-м перцентиле реальных пользователей Chrome через CrUX — не из лабораторного теста — и именно CrUX p75 использует ранжирование в поиске. Каждый приём оптимизации производительности в этом пилларе — сокращение длинных задач для INP, оптимизация доставки изображений для LCP, резервирование места для CLS — в конечном счёте существует, чтобы двигать эти три field-числа. Отлаживайте в лабе; судите по полю. Теперь, когда встретишь жалобу на производительность — медленный контент, кнопки без отклика, прыгающий текст — сразу будешь знать, какую vital проверять первой и какой источник даёт реальный вердикт.
Практика
Начни сверху. Задачи идут от простого к сложному: вспомнить факт, применить к случаю, затем senior-уровень. Открой, попробуй, потом открой ответ.