Браузер и фронтенд-рантайм
Стратегии рендеринга: тест с множественным выбором
Шесть вопросов, проходящих сквозь весь юнит. Каждый — решение, которое вы принимаете, проектируя реальный маршрут: не определение для заучивания, а компромисс между свежестью, ценой сервера и мёртвым окном до того, как страницу можно кликнуть.
Убедитесь, что вы связываете когда производится HTML (SSG/ISR/SSR/streaming) с тем, сколько из него должно стать интерактивным (hydration, RSC) — синтез, к которому вели отдельные уроки.
Страница товара в e-commerce одинакова для всех пользователей, цена меняется 4–6 раз в день, и она должна ранжироваться в поиске с быстрым LCP. Какая стратегия подходит лучше всего и почему?
Залогиненный дашборд должен быть свежим per-user, но имеет один медленный запрос истории заказов (~400 мс). Обычный SSR заставляет каждого пользователя ждать 400 мс TTFB. Какое решение верное?
Коллега говорит: «мы внедрили RSC, значит SSR нам больше не нужен». Почему это неверно?
Новостная статья — 2000 слов текста, одно поле комментариев, одна кнопка лайка — полностью отрендерена через SSR и полностью гидрирована. INP на p75 плохой. Какое архитектурное исправление даёт наибольший рычаг?
Компонент приветствия читает текущий час во время рендера и печатает «Доброе утро» или «Добрый вечер». В продакшене пользователи видят мигание и скачок CLS 0.14, с предупреждением в консоли, что текст сервера и клиента расходятся. Какова корневая причина и верное исправление?
По всему e-commerce-приложению вы хотите минимизировать цену hydration и держать INP под 200 мс на каждом маршруте. Какое одно правило самое надёжное?
Сквозная линия юнита — решение по двум осям. Ось первая — когда производится HTML — идёт SSG (билд, заморожено, мгновенный хит CDN) → ISR (ограниченное устаревание через stale-while-revalidate) → SSR (свежесть per-request, цена сервера на критическом пути) → streaming SSR (оболочка первой за ~50 мс, медленные Suspense-границы позже). Ось вторая — сколько этого HTML должно стать интерактивным — управляется RSC (Server Components отправляют ноль клиентского кода) и стратегией hydration (полная → выборочная → острова → resumability). Продакшен-сбои сводятся к этому: устаревшие цены хотят ISR, медленные per-user запросы хотят streaming плюс Suspense, плохой INP хочет меньше hydration, а мигание контента и скачок CLS — это hydration mismatch, исправляемый детерминизмом рендера.