Skip to main content

Як Server Components кешують дані?

Server Components у Next.js кешують дані автоматично, здебільшого через розумний fetch. Кеш працює на сервері і керується самим Next.js - тобі не потрібно писати окрему логіку для цього.


Базова ідея кешування

Коли Server Component робить fetch, Next.js:

  1. дивиться, чи є вже результат цього запиту в кеші
  2. якщо є - повертає його
  3. якщо немає - робить запит, зберігає результат і використовує далі

За замовчуванням запити кешуються.


Кешування через fetch

Поведінка за замовчуванням

js
const res = await fetch("https://api.example.com/posts")

За замовчуванням це:

  • кешований запит
  • дані зберігаються
  • повторно використовуються при наступних рендерах
  • особливо ефективно для SSG та ISR

Це відрізняється від звичайного fetch у браузері - тут він керується фреймворком.


Керування кешем

1. Вимкнути кеш повністю

Якщо дані мають бути завжди свіжими:

js
await fetch(url, { cache: "no-store" })

Що це означає:

  • запит не кешується
  • виконується при кожному рендері
  • поведінка схожа на SSR

2. Кеш з оновленням (revalidation)

Можна сказати: «кешуй, але онови раз на N секунд»

js
await fetch(url, { next: { revalidate: 60 } })

Поведінка:

  • дані беруться з кешу
  • раз на 60 секунд Next.js оновлює їх у фоні
  • користувачі не чекають оновлення

Це і є ISR, але на рівні конкретного запиту.


3. Кеш спільний для різних компонентів

Якщо:

  • кілька Server Components роблять однаковий fetch
  • з однаковими параметрами

Next.js:

  • виконає запит один раз
  • перевикористає результат

Це знижує навантаження на API і прискорює рендер.


Кеш і тип рендеру сторінки

Кешування тісно пов'язане з тим, як рендериться сторінка:

  • SSG -> дані кешуються назавжди (або до revalidate)
  • ISR -> кеш + періодичне оновлення
  • SSR (no-store) -> кешу немає
  • Client fetching -> серверний кеш не бере участі

Що саме кешується

Кешується:

  • результат fetch
  • прив'язка до URL і опцій
  • дані, а не HTML

Не кешується:

  • useEffect
  • клієнтські запити
  • запити з no-store

Чому це зручно

  • не потрібно вручну писати Redis / memory cache
  • менше запитів до API
  • швидкі повторні рендери
  • поведінка передбачувана й декларативна

Ти просто описуєш, наскільки свіжими мають бути дані, а Next.js робить решту.


Коротке резюме

  • Server Components кешують дані через серверний fetch
  • за замовчуванням fetch кешується
  • cache: "no-store" - без кешу, завжди свіжі дані
  • revalidate - кеш з автооновленням
  • однакові запити перевикористовуються
  • кеш працює на рівні даних, а не UI

Next.js бере на себе більшу частину логіки кешування - лишається лише обрати потрібну стратегію.

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

Для співбесіди
Premium

Коротка відповідь допоможе вам впевнено відповідати на цю тему під час співбесіди.