Wat Next.js standaard biedt
- Data cache – In Next.js 13+ komt elke
fetch()-aanroep terecht in een geheugencache per verzoek. Het toevoegen van eenrevalidate-optie vertelt de runtime om de gegevens na een ingesteld interval te verversen, waardoor een 'hot' API-aanroep pas een 'cold' aanroep wordt wanneer dat nodig is. - Full-route cache – Het framework slaat de gerenderde HTML en de gegevens die nodig zijn voor een volledige route permanent op. Terugkerende bezoekers ervaren een directe overgang omdat de server het opnieuw renderen overslaat.
- ISR – Statische pagina's worden op de achtergrond opnieuw gegenereerd terwijl de oude versie de verkeersstroom blijft afhandelen. Hierdoor kun je een grote site statisch houden zonder telkens een volledige rebuild uit te voeren wanneer de inhoud verandert.
- Server Component
cache()– Decache-helper van React memoïseert dure berekeningen of databaseverbindingen voor de duur van een enkel verzoek, waardoor dubbel werk binnen de componentboom van een pagina wordt voorkomen.
Deze caches lossen het "first-hit"-probleem op, maar draaien nog steeds binnen het Node-proces. Om de server en de database te beschermen, moet je de caching naar buiten toe uitbreiden.
Externe lagen die je kunt toevoegen
| Laag | Wat het opslaat | Typische tool | Hoe het helpt |
|---|---|---|---|
| CDN | Statische assets, HTML, API JSON | Cloudflare, Akamai, AWS CloudFront | Verplaatst inhoud naar edge-locaties, waardoor de round-trip naar de gebruiker wordt verkort |
| Reverse proxy | Volledige paginareacties voordat ze Node bereiken | Nginx, Varnish | Serveert gecachte pagina's direct, wat de belasting op de Next.js-instantie vermindert |
| Application-level cache | Resultaten van dure DB-queries of API-aanroepen | Redis, Memcached | Biedt een snelle key-value store die serverherstarts overleeft en gedeeld kan worden tussen meerdere app-instanties |
Elke laag bevindt zich verder van de oorspronkelijke database, waardoor een 'miss' op één niveau doorwerkt naar het volgende, en de database uiteindelijk pas wordt bereikt wanneer dat absoluut noodzakelijk is.
Caches up-to-date houden
Invalidation (het ongeldig maken van de cache) is waar de meeste teams de mist in gaan. Drie praktische patronen werken goed:
- Time-based (TTL) – Ken een vaste vervaldatum toe aan een cache-item. Eenvoudig te configureren, maar kan verouderde gegevens serveren totdat de timer verloopt.
- Event-driven – Koppel dit aan je CMS of een andere gegevensbron die een webhook verzendt wanneer de inhoud verandert. De webhook triggert een purge van het bijbehorende cache-item.
- Tag-based – Koppel een logische tag aan een groep fetches (bijv.
product-list). Wanneer een item in die groep verandert, wist een enkele aanroep naarrevalidateTag('product-list')elk item dat die tag deelt.
Door deze benaderingen te combineren, kun je een balans vinden tussen versheid en de cache-hitrate.
De hiërarchie die voor de meeste teams werkt
- Browser cache – Statische assets (CSS, JS, afbeeldingen) krijgen een lange
max-age, zodat het apparaat van de gebruiker het netwerk nooit meer hoeft te raadplegen. - CDN – Edge-nodes cachen volledige HTML-pagina's en API JSON, waarbij de
Cache-Control-headers die je in Next.js instelt, worden gerespecteerd. - Reverse proxy – Een Nginx- of Varnish-instantie staat voor de Next.js-server en serveert gecachte reacties voor routes die zelden veranderen.
- Next.js interne cache – De data- en route-caches van het framework verzorgen de memoïsatie per verzoek en ISR.
- Application cache – Redis slaat de resultaten van zware databasequeries op, gekoppeld aan queryparameters of tags.
- Database – De ultieme bron van waarheid, die alleen wordt geraadpleegd bij een cache-miss op elk hoger niveau.
Wanneer een verzoek binnenkomt, loopt het deze lijst af totdat een laag het verzoek afhandelt. Het snelste antwoord wint, en de respons wordt weer omhoog in de keten geschreven voor toekomstige hits.
De onderdelen samenvoegen
- Stel
Cache-Control-headers in je API-routes in - Configureer je CDN – Schakel edge-caching in voor HTML- en JSON-endpoints en zorg ervoor dat de CDN
Cache-Controlrespecteert. - Implementeer een reverse proxy – Plaats Nginx voor je Next.js-server.
- Voeg Redis toe – Cache de resultaten van dure databasequeries.
- Gebruik
revalidateTagin je componenten – RoeprevalidateTagaan om de interne Next.js-cache voor een specifieke tag te wissen.
Kernpunt
Een enkele cache binnen Next.js versnelt het eerste verzoek, maar echte schaalbaarheid komt voort uit een gedisciplineerde stack: browser → CDN → reverse proxy → framework → Redis → database. Configureer elke laag, beheer invalidatie met tijd, events en tags, en houd je metrieken in de gaten. De latentie blijft laag terwijl je backend verkeerspieken overleeft.
