Як працюють кешування та ревалідація в Next.js

Коротка відповідь

Спочатку визначте свіжість. Публічний контент може допускати коротку застарілість; автор збереження — потребувати read-your-writes. Персональні дані потребують scope користувача й tenant. Кешування є рішенням правильності: швидка відповідь із чужими даними залишається помилкою.

Приклад fetch для Next.js 16 без Cache Components, як у репозиторії. Документація також описує модель use cache, cacheTag і cacheLife. Не змішуйте приклади різних конфігурацій і не вважайте defaults однаковими. Перевірте версію й next.config.

Практичні кроки реалізації

1. Назвіть повторно використані дані

Відрізняйте дедуплікацію рендерингу, серверні дані, результат маршруту, браузерну навігацію й HTTP-кеш. Прибраний повтор у рендерингу не означає міжзапитної свіжості. Інвалідація сервера не обов’язково змінює вже відкриту сторінку. Спочатку знайдіть шар старих даних.

2. Визначте ключі й теги за власністю

Тег об’єднує інвалідацію, не є авторизацією чи ключем. Для залежності від локалі, tenant чи видимості включайте параметри в ключ або уникайте спільного кешу. Використовуйте стабільні ресурсні теги й визначте, хто може запускати подію.

3. Свідомо виберіть інвалідацію

У Next.js 16 revalidateTag(tag, "max") позначає stale і допускає старий результат при оновленні наступного відвідування. updateTag забезпечує read-your-writes лише в Server Actions. revalidatePath стосується шляху, не всіх споживачів спільних даних. Узгодьте API з обіцянкою й контекстом.

4. Простежте виправлення наскрізно

Перевірте запис, автентичну подію, кеш, наступний запит, список і відкритий браузер. Повтори webhook безпечні; відрізняйте збережений запис від невдалого refresh. Старий UI не є приводом дублювати write. Перевіряйте production, не лише dev чи hard refresh.

Приклад реалізації

Публічний reader явно кешується й має тег. Функцію повідомлення викликають після перевіреної публікації чи дозволеної мутації в серверному контексті. Stale-while-revalidate підходить каталогу з допустимою затримкою, не підтвердженню приватного write. URL умовний.

import "server-only";
import { revalidateTag } from "next/cache";

export async function readPublicCatalogue() {
  const response = await fetch("https://api.example.com/catalogue", {
    cache: "force-cache",
    next: { tags: ["public-catalogue"], revalidate: 3600 },
  });
  if (!response.ok) throw new Error("Catalogue unavailable");
  const value: unknown = await response.json();
  return value; // Validate the real schema before rendering.
}

export function notifyPublicCatalogueChanged() {
  revalidateTag("public-catalogue", "max");
}

Компроміси та альтернативи

Часова перевалідація обмежує застарілість без події кожного редагування; події прискорюють виправлення, але потребують авторизації й повторів. Для чутливих персональних даних відсутність спільного кешу може бути яснішою. Cache Components — міграція конфігурації, не заміна назви функції.

Поширені помилки

Не копіюйте deprecated одноаргументний revalidateTag для миттєвого очищення, не викликайте updateTag із webhook Route Handler. Router refresh не доводить очищення всіх серверних записів. Не кешуйте персональне під публічним ключем і не називайте тег контролем доступу.

Перевірка перед випуском

• ☐ Модель відповідає next.config і версії.
• ☐ Читання мають вимоги до свіжості й видимості.
• ☐ Ключі містять усі параметри результату.
• ☐ Споживачів тегів і шляхів описано.
• ☐ Події авторизовані й допускають повтори.
• ☐ Запис і відкритий UI перевіряються окремо.

Поширені запитання

Чи інвалідація шляху оновлює все?

Ні. Scope шляху й даних різний. Знайдіть споживачів і належний тег. Не інвалідуйте все до розуміння шару й споживачів.

Який API потрібен webhook CMS?

Авторизований Route Handler може використовувати revalidateTag із профілем чи revalidatePath. updateTag доступний лише Server Actions. Поведінку stale чи негайного завершення визначає вимога публікації.

Наступний крок

Складіть карту ключів, тегів, маршрутів і браузерної поведінки ресурсу. Простежте виправлення. Відокремте публічне delayed-refresh від приватного read-your-writes й оновлюйте карту зі зміною авторизації чи локалі.

Первинні джерела

• Next.js: кеш без Cache Components
• Next.js: revalidateTag
• Next.js: updateTag
• Next.js: revalidatePath

Пов’язані матеріали та приклади

• React, Next.js і TypeScript
• Зручна для підтримки структура проєкту Next.js App Router
• Серверні та клієнтські компоненти React: порівняння
• Завантаження даних у Next.js App Router
• Публічний каталог проєктів