Next.js 16 Cache Components: Τι Άλλαξα σε Πραγματικά Sites

Τι Είναι τα Cache Components

Τα Next.js 16 Cache Components είναι ένα ρητό, opt-in caching primitive για Server Components και async functions. Στο παλιό μοντέλο του Next.js 13–15, τα fetches cachάρονταν by default και έπρεπε να παλεύεις για να το απενεργοποιήσεις. Τώρα, το αντίθετο: τίποτα δεν cachάρεται αν δεν βάλεις use cache. Το unstable_ prefix έπεσε στο 16.2 — είναι πλέον stable API.

Η αλλαγή νοοτροπίας είναι ουσιαστική. Από «cache by default» φτάνουμε σε «dynamic by default, cache όπου το αποφασίζεις εσύ».

Τι Ενεργοποιείς

Στο next.config.ts, βάζεις το flag:

import type { NextConfig } from 'next'

const config: NextConfig = {
  cacheComponents: true,
  // Turbopack is now default in 16 — no separate flag needed
}

export default config

Χωρίς cacheComponents: true, η οδηγία use cache δεν κάνει απολύτως τίποτα. Ενεργοποίησέ το μία φορά και μετά σήμανε ό,τι θέλεις να cachαριστεί.

Τι Cachάρεις και Πώς

Βάζεις 'use cache' στην αρχή μιας async function ή Server Component. Το συνδυάζεις με cacheLife για TTL και cacheTag για στοχευμένη ακύρωση.

import { cacheLife, cacheTag } from 'next/cache'

async function getServicesList() {
  'use cache'
  cacheLife('hours') // built-in: minutes | hours | days | weeks | max
  cacheTag('services')

  const res = await fetch('https://api.example.com/services')
  return res.json()
}

Για ακύρωση on demand — μετά από ένα CMS webhook, για παράδειγμα — καλείς updateTag μέσα σε Server Action ή Route Handler:

import { updateTag } from 'next/cache'

export async function POST() {
  updateTag('services')
  return new Response('revalidated')
}

Αυτό είναι όλο το pattern. Χωρίς revalidatePath, χωρίς revalidateTag από το next/cache v1 — εξακολουθούν να δουλεύουν για συμβατότητα με το Page Router, αλλά το updateTag είναι το αντίστοιχο των Cache Components.

Static Shell + Streaming

Το Next.js κάνει prerender ένα στατικό HTML shell αμέσως. Τα dynamic Server Components — όσα δεν έχουν use cache — κάνουν stream μέσω Suspense. Αποτέλεσμα: το Lighthouse score σου δεν χαλάει πια από ένα μόνο αργό data fetch κάπου βαθιά στη σελίδα.

Σε ένα marketing site που έφτιαξα εκ νέου με Next.js 16, ο hero, το nav και το footer είναι καθαρό στατικό shell — παραδίδονται μέσα σε χιλιοστά δευτερολέπτου από το edge του Vercel. Το τμήμα τιμολόγησης, που τραβά Postgres query μέσω Prisma, κάνει stream πίσω από ένα <Suspense> boundary. Το TTFB του στατικού περιεχομένου είναι κάτω από 60 ms. Το dynamic κομμάτι φορτώνει μόλις είναι έτοιμο. Οι χρήστες βλέπουν περιεχόμενο αμέσως.

Στο Next.js 15 αυτό ήθελε προσεκτική ακροβασία με no-store. Εδώ είναι η default συμπεριφορά.

Τι Έσπασε κατά τη Μετάβαση

Μερικές παγίδες στο 15 → 16.

Το fetch caching εξαφανίστηκε από το fetch layer. Στο Next.js 15, τα fetch calls μέσα σε Server Components είχαν δικό τους cache by default (ή με next: { revalidate }). Στο 16, αυτό το layer δεν υπάρχει. Αν βασιζόσουν σε αυτό και κάνεις migrate χωρίς να βάλεις use cache στις data functions, τα calls τρέχουν σε κάθε request. Το site δουλεύει, αλλά πιο αργά. Εγώ το κατάλαβα βλέποντας τα Neon query counts να εκτινάσσονται μετά από ένα deploy.

Τα unstable_cache wrappers θέλουν αντικατάσταση. Κάθε unstable_cache από το Next.js 15 γίνεται async function με 'use cache'. Το παλιό API δουλεύει ακόμα κατά τη μεταβατική περίοδο, αλλά είναι deprecated.

Nested use cache scope. Αν ένα parent component έχει 'use cache' και ένα child δεν έχει, το child renderάρεται τη στιγμή του cache, όχι του request. Μία φορά με έπιασε με ένα timestamp που είχα αφήσει σε child component — ήταν παγωμένο από τη στιγμή build/cache. Σήμαινε ρητά τα dynamic leaves· αν χρειάζονται request-time data, τύλιξέ τα σε Suspense.

Turbopack ως Default

Το Turbopack είναι πλέον stable και default dev server στο Next.js 16. Τα cold starts στα marketing sites που μετέφερα μειώθηκαν αισθητά. Δεν χρειάζεται καμία ρύθμιση — δουλεύει κατευθείαν, εκτός αν περάσεις --no-turbopack για να το παρακάμψεις.

Πότε το Opt-In Caching Γυρίζει Μπούμερανγκ

Είλικρινής εκτίμηση: το opt-in caching σημαίνει ότι μπορείς να βγάλεις κάτι αργό στην παραγωγή. Αν κάποιος developer ξεχάσει use cache σε μια βαριά data function, εκείνη η function τρέχει σε κάθε request. Δεν υπάρχει αυτόματο fallback.

Τι κάνω εγώ: βάζω 'use cache' ως αυτόματη συνήθεια σε όλες τις data-fetching functions, ελέγχω τα Vercel function logs μετά από κάθε deploy, και τρέχω γρήγορο Lighthouse σε κάθε σελίδα με νέα Server Components πριν το merge.

Η ρύθμιση του cacheLife έχει κι αυτή σημασία. Τα built-in presets (minutes, hours, days) καλύπτουν τα περισσότερα cases, αλλά για περιεχόμενο που αλλάζει μέσω webhook (CMS-driven copy, τιμολόγηση) προτιμώ μικρό TTL συν cacheTag/updateTag αντί να βασίζομαι σε time-based expiry.

FAQ

Τι κάνει το use cache στο Next.js 16; Σημαίνει μια async function, Server Component ή ολόκληρο αρχείο ως cacheable. Η επιστρεφόμενη τιμή αποθηκεύεται και επαναχρησιμοποιείται μέχρι να λήξει το cacheLife ή να ακυρωθεί το αντίστοιχο cacheTag μέσω updateTag. Δουλεύει μόνο όταν το cacheComponents είναι ενεργό στο next.config.

Δουλεύει το use cache σε Client Components; Όχι. Είναι αμιγώς server-side. Τα Client Components συνεχίζουν με standard React state και SWR/React Query patterns.

Μπορώ να χρησιμοποιήσω cacheTag με Prisma queries; Ναι. Τυλίγεις το query σε async function, βάζεις 'use cache', ορίζεις το tag. Καλείς updateTag('your-tag') από Route Handler μόλις αλλάξουν τα δεδομένα.

Χρειάζεται το flag cacheComponents και στην παραγωγή; Ναι. Χωρίς αυτό, το 'use cache' δεν κάνει τίποτα, ανεξάρτητα από το environment.