Браузер и фронтенд-рантайм
Всё вместе: тест с выбором ответа
Суть MCQ на синтез поперёк всего раздела браузера — цепочка-эстафета, uncanny valley гидратации, чтение узкого места по трём трекам и пять канонических поломок.
Высота — путь к senior
НольJuniorMiddleSenior
Ты на senior-высоте — в орбитеШесть вопросов поперёк всего трека браузера — event loop, render pipeline, V8, воркеры, fiber, SSR/SSG и Core Web Vitals, собранные на одной странице. Каждый — решение, которое ты принимаешь, глядя на реальный trace, а не определение для заучивания.
Цель
Убедись, что связываешь каждый слой эстафеты загрузки страницы в одну цепочку: почему симптом регулярно называет не тот слой, почему гидратация — это шарнир и какой трек является узким местом в тот момент, который важен.
Викторина
Completed
Server-rendered страница товара достигает LCP за 1.4 с (хорошо), но первый тап по 'Add to cart' на 2.0 с фиксирует INP 700 мс. Каково структурное объяснение?
Heads-up LCP измеряет момент отрисовки крупнейшего элемента; INP — задержку взаимодействия. Они независимы — быстрая отрисовка серверного HTML не защищает интерактивность, пока гидратация блокирует main thread.
Heads-up При тапе внутри окна гидратации большая часть 700 мс — это input delay, время в очереди за длинной задачей, а не processing обработчика. Оптимизация обработчика, который не был узким местом, ничего не сдвинет.
Heads-up Страница уже отрисовалась на 1.4 с, значит байты пришли. Задержка взаимодействия после отрисовки — это проблема main thread (гидратация), а не сети.
Викторина
Completed
DevTools trace показывает поздний LCP, при этом hero-картинка всё ещё на network-треке в момент LCP. Какой слой — реальная причина, а какой за неё платит?
Heads-up Если картинка всё ещё качается в момент LCP, до композитора она не дошла. Pipeline в порядке; сбой в том, что discovery произошёл слишком поздно на слое парсинга.
Heads-up Render-blocking JS — это другая ветка: hero загрузился рано, но main thread занят. Здесь hero всё ещё на network-треке, так что узкое место — discovery, а не V8.
Heads-up Ресурс, всё ещё качающийся в момент LCP, — это симптом network-трека, коренящийся в discovery. GPU компонует только то, что уже пришло и было отрисовано.
Викторина
Completed
Ре-рендер по 'Add to cart', который должен стоить ~5 мс, стоит ~80 мс и роняет INP, хотя бандл маленький, а обработчик короткий. Какова наиболее вероятная межслойная причина?
Heads-up Reconciler в других местах проходил то же дерево быстро. Ре-рендер 80 мс при коротком обработчике указывает на мегаморфный путь в V8, а не на reconciler — это классическая мисатрибуция 'React медленный'.
Heads-up Синхронная стоимость ре-рендера на main thread — не сетевое событие. Запрос данных показался бы на network-треке, пока main thread свободен, а не как scripting внутри взаимодействия.
Heads-up CLS измеряет визуальную стабильность, а не задержку взаимодействия. Полоса scripting 80 мс внутри тапа — это проблема INP из-за медленного выполнения, а не сдвиг layout.
Викторина
Completed
Деплой выкатывает новый HTML и новый JS-бандл, но часть вернувшихся пользователей ловит runtime-ошибки, а некоторые застревают на сломанной странице даже после деплоя фикса. Какая каноническая поломка и какой слой?
Heads-up Mismatch мигает контентом и поднимает CLS внутри сессии; он не переживает деплой и не ловит пользователей на старом коде. Сохранение поперёк деплоев и обход фикса — это сигнатура устаревшего кэша воркера.
Heads-up Новый бандл задеплоился нормально; проблема в клиентском кэше (service worker), который отдаёт СТАРЫЙ бандл против нового HTML. Сброс CDN не освободит пользователей, запертых за их собственным воркером.
Heads-up Мегаморфизм бьёт по INP, а не по корректности поперёк деплоев. Runtime-ошибки от рассинхрона версий плюс пользователи, запертые на сломанной оболочке, — это statefulness: кэш пережил свою корректность.
Викторина
Completed
Джуниор оптимизирует обработчик 'Add to cart' с 12 мс до 6 мс; полевой INP остаётся 480 мс. Что, по методу трёх треков, надо было сделать сначала?
Heads-up Processing-время обработчика никогда не было узким местом. INP держится на 480 мс, потому что тап встаёт в очередь за длинной задачей гидратации; никакая оптимизация обработчика этот input delay не трогает.
Heads-up CSR убирает гидратацию, но возвращает пустую первую отрисовку и худшие LCP и SEO — обмен одной проблемы на две. Фикс — сократить то, что гидратируется (code-split, Server Components, islands), а не отказываться от SSR.
Heads-up Гидратация — это в основном одна длинная задача main thread; лишние ядра её не делят. Рычаг — меньше парсить, компилировать и выполнять: меньший бандл и меньше гидратируемых islands.
Викторина
Completed
Одна RUM-сессия плоха по всем метрикам: TTFB 2980 мс, LCP 6800 мс (hero — это CSS background-image), INP 540 мс (LoAF называет скрипт гидратации), CLS 0.21 (цена ре-рендерилась). Какой единственный фикс имеет наибольший рычаг для старта и почему?
Heads-up CLS — реальный баг, но фикс mismatch цены оставляет пол TTFB ~3 с нетронутым. Рычаг — это про то, сколько метрик ниже по цепочке зависят от фикса, а FCP и LCP оба сидят поверх TTFB.
Heads-up Skeleton прячет ожидание, но не двигает ни одну метрику — main thread всё ещё заблокирован, а байты всё ещё приходят на 2980 мс. Это лечит восприятие, а не узкое место.
Heads-up INP важен, но его корень здесь — длинная задача гидратации ниже бандла. При TTFB 2980 мс paint не может даже начаться ~3 с; фикс пола каскадит в FCP и LCP, так что TTFB — рычаг более высокого приоритета на старте.
Итог
Сквозная линия через весь трек — одна цепочка: TTFB — это пол, discovery кормит LCP, парсинг V8 плюс reconciler кормят длинную задачу гидратации, и эта задача — шарнир, определяющий ранний INP. Симптом регулярно называет не тот слой — ‘медленная картинка’ — это discovery, ‘React медленный’ — это мегаморфная форма V8, ‘сломалось после деплоя’ — это устаревший кэш воркера. Дисциплина всегда одна: измерить до того, как трогать, найти узкий трек в узкий момент, починить доминирующую причину (TTFB и стоимость гидратации первыми), затем перемерить.