Браузер и фронтенд-рантайм
Стратегии рендеринга: тест на свободное воспроизведение
Воспроизведение сильнее перечитывания. На каждую подсказку проговорите или запишите полный ответ по памяти, прежде чем открыть модельный — именно усилие припоминания закрепляет механизм, а не узнавание на странице.
Восстановите ключевые механизмы юнита — когда рендерит каждая стратегия, почему hydration стоит ~2×, что ломает контракт hydration и как сочетаются RSC и streaming — не подглядывая в уроки.
- 01SSG, SSR, ISR, streaming SSR — определите каждую по тому, КОГДА производится HTML, и назовите цену каждой.
- 02Почему hydration стоит примерно 2× серверного рендера и почему это хуже простого удвоения?
- 03Что такое hydration mismatch, каковы его частые причины и каково правило детерминизма, которое его предотвращает?
- 04Почему данные API сервера должны быть встроены в HTML и какой механизм используют фреймворки?
- 05RSC и SSR называют ортогональными. Что контролирует каждая ось и как одна страница Next.js App Router использует обе?
- 06Дайте per-route фрейм решения для маркетинговой главной, страниц товаров, дашборда аккаунта и checkout — с причиной для каждого.
Если вы смогли восстановить каждый ответ по памяти, вы держите хребет юнита: КОГДА производится HTML охватывает SSG → ISR → SSR → streaming, обменивая свежесть на цену сервера на критическом пути; hydration — это ~2× ре-рендер, выполняющийся на устройстве пользователя и блокирующий интерактивность (INP); контракт hydration ломается на любом недетерминированном значении, прочитанном во время рендера, и на снимке данных, отличном от серверного; RSC — ортогональная ось, полностью убирающая серверные компоненты из клиентского бандла; и верный ответ всегда per-route, выбранный по свежести, интерактивности и задержке данных.