opción

Almacena en caché respuestas dinámicas y estáticas en la CDN de Netlify desde Functions, Edge Functions y proxies. Úsala cuando añadas encabezados de almacenamiento en caché o de control de caché a la respuesta de una función, ajustes el TTL de la caché o el «stale-while-revalidate», configures la caché duradera, varíes una clave de caché según la consulta, el encabezado, la cookie, el país o el idioma, purgues o invalides la caché por sitio o etiqueta de caché, utilices la API de caché programática (caches.open/match/put) o los ayudantes de @netlify/cache (fetchWithCache/cacheHeaders/getCacheStatus), o para acelerar una llamada a la API que requiera muchos recursos.

...Expandir todo
13
Tiempo actualizado 23 de agosto de 2026

Acerca de «netlify-caching»

Esta guía práctica sirve de referencia para el almacenamiento en caché de respuestas dinámicas y estáticas en la CDN de Netlify desde Functions, Edge Functions y proxies. Resuelve el problema de que las respuestas dinámicas no se almacenan en caché de forma predeterminada y de que los distintos encabezados de control de caché se comportan de forma ligeramente diferente: indica al agente que consulte «Netlify-CDN-Cache-Control», explica cómo se relaciona con «CDN-Cache-Control» y con «Cache-Control» estándar, y enumera las directivas (public/private/no-store, s-maxage, max-age, stale-while-revalidate, durable) y sus valores por defecto.

Se hace hincapié en los errores comunes en la práctica: solo se almacena en caché el método GET; Netlify Dev no emula la caché de la CDN, por lo que el almacenamiento en caché debe verificarse en una URL desplegada mediante el encabezado «Cache-Status»; la cadena de consulta completa se convierte en la clave de caché a menos que se delimite con «Netlify-Vary»; los recursos estáticos permanecen actualizados hasta un año; la autenticación básica (basic-auth) en cualquier página desactiva el almacenamiento en caché en todo el sitio, y «durable» solo está disponible en entornos sin servidor. Se documenta la variación de la clave de caché con Netlify-Vary (por consulta, encabezado, idioma, país o cookie), el etiquetado de la caché y la exclusión mediante «Netlify-Cache-Tag» y «Netlify-Cache-ID», así como la purga bajo demanda con «purgeCache» desde una función desplegada, por etiqueta, desde funciones compatibles con Lambda o a través de la API de purga HTTP directa.

Los usuarios a los que va dirigida son desarrolladores web y full-stack que optimizan el rendimiento de la CDN, añaden ISR o revalidación bajo demanda, o depuran por qué una respuesta se almacena o no en caché. La skill tiene en cuenta la seguridad: indica explícitamente que los tokens de acceso personales para las purgas fuera de la función deben leerse desde una variable de entorno y nunca deben codificarse de forma fija, y advierte contra la exclusión de contenido sensible de la invalidación automática de la caché, por lo que es inofensiva.

Preguntas frecuentes

¿Por qué no se almacena en caché la respuesta de mi función dinámica?

Las respuestas dinámicas no se almacenan en caché de forma predeterminada y solo se almacenan en caché las solicitudes GET. Debes habilitarlo configurando Netlify-CDN-Cache-Control en la respuesta y exponer los datos almacenables en caché en una ruta GET.

¿Por qué veo una falta de caché al realizar pruebas localmente?

Netlify Dev no emula la caché de la CDN, por lo que es normal que se produzca una falta de caché cada vez a nivel local. Comprueba el almacenamiento en caché en una vista previa de implementación o en una URL de producción inspeccionando el encabezado «Cache-Status».

¿Cómo evito que cada cadena de consulta cree una entrada de caché independiente?

Sin Netlify-Vary, la cadena de consulta completa es la clave de caché, por lo que parámetros como utm_* crean entradas distintas. Utiliza Netlify-Vary: query=... para enumerar solo los parámetros que realmente modifican la respuesta.

¿Cómo puedo purgar o invalidar la caché?

Utiliza purgeCache desde una función desplegada (el ID del sitio se pasa automáticamente), opcionalmente por etiqueta o dirigiéndote a un alias o dominio de despliegue. Desde scripts de CI o locales, pasa un token de acceso personal leído de una variable de entorno junto con el ID del sitio, o llama a la API de purga HTTP directa.

¿Hay algún detalle que desactive el almacenamiento en caché por completo?

Sí. La autenticación básica (basic-auth) en cualquier página desactiva el almacenamiento en caché para todo el sitio, la opción «durable» no tiene efecto en las respuestas de Edge Function y los generadores bajo demanda (ODB) heredados no admiten estos encabezados. La skill desaconseja el uso de ODB en el código nuevo.

Ver en 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.

Todos los archivos

0 archivos

Instalar netlify-caching

Descarga y descomprime los archivos de habilidades en tu directorio .claude/skills/.

Descargar ZIP

Clona el repositorio y copia los archivos de la habilidad a tu proyecto.

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

Copiar Copiar
Configuración rápida: Copia la carpeta de la habilidad en .claude/skills/. Claude la detectará automáticamente y la utilizará.

Habilidades relacionadas

Cloudflare Manager
Tiempo actualizado 29 de junio de 2026
pinecone
Tiempo actualizado 29 de junio de 2026
azure-setup-guide
Tiempo actualizado 29 de junio de 2026
sentry-architecture-variants
Tiempo actualizado 29 de junio de 2026
OR