Caché en el Edge con Cloudflare Workers sin un CDN de pago

Cuando despliegas un Cloudflare Worker, no estás desplegando un servidor de origen detrás de un CDN. El Worker es el CDN. Cada petición llega a una de las 300+ ubicaciones edge de Cloudflare, y la respuesta que devuelves puede cachearse ahí mismo para el próximo visitante de la misma región.

La mayoría de los tutoriales se pierden esto. Tratan a los Workers como un servidor Node.js y añaden una capa de caché después. No hace falta.

Cómo Funciona el Caché en Workers#

Cuando tu Worker devuelve una respuesta con los headers Cache-Control correctos, el edge de Cloudflare cachea esa respuesta automáticamente. Sin configuración extra, sin plan de pago, sin Cache Rules.

javascriptreturn new Response(obj.body, {
  headers: {
    "Content-Type": "image/webp",
    "Cache-Control": "public, s-maxage=31536000, max-age=86400",
  },
});

Dos directivas hacen el trabajo pesado:

• s-maxage=31536000 — el edge (Cloudflare) cachea esto durante 1 año
• max-age=86400 — el navegador lo cachea durante 1 día

Después de que el primer visitante en una región ejecuta el Worker y obtiene la imagen desde R2, cada visitante posterior en esa región recibe la respuesta cacheada. El Worker ni siquiera se ejecuta. R2 no recibe la petición. Costo: prácticamente cero.

Qué Cachear y Por Cuánto Tiempo#

El TTL correcto depende de cuánto cambia el contenido.

Imágenes y estáticos — son content-addressed por naturaleza (un post nuevo tiene un slug nuevo), así que cachea agresivamente. Un año para s-maxage no es excesivo.

javascript"Cache-Control": "public, s-maxage=31536000, max-age=86400"

RSS y sitemap — cambian cuando publicas, lo cual es infrecuente. Una hora para el edge está bien.

javascript"Cache-Control": "public, s-maxage=3600, max-age=300"

Endpoints de API con datos dinámicos — reacciones, contadores de vistas, cualquier cosa que cambie con interacciones de usuario. No cachear.

javascript"Cache-Control": "no-store"

Páginas HTML — no las cacheo en el edge porque el Worker es suficientemente rápido (< 50ms cold start en Cloudflare) y el contenido cambia cuando publico posts nuevos.

Sirviendo Objetos de R2#

Los objetos de R2 almacenan su Content-Type original como metadatos. El método writeHttpMetadata() lo copia a los headers de tu respuesta automáticamente.

javascriptconst obj = await env.POSTS_BUCKET.get(slug);
const headers = new Headers();
obj.writeHttpMetadata(headers);
headers.set("Cache-Control", "public, s-maxage=31536000, max-age=86400");
return new Response(obj.body, { headers });

Esto importa para la ruta de imagen OG — el Content-Type es image/webp, y writeHttpMetadata lo pone en la respuesta sin que tengas que saber en qué formato está el archivo.

El Beneficio Oculto: Sin Egress de Origen#

En la mayoría de los setups de hosting, el ancho de banda CDN → Origen cuesta dinero. En Cloudflare Workers + R2, el egress de R2 a la red de Cloudflare es gratuito. Servir 10,000 imágenes por día cuesta lo mismo que servir 100.

La arquitectura elimina la estructura de costos que normalmente te obliga a pensar cuidadosamente sobre el caché. Aun así deberías pensarlo — los cache hits son más rápidos — pero no recibirás una factura sorpresa si se te olvida.

Un Gotcha: El Caché Varía por Región#

Cloudflare cachea por PoP (punto de presencia). Un visitante en Buenos Aires y uno en Madrid ambos generarán un cache miss en su primera petición, luego obtendrán respuestas cacheadas en visitas posteriores. No hay un único caché global de origen.

Esto significa que la latencia de cold start (Worker ejecutándose + fetch desde R2) se distribuye entre los primeros visitantes por región, no solo en el primer visitante global. Para un sitio personal con poco tráfico, esto es invisible. Para un post viral, el primer visitante en cada ciudad importante paga el costo.

No es un problema. Es simplemente el modelo.