Браузер и фронтенд-рантайм
Стратегии рендеринга: per-route аудит рендеринга
Читать про стратегии рендеринга — не то же, что выбирать одну на маршрут под реальными ограничениями. Соберите небольшое приложение из четырёх маршрутов, назначьте каждому стратегию по требованиям свежести и интерактивности, затем докажите выборы через TTFB, LCP, INP и счётчик hydration mismatch — и исправьте найденные регрессии.
Превратите двухосевую модель юнита в воспроизводимый инженерный цикл: выбрать стратегию на маршрут, минимизировать поверхность hydration через RSC и острова, защитить детерминизм рендера, инструментировать метрики, ловящие регрессии, и проверить каждое решение числами до/после.
Соберите (или возьмите) небольшое приложение из четырёх маршрутов — маркетинговая главная, страница товара с часто меняющейся ценой, per-user дашборд с одним медленным запросом и форма checkout — назначьте каждому маршруту верную стратегию рендеринга и докажите каждый выбор измеренными TTFB, LCP, INP и нулевым счётчиком hydration mismatch.
- Таблица по маршрутам: выбранная стратегия, TTFB, LCP, INP (p75) и размер бандла — измеренные, не оценочные — с однострочным обоснованием на маршрут.
- Маршрут с hydration mismatch показывает предупреждение и CLS до исправления и ноль предупреждений mismatch с CLS, вернувшимся к ~0, после — оба зафиксированы.
- Waterfall дашборда показывает сброс оболочки первой (~50 мс) с медленной границей, подгружаемой потоком позже; удаление Suspense-границы заметно задерживает TTFB до ~400 мс.
- INP на p75 остаётся под 200 мс на каждом маршруте, и клиентский бандл измеримо сокращается после опускания 'use client' до листьев.
- Абзац-резюме: для каждого маршрута драйвер свежесть × интерактивность за стратегией и почему она победила альтернативы.
- Добавьте CI-гейт, валящий билд на любом новом hydration mismatch и на регрессии INP-p75 выше 200 мс на канареечном маршруте.
- Сравните распространение on-demand ревалидации ISR между имитированными CDN POP: покажите короткое окно, где одни POP отдают старое, а другие новое, и задокументируйте компромисс ограниченного устаревания.
- Добавьте dehydrated query cache (React Query/SWR) на дашборд, чтобы первый клиентский рендер использовал снимок сервера, и покажите hydration mismatch из-за данных, появляющийся, если перезапросить до hydration.
- Переведите дашборд с полной hydration на острова (или опустите больше 'use client') и измерьте дельту INP и размера бандла на профиле слабого мобильного CPU.
Это цикл, который вы запускаете, проектируя любое реальное приложение: выбрать стратегию на маршрут по свежести × интерактивности × задержке данных (SSG → ISR → streaming SSR → SSR), минимизировать поверхность hydration, держа Server Components по умолчанию и опуская ‘use client’ до листьев, защитить детерминизм рендера, чтобы контракт hydration держался, инструментировать TTFB/LCP/INP/частоту mismatch и проверять каждое решение числами до/после под реалистичной нагрузкой. Сделав это один раз на игрушечном приложении из четырёх маршрутов, вы превращаете продакшен-архитектуру в мышечную память.