Браузер и фронтенд-рантайм
Core Web Vitals: тест с выбором ответа
Суть Тест с выбором на синтез по всему юниту Core Web Vitals — пороги, вердикт field-vs-lab, фазы LCP, ловушка гидрации для INP, подсчёт CLS и компромиссы общего бюджета.
Высота — путь к senior
НольJuniorMiddleSenior
Ты на senior-высоте — в орбитеШесть вопросов поперёк всего юнита. Каждый отражает решение, которое ты принимаешь, читая реальный отчёт PageSpeed или полевой дашборд — не определение для заучивания, а какому числу верить и за какой фикс хвататься.
Цель
Убедись, что связываешь три порога, вердикт field-vs-lab, разбиения на фазы и части, и общий бюджет производительности — тот синтез, к которому вели отдельные уроки.
Викторина
Completed
PageSpeed Insights показывает LCP 1.8 с в секции Lighthouse (зелёный) и LCP 3.9 с по field p75 (красный). Команда говорит: 'лаба говорит, что всё ок, ничего не делаем.' Как правильно это читать?
Heads-up Воспроизводимо — не значит репрезентативно. Лаба намеренно фиксирует одно устройство и сеть — это делает её хорошей для отладки, но не для вердикта. Ранжирование использует field p75.
Heads-up Число из лабы и полевой перцентиль — разные виды измерений; усреднять их бессмысленно. Field p75 самодостаточен как пережитое пользователем и релевантное ранжированию значение.
Heads-up TTFB — одна фаза LCP, а не замена ей. Оба числа LCP валидны — они по-разному отвечают на вопрос синтетика-vs-реальный пользователь — и полевое и есть вердикт.
Викторина
Completed
У server-rendered страницы плохой INP, но только для взаимодействий в первые ~3 секунды; после этого каждый тап нормальный. Обработчики тапа выполняются за 8 мс. Где проблема и каков фикс?
Heads-up Если бы причиной были обработчики, INP был бы плохим для каждого взаимодействия, а не только для ранних. Обработчик за 8 мс не создаёт ограниченный во времени паттерн — эта сигнатура указывает на гидрацию.
Heads-up Задержка сервера влияет на TTFB и LCP, а не на задержку взаимодействия в основном потоке, которую измеряет INP — и не создала бы паттерн INP только в начале.
Heads-up Размер картинки определяет load time у LCP. Он не блокирует основной поток для взаимодействий; это вопрос JavaScript/гидрации, на что и указывает паттерн только в начале.
Викторина
Completed
LCP-атрибуция web-vitals показывает TTFB 280 мс, load delay 90 мс, load time 3510 мс, render delay 240 мс. Элемент — hero-картинка JPEG 3.8 МБ 4000×3000. Каков фикс с наибольшим рычагом?
Heads-up Load delay всего 90 мс — обнаружение уже быстрое. fetchpriority/preload чинят load DELAY, а не load TIME. Чинить не ту фазу — классическая ошибка с LCP.
Heads-up TTFB — 280 мс, маленький кусок. Срезать его почти ничего не даст против load time в 3510 мс. Сначала читай разбиение по фазам; чини доминирующую.
Heads-up Render delay — 240 мс. Инлайнинг CSS бьёт по render-blocking ресурсам, которые здесь не узкое место. Узкое место — скачивание картинки в 4 МБ.
Викторина
Completed
Один layout shift сдвигает элемент в пол-вьюпорта вниз на 20% высоты вьюпорта, без взаимодействия пользователя за предыдущие 500 мс. Сколько он набирает, и CLS страницы автоматически плохой?
Heads-up Оценка — произведение, а не сумма: impact fraction × distance fraction = 0.5 × 0.2 = 0.1. Сложение — распространённая арифметическая ошибка.
Heads-up Наоборот — исключение в 500 мс убирает сдвиги, которые СЛЕДУЮТ за взаимодействием. Беспричинный сдвиг — именно то, что наказывает CLS; этот набирает 0.1.
Heads-up Нет порога pass/fail на отдельный сдвиг. CLS — сумма худшего session window в 5 с; одиночный сдвиг 0.1 сидит на границе good, а не в 'poor'.
Викторина
Completed
Команда инлайнит весь bundle критического CSS, чтобы срезать render delay у LCP на 400 мс. LCP в лабе улучшается, но ты возражаешь перед мержем. Почему?
Heads-up Инлайнинг критического CSS сам по себе не задирает INP — он убирает render-blocking запрос. Реальная забота — компромисс размер-HTML/TTFB, знак которого зависит от скорости соединения и размера bundle.
Heads-up Render-blocking CSS напрямую задерживает paint LCP-элемента (render delay), так что инлайнинг критического CSS может помочь LCP. Подвох — в цене TTFB, а не в нерелевантности.
Heads-up Фиксы из лабы вполне могут двигать field — в этом и смысл отладки в лабе. Проблема в проверке чистого эффекта по всем трём метрикам, а не в игнорировании результатов лабы.
Викторина
Completed
SPA выдаёт зелёные Core Web Vitals на первой загрузке, но пользователи жалуются, что клиентские смены маршрута ощущаются вялыми. Почему метрики могут это пропустить и каков фикс?
Heads-up Зелёные числа на первой загрузке не покрывают soft navigations. Быстрая первая загрузка плюс вялые переходы маршрута — реальный, исторически недомеренный режим отказа в SPA.
Heads-up CrUX не неверен; разрыв в том, что soft navigations не испускают стандартное событие load, поэтому vitals им не атрибутировались. Поддержка soft-navigation в Chrome и явная RUM-инструментация закрывают разрыв.
Heads-up У SPA могут быть хорошие vitals — проблема в покрытии измерений смен маршрута, а не в архитектурной невозможности. Инструментируй soft navigations, а не бросай SPA.
Итог
Сквозная линия юнита — одна диагностическая дисциплина: LCP/INP/CLS — это полевые метрики на p75 (≤2.5 с, ≤200 мс, ≤0.1), и только field data из CrUX — вердикт ранжирования: отлаживай в лабе, суди по field. LCP читают по разбиению на четыре фазы, а INP — по разбиению на три части, поэтому чинишь доминирующую фазу, а не удобную. Паттерн INP только в начале означает гидрацию, а не обработчики. CLS — это impact × distance, просуммированный по худшему окну 5 с, с исключением 500 мс после взаимодействия. И все три делят бюджет — каждое изменение надо мерить против всех них, никогда одну в изоляции.