Архитектура фронтенда
Data fetching: тест с множественным выбором
Суть Синтез всего юнита data fetching в формате выбора — место fetch, waterfall'ы, RSC streaming, SWR-кэш, LCP и многослойная инвалидация.
Высота — путь к senior
НольJuniorMiddleSenior
Ты на senior-высоте — в орбитеШесть вопросов через весь юнит. Каждый отражает решение, которое ты принимаешь на реальном перф-ревью — не определение для пересказа, а компромисс, который надо взвесить против бюджета LCP и риска устаревших данных.
Цель
Убедись, что связываешь место fetch, waterfall’ы, RSC streaming, клиентский кэш и многослойную инвалидацию в одно решение: какие round-trip’ы лежат на critical path и что на самом деле покупает каждый фикс.
Викторина
Completed
Страница товара рендерит заголовок (LCP-элемент) из клиентского useEffect-fetch. LCP равен 2.9s. Команда добавляет скелетон загрузки и поднимает TTL CDN-кэша. LCP почти не двигается. Какой фикс настоящий?
Heads-up fetchpriority — про обнаружение ресурсов (картинки, шрифты), а не про вызов API через JS. Заголовок заперт за загрузкой бандла и mount, до которых fetchpriority не дотягивается.
Heads-up Кэширование HTML скелетона ничего не меняет — LCP-элемент это заголовок, и он по-прежнему ждёт клиентский fetch после запуска JS. TTL CDN на оболочке эту цепочку не схлопывает.
Heads-up HTTP/3 срезает немного латентности handshake, но оставляет последовательный порядок bundle-затем-mount-затем-fetch нетронутым. Выигрыш — серверный fetch, а не более быстрый транспорт.
Викторина
Completed
Страница профиля грузит user (200ms), posts (300ms) и followers (150ms) — все независимые — через три вложенных useEffect-компонента. Суммарно ~650ms. Почему, и что ограничивает это до ~300ms?
Heads-up Браузер разрешает несколько одновременных соединений на origin; сериализация здесь — каскад рендера React, а не лимиты соединений. Promise.all запускает все три сразу независимо от этого.
Heads-up Вложенные useEffect-fetch'и реально складываются, потому что каждый ребёнок не может смонтироваться, пока родитель не перерендерится с данными. 650ms — реальный waterfall, а не шум.
Heads-up staleTime управляет временем рефетча на повторных визитах, а не waterfall'ом первой отрисовки. На холодной загрузке кэша нет; fetch'и всё равно сериализуются.
Викторина
Completed
Команда помечает каждый компонент 'use client' в Next.js App Router, а потом жалуется, что RSC не дал выигрыша по бандлу. Что произошло?
Heads-up RSC реально отгружает ноль JS для server components — реальное приложение может упасть с ~240KB до ~60KB. Команда победила это, опт-инув каждый компонент в клиент.
Heads-up Streaming снижает TTFB, а не размер бандла. Выигрыш по бандлу приходит чисто от удержания неинтерактивных компонентов на сервере, чему 'use client' везде мешает.
Heads-up Tree-shaking удаляет мёртвый код, а не реально используемые интерактивные компоненты. Каждый лист 'use client' — реальный код, который браузер обязан выполнить; поэтому бандл остался большим.
Викторина
Completed
RSC-страница грузит данные на сервере, затем клиентский компонент вызывает useQuery за теми же данными при монтировании — каждая загрузка страницы делает два round-trip'а за один датасет. Какой фикс правильный?
Heads-up Клиентскому компоненту нужен query для интерактивности после монтирования (фоновая ревалидация, мутации). Удаление теряет это; правильный ход — засеять его кэш, а не удалять query.
Heads-up staleTime=0 заставляет клиент рефетчить сразу при монтировании — это гарантирует двойной fetch, а не предотвращает его. Дегидрация — то, что убирает второй trip.
Heads-up Дешёвый второй fetch — всё равно второй round-trip и всё равно запрос от клиента. Ловушка dual-fetch чинится разделением уже загруженных сервером данных через гидрацию, а не кэшированием дубликата.
Викторина
Completed
Поле search-as-you-type шлёт fetch на каждое нажатие. Пользователь печатает 'react', но видит результаты для 'reac'. Ни один из запросов не падает. Первопричина и лучший фикс?
Heads-up Сервер вернул корректные результаты на каждый полученный запрос; баг на клиенте — более медленный ответ 'reac' пришёл последним и затёр более новое состояние 'react'.
Heads-up Батчинг React влияет на планирование перерендера внутри тика, а не на порядок прихода независимых сетевых ответов. Гонка между fetch'ами, а не внутри батчера React.
Heads-up staleTime управляет тем, когда кэшированные данные рефетчатся, а не тем, какой из двух in-flight ответов победит. Гонку решает только отмена или версионирование queryKey.
Викторина
Completed
После мутации, обновляющей товар, сервер ревалидирует свой кэш, но пользователи несколько минут видят старую цену. Server Function корректно вызвала revalidateTag. Что упустили?
Heads-up revalidateTag работает в Server Functions и сделал своё дело на сервере. Устаревшие данные жили в нетронутом клиентском query-кэше — отдельном слое.
Heads-up Короткий TTL обновил бы раньше, а не закрепил устаревшие данные на минуты. Стойкая устарелость — это клиентский кэш, держащий старый ответ в течение собственного времени жизни.
Heads-up DB/Redis-кэш инвалидируется кодом приложения и является одним из слоёв здесь, но симптом — старые данные только в браузере — указывает на клиентский кэш библиотеки, до которого revalidateTag никогда не дотягивается.
Итог
Сквозная линия юнита — одна карта critical path. Место fetch решает, сколько round-trip’ов предшествует LCP: server fetch их схлопывает, client fetch после JS их складывает. Waterfall’ы пересериализуют независимые fetch’и через каскад рендера; Promise.all и соседние RSC-компоненты ограничивают их самым медленным. RSC отгружает ноль JS только для компонентов, остающихся на сервере, а Suspense streaming покупает низкий TTFB. Клиентский кэш (SWR-семантика, single-flight, оптимистичные снимки) управляет повторными визитами и взаимодействиями, а AbortController убивает гонки. И каждая мутация должна инвалидировать каждый затронутый слой кэша — одной серверной ревалидации мало, браузер останется устаревшим.