option

Mettez en cache les réponses dynamiques et statiques sur le CDN de Netlify à partir de Functions, d’Edge Functions et de proxys. À utiliser lorsque vous ajoutez des en-têtes de mise en cache ou de contrôle de cache à la réponse d’une fonction, que vous ajustez la durée de vie (TTL) du cache ou le paramètre « stale-while-revalidate », que vous configurez le cache durable, que vous faites varier une clé de cache en fonction de la requête, de l’en-tête, du cookie, du pays ou de la langue, que vous purgez ou invalidez le cache par site ou par balise de cache, ou que vous utilisez l’API de cache programmatique (caches.open/match/put) ou les aides @netlify/cache (fetchWithCache/cacheHeaders/getCacheStatus), ou encore pour accélérer une API coûteuse

...Développer tout
13
Heure mise à jour 23 août 2026

À propos de « netlify-caching »

Cette compétence constitue un guide pratique pour la mise en cache des réponses dynamiques et statiques sur le CDN de Netlify à partir de Functions, d’Edge Functions et de proxys. Elle résout le problème lié au fait que les réponses dynamiques ne sont pas mises en cache par défaut et que les différents en-têtes « Cache-Control » se comportent de manière subtilement différente : elle indique à l’agent de se référer à l’en-tête « Netlify-CDN-Cache-Control », explique son lien avec « CDN-Cache-Control » et l’en-tête standard « Cache-Control », et répertorie les directives (public/private/no-store, s-maxage, max-age, stale-while-revalidate, durable) ainsi que leurs valeurs par défaut.

Il met l’accent sur les pièges concrets : seule la méthode GET est mise en cache ; Netlify Dev n’émule pas le cache du CDN, la mise en cache doit donc être vérifiée sur une URL déployée via l’en-tête `Cache-Status` ; la chaîne de requête complète devient la clé de cache à moins de la limiter avec `Netlify-Vary` ; les ressources statiques restent à jour jusqu’à un an ; l’authentification de base (basic-auth) sur n’importe quelle page désactive la mise en cache sur l’ensemble du site, et l’option « durable » est réservée aux applications sans serveur. Ce document décrit les variations de la clé de cache avec Netlify-Vary (par requête, en-tête, langue, pays, cookie), le marquage du cache et la désactivation via `Netlify-Cache-Tag` et `Netlify-Cache-ID`, ainsi que la purge à la demande avec `purgeCache` depuis une fonction déployée, par balise, à partir de fonctions compatibles Lambda, ou via l’API de purge HTTP directe.

Les utilisateurs ciblés sont les développeurs web et full-stack qui optimisent les performances du CDN, ajoutent l’ISR ou la revalidation à la demande, ou cherchent à comprendre pourquoi une réponse est ou n’est pas mise en cache. Cette compétence est soucieuse de la sécurité : elle indique explicitement que les jetons d’accès personnels pour les purges hors fonction doivent être lus à partir d’une variable d’environnement et ne jamais être codés en dur, et met en garde contre l’exclusion de contenus sensibles de l’invalidation automatique du cache — elle est donc inoffensive.

FAQ

Pourquoi la réponse de ma fonction dynamique n’est-elle pas mise en cache ?

Les réponses dynamiques ne sont pas mises en cache par défaut et seules les requêtes GET le sont. Vous devez activer cette fonctionnalité en définissant Netlify-CDN-Cache-Control dans la réponse et en exposant les données pouvant être mises en cache sur une route GET.

Pourquoi est-ce que j’observe un « cache miss » lors des tests en local ?

Netlify Dev n’émule pas le cache du CDN ; il faut donc s’attendre à un échec de mise en cache local à chaque fois. Vérifiez la mise en cache sur une URL de prévisualisation de déploiement ou de production en inspectant l’en-tête `Cache-Status`.

Comment empêcher que chaque chaîne de requête ne crée une entrée de cache distincte ?

Sans « Netlify-Vary », la chaîne de requête complète sert de clé de cache ; les paramètres tels que « utm_* » créent donc des entrées distinctes. Utilisez « Netlify-Vary: query=... » pour n'énumérer que les paramètres qui modifient réellement la réponse.

Comment purger ou invalider le cache ?

Utilisez la fonction purgeCache depuis une fonction déployée (l’ID du site est transmis automatiquement), éventuellement par balise ou en ciblant un alias de déploiement ou un domaine. Depuis des scripts CI ou locaux, transmettez un jeton d’accès personnel lu à partir d’une variable d’environnement ainsi que l’ID du site, ou appelez directement l’API HTTP de purge.

Existe-t-il des pièges qui désactivent complètement la mise en cache ?

Oui. L’authentification de base (basic-auth) sur n’importe quelle page désactive la mise en cache pour l’ensemble du site, l’option « durable » n’a aucun effet sur les réponses des fonctions Edge, et les générateurs à la demande (On-demand Builders) hérités ne prennent pas en charge ces en-têtes. La skill déconseille l’utilisation des ODB dans le nouveau code.

Voir sur GitHub

Cache-control header to reach for

Dynamic responses (Functions, Edge Functions, proxies) are NOT cached by default — you must opt in. Set Netlify-CDN-Cache-Control on the response:

import type { Context } from "@netlify/functions";export default async (req: Request, context: Context) => {  return new Response("Hello world", {    headers: {      'Netlify-CDN-Cache-Control': 'public, durable, max-age=60, stale-while-revalidate=120'    }  });};

Header choice (most specific wins; CDN-Cache-Control/Cache-Control always pass downstream):

  • Netlify-CDN-Cache-Control — Netlify CDN only. Reach for this.
  • CDN-Cache-Control — all CDNs that support it.
  • Cache-Control — any CDN or the browser.

Legacy path to avoid: On-demand Builders do not support these headers or Netlify-Vary — they use a TTL pattern and key on URL path only. Don't reach for ODBs in new code.

Footguns (read first)

  • Only GET is cached. POST/PUT/etc. are never cached regardless of headers — expose cacheable data on a GET route (inputs in the URL or query string).
  • netlify dev does not emulate the CDN cache. A local cache miss every time is expected. Verify caching on a deployed URL (Deploy Preview or production) via its Cache-Status header.
  • Without Netlify-Vary: query=..., the full query string is the cache key — every distinct query string (utm_*, fbclid, …) is a separate cache entry. Enumerate only the params that change the response.
  • Static assets are fresh for up to a year — a shorter max-age is ignored. They change only on a new deploy or manual purge.
  • basic-auth on ANY page disables caching for the ENTIRE site.
  • durable is serverless-only — it has no effect on Edge Function responses.
  • Never opt sensitive content out of automatic invalidation — it can stay publicly cached after deploys/firewall changes.

Directives

  • public cache it / private browser-only, not Netlify's shared cache / no-store don't cache.
  • s-maxage=N seconds in Netlify's shared cache (overrides max-age there).
  • max-age=N seconds in any cache.
  • stale-while-revalidate=N serve stale for N seconds after expiry while revalidating in background.
  • durable (serverless only) store in Netlify's durable cache so other edge nodes reuse it instead of re-invoking the function.

Defaults when no header is set — static: Netlify-CDN-Cache-Control: public, s-maxage=31536000, must-revalidate; dynamic: Cache-Control: public, max-age=0, must-revalidate.

Cache key variation — Netlify-Vary

Comma-delimited instructions on the response; pipe-delimited value lists:

Netlify-Vary: query=item_id|page, country=es+de|us, cookie=ab_test|is_logged_in
  • query=a|b subset, or bare query for all params. Keys case-sensitive; param order irrelevant.
  • header=Device-Type|App-Version — custom + most standard headers.
  • language=en|es+pt+ groups; checked against Accept-Language with quality weighting.
  • country=us|es+pt — GeoIP, ISO 3166-1 two-letter codes; + groups.
  • cookie=ab_test|is_logged_in — target specific keys, not the whole Cookie header.

Cannot vary by header on: Accept*, Cache-Control, Connection, Content-Length, Cookie, Host, If-*, Range, Referer, Upgrade, User-Agent. For language/cookie/format use Vary: Accept-Language/Vary: Cookie or the specific Netlify-Vary instruction.

Consistency rule: a URL must return the same Netlify-Vary on every response — the first cached response's instructions win and later ones are ignored. Netlify-Vary + standard Vary are both respected (use Vary for format/encoding, and to pass instructions to an upstream CDN like Cloudflare).

Cache tags & opt-out

Tag responses for taggable purging:

Netlify-Cache-Tag: tag1,tag2,tag3
  • Netlify-Cache-Tag (Netlify CDN) wins over Cache-Tag (passed downstream). Some providers strip Cache-Tag — set both when proxying through them.
  • Constraints: case-insensitive, UTF-8 only, ≤1024 chars/tag, ≤500 tags/response.

Opt a response out of automatic atomic-deploy invalidation with Netlify-Cache-ID (comma-separated; auto-registered as cache tags for purging; separate 500-ID limit):

Netlify-Cache-ID: cms-proxy,product,image

After opting out, purge on-demand after relevant changes (e.g. redirect/proxy or function changes behind a Netlify-Cache-ID).

On-demand invalidation (purge)

Purge from a deployed function with purgeCache (site ID is passed automatically):

import { purgeCache } from "@netlify/functions";export default async () => {  await purgeCache(); // no args = purge everything for the site  return new Response("Purged!", { status: 202 });};

Purge by tag, optionally targeting a deploy/subdomain:

import { purgeCache } from "@netlify/functions";export default async (req: Request) => {  const cacheTag = new URL(req.url).searchParams.get("tag");  if (!cacheTag) return;  await purgeCache({    tags: [cacheTag],    deployAlias: "deploy-preview-11",    domain: "early-access.company.com",  });  return new Response("Purged!", { status: 202 });};

Ambient credentials only work inside a deployed function. From CI, local scripts, or the build, pass token (a personal access token read from an env var — never hardcoded) and siteID.

Lambda-compatible functions use the legacy module.exports.handler = async (event, context) => {…} signature and must pass context.clientContext.custom.purge_api_token:

import { purgeCache } from "@netlify/functions";module.exports.handler = async (event, context) => {  const token = context.clientContext.custom.purge_api_token;  await purgeCache({ tags: ["tag1", "tag2"], token });  return { body: "Purged!", statusCode: 202 };};

Direct API (from outside a function) — POST https://api.netlify.com/api/v1/purge with Authorization: Bearer <personal_access_token> and Content-Type: application/json:

curl -X POST \  -H "Content-Type: application/json" \  -H "Authorization: Bearer <personal_access_token>" \  --data '{"site_slug": "mysitename", "cache_tags": ["news"], "deploy_alias": "deploy-preview-11", "domain": "early-access.company.com"}' \  'https://api.netlify.com/api/v1/purge'
  • Purge by site: site_id or site_slug. By tag: cache_tags + site. Omitting cache_tags purges the whole site; an empty cache_tags list purges NOTHING.
  • Identifier mapping: in the UI (Project configuration > General > Project details), Project ID = site_id, Project name = site_slug. See https://docs.netlify.com/api-and-cli-guides/api-guides/get-started-with-api#get-site.
  • Rate limit: each tag or site can be purged only twice per 5s — exceeding returns 429.

Cache API (caches global)

Programmatic read/write of HTTP responses from Functions/Edge Functions. Use for caching individual components of a route or arbitrary fetches, alongside header-based route caching.

Scope rule: caches.open() anywhere, but match/put/delete only inside the request handler — doing them at module/global scope throws.

import type { Config, Context } from "@netlify/functions";const cache = await caches.open("my-cache"); // ok in global scopeexport default async (req: Request, context: Context) => {  const request = new Request("https://example.com/expensive-api");  const cached = await cache.match(request);  if (cached) return cached;  const fresh = await fetch(request);  if (fresh.ok) {    cache.put(request, fresh.clone()).catch((error) => {      console.error("Failed to add to the cache:", error);    });  }  return fresh;};export const config: Config = { path: "/cache-api-example" };

CacheStorage subset:

  • caches.match(request)Response from any cache, or undefined.
  • caches.open(name)Cache. Distinct names fragment the cache and lower hit ratio — use few, meaningful names.

Cache methods (all require caches.open()):

  • cache.match(request)Response | undefined.
  • cache.put(request, response) → adds a response.
  • cache.add(request) / cache.addAll(requests) → fetch + store.
  • cache.delete(request)true.
  • keys() is not implemented — no way to list contents.

Consistency: reads/writes strongly consistent; deletes eventually consistent (a deleted entry may still return briefly).

Cannot cache: partial responses (206), Vary: *, or non-GET methods. Responses need a cache-control header with max-age/s-maxage ≥ 1s, public (not private/no-cache/no-store), and a 2xx status — otherwise storage errors. For responses you don't control, rewrite headers with fetchWithCache.

Limits per invocation: 100 lookups, 20 insertions/deletions. Exceeding: further lookups return nothing; writes/deletes no-op. Limits are shared across edge functions in a request but separate between serverless and edge functions. Cache data is per-region (not replicated), auto-invalidated on redeploy and on max-age/s-maxage expiry.

@netlify/cache module

Install to get helpers, time constants (MINUTE/HOUR/DAY), and a caches export for local dev:

npm install @netlify/cache

Local-dev workaround: the caches global isn't part of Node.js. Netlify provides it in its Functions/Edge runtimes (live and under netlify dev), but if you run your framework's own dev server the global is undefined and throws — import it instead:

import { caches } from "@netlify/cache";const cache = await caches.open("my-cache");

Requires Netlify CLI 20.0.3+; nothing persists locally (lookups return nothing, writes/deletes don't mutate). No functional change from the global.

cacheHeaders(settings) → header object

import { cacheHeaders, DAY } from "@netlify/cache";const headers = {  "x-custom-header": "some value",  ...cacheHeaders({    ttl: 2 * DAY,          // s-maxage    swr: HOUR,             // stale-while-revalidate    durable: true,    tags: ["product", "sale"],    overrideDeployRevalidation: ["tag"], // opt out of atomic-deploy invalidation    vary: {      cookie: ["ab_test_name", "ab_test_bucket"],      query: ["item_id", "page"], // or true for all      country: ["us", ["es", "pt"]], // nested = OR      language: ["en"],      header: ["Device-Type"],    },  }),};

For only generic (non-Netlify) headers, use the cdn-cache-control npm module instead.

fetchWithCache(resource, options?, cacheSettings?)

Drop-in fetch that returns a cached response or fetches, stores, and returns. cacheSettings override conflicting response headers; with swr, background revalidation is handled automatically.

import { fetchWithCache, DAY } from "@netlify/cache";const response = await fetchWithCache("https://example.com/expensive-api", {  ttl: 2 * DAY,  tags: ["product", "sale"],  vary: { cookie: ["ab_test_name"], query: ["item_id", "page"] },});

getCacheStatus(response | headers | headerString)

Returns { hit, caches: { durable: { hit, stale, stored, ttl }, edge: { hit, stale } } }.

const { hit, edge, durable } = getCacheStatus(response);

needsRevalidation(response) → boolean

Only needed when calling cache.match/cache.put directly (not with fetchWithCache+swr). True when a Cache-API response is stale within its SWR window — return it, then revalidate in context.waitUntil and cache.put the fresh copy:

if (cached) {  if (needsRevalidation(cached)) {    context.waitUntil(      fetch(request).then((fresh) => {        const response = new Response(fresh.body, {          headers: { ...Object.fromEntries(fresh.headers), ...cacheHeaders({ ttl: MINUTE, swr: HOUR }) },        });        return cache.put(request, response);      })    );  }  return cached;}

Durable cache

Add durable (serverless only) so edge nodes lacking a local copy check the shared durable cache before invoking the function — fewer invocations, better cache-miss latency. Eventually consistent, so multiple regions may still invoke the function a few times per version. Co-located with the site's functions region. Works with Netlify-Vary, SWR, and on-demand invalidation. Next.js: Next Runtime 5.5.0+ uses the durable cache automatically.

Debugging with Cache-Status

Netlify sets Cache-Status (RFC 9211) on all responses. Check it on a deployed URL. Look for values starting "Netlify Edge" or "Netlify Durable":

  • "Netlify Edge"; fwd=miss — nothing cached.
  • "Netlify Edge"; hit — served from cache.
  • "Netlify Edge"; hit; fwd=stale — stale served while revalidating (SWR).
  • Durable stored on miss: "Netlify Durable"; fwd=uri-miss; stored=true; ttl=3600.
  • Durable hit: "Netlify Durable"; hit; ttl=1234.

ttl negative = seconds since expiry. Each request may hit a different cache instance — without production traffic or durable, expect several empty caches before a hit; repeat requests to warm one.

Netlify house rules (caching)

These are org conventions, not docs facts — merged into the rendered skill byctx-gen and never generated. Owned by the skills maintainer.

  1. Only GET responses are cached by the CDN. POST/PUT/etc. are nevercached regardless of headers — expose cacheable data on a GET route(put the inputs in the URL or query string).
  2. Without Netlify-Vary: query=..., the full query string is the cache key —every distinct query string (utm_*, fbclid, ...) is a separate cacheentry. Enumerate only the params that actually change the response.
  3. netlify dev does not emulate the CDN cache — a cache miss every timelocally is expected, not a bug. Verify caching behavior on a deployed URL(Deploy Preview or production) via its Cache-Status header.
  4. purgeCache() has ambient credentials only inside a deployed function.From CI, local scripts, or the build, pass token (a personal accesstoken read from an env var, never hardcoded) and siteID.

Tous les fichiers

0 fichiers

Installer netlify-caching

Téléchargez et décompressez les fichiers de compétences dans votre répertoire .claude/skills/.

Télécharger le ZIP

Clonez le dépôt et copiez les fichiers de compétence dans votre projet.

git clone https://github.com/netlify/context-and-tools/blob/main/skills/netlify-caching/SKILL.md # Copy SKILL.md to your .claude/skills/ directory

Copier Copier
Configuration rapide: Copiez le dossier de la compétence dans .claude/skills/ : Claude la détectera automatiquement et l'utilisera.

Compétences similaires

Cloudflare Manager
Heure mise à jour 29 juin 2026
pinecone
Heure mise à jour 29 juin 2026
sentry-architecture-variants
Heure mise à jour 29 juin 2026
azure-setup-guide
Heure mise à jour 29 juin 2026
OR