Как спроектировать кэширование и стратегии рендеринга страниц в Next.js?
- Чем SSG отличается от ISR?
Стратегии: статическая генерация при сборке — для неизменного контента; ISR (revalidate по времени) — статика, которая пересобирается в фоне; ревалидация по требованию (revalidateTag, revalidatePath после изменения данных) — свежесть без постоянного SSR; динамический рендер на каждый запрос — для персональных страниц (cookies, заголовки). Выбирают по странице: насколько данные свежие, персональные, как часто читаются. Кэш данных помечают тегами и сбрасывают точечно; Partial Prerendering сочетает статичный каркас с динамическими «дырками».
- Персональные данные в общем кэше — утечка между пользователями
- Поведение кэша меняется между версиями Next.js — фиксировать и проверять
- CDN перед приложением кэширует статические ответы
А ещё Матрица: страница × свежесть × персональность → стратегия
Подробно
Пример: каталог — ISR 10 минут + revalidateTag("product") при изменении товара; карточка товара — статично с тегом; корзина — динамически; блог — SSG.
Что хотят услышать
- SSG, ISR, ревалидация по требованию, динамика.
- Выбор по свежести и персональности.
- Теги и опасность персональных данных в кэше.
Проверьте себя
Один верный вариант. Подумайте, потом откройте ответ.
Показать варианты и ответ
- ✗Все страницы лучше рендерить динамически на каждый запрос
- ✓По странице: SSG для неизменного, ISR и теги для обновляемого, динамика для личного
- ✗Персональную корзину пользователя можно кэшировать статически сразу для всех посетителей
- ✗ISR пересобирает страницу при каждом запросе синхронно
Связанные вопросы
Разбор собеседования с sotto
После собеседования sotto разбирает разговор: оценка, каждый вопрос — хорошо, частично или слабо, чего не хватило в ответе и над чем поработать к следующему разу. Первые 30 минут бесплатно.