Servir un sitio estático desde un Worker

Un sitio estático es el caso degenerado de una respuesta HTTP: bytes que no cambian de una petición a otra —HTML, CSS, JavaScript, tipografías, imágenes— y que, por tanto, no necesitan que nadie los compute, solo que alguien los entregue rápido y cerca del usuario. Durante años eso obligaba a levantar un servidor o a contratar un producto aparte. Desde marzo de 2026 basta un Worker: declaras un bloque assets en wrangler.jsonc, lo apuntas a una carpeta, y la red de Cloudflare sirve esos archivos desde cientos de ciudades sin que tu código llegue a arrancar. Esta lección instala el modelo mínimo —un directorio, un manifiesto, dos comandos— sobre el que se construye todo lo demás del nivel.

Un sitio sin servidor

Servir un archivo estático no requiere lógica: requiere un distribuidor de bytes veloz y próximo al usuario, que es exactamente lo que la red de Cloudflare sabe hacer mejor que nada. El bloque assets convierte tu proyecto de Worker en ese distribuidor.

La configuración de un sitio puramente estático cabe en unas pocas líneas y tiene una ausencia notable —no hay campo main, porque no hay código que ejecutar—:

{
  "$schema": "node_modules/wrangler/config-schema.json",
  "name": "mi-sitio",
  "compatibility_date": "2026-03-01",
  "assets": {
    "directory": "./dist"
  }
}

Ese manifiesto declara todo lo necesario: un nombre, una fecha de compatibilidad y una carpeta. El campo directory es la raíz del sitio; suele apuntar a la salida de tu empaquetador —./dist, ./build o ./public—, la carpeta que ya contiene el HTML final listo para servir. A partir de aquí, cada archivo dentro de ese directorio es una URL potencial, y Cloudflare se encarga del resto.

Del árbol de archivos a las rutas

Cuando ejecutas wrangler deploy, wrangler recorre directory, calcula el hash del contenido de cada archivo y sube solo los que Cloudflare aún no tiene. El almacenamiento es direccionado por contenido: dos despliegues que comparten un logo idéntico comparten el mismo objeto, y un redeploy que solo cambió una página sube esa página y nada más. Esa subida incremental es lo que hace que publicar un sitio grande cueste segundos en lugar de minutos.

El árbol de carpetas se traduce en rutas de forma directa, y unas pocas reglas gobiernan los detalles que suelen morder:

Cómo se resuelven las extensiones .html y las barras finales lo decide html_handling. Los otros valores posibles —force-trailing-slash, drop-trailing-slash y none— existen para cuando tu sitio tiene requisitos estrictos sobre la forma canónica de las URLs, algo que importa para el SEO y para no duplicar contenido bajo dos direcciones.

flowchart LR
U[Navegador pide una ruta] --> E[Edge de Cloudflare]
E --> M{Coincide un asset}
M -->|si| S[Sirve los bytes sin invocar codigo]
M -->|no| N[not_found_handling decide la respuesta]
style S fill:#a6e3a1,color:#11111b

De wrangler dev a wrangler deploy

El ciclo de trabajo son dos comandos. wrangler dev levanta el sitio en tu máquina, sirviendo el contenido de directory en una dirección local y recargando cuando cambias un archivo; es una réplica fiel del comportamiento del edge, no una aproximación, porque usa el mismo runtime por debajo.

Cuando el resultado te convence, wrangler deploy sube los assets y publica el sitio en tu subdominio de workers.dev o en el dominio que hayas enganchado:

# Sirve el sitio en local con recarga en caliente
npx wrangler dev

# Publica los assets al edge global
npx wrangler deploy

Hay una consecuencia económica que no conviene pasar por alto y que define el modelo de 2026: las peticiones que se resuelven íntegramente con un asset estático son gratuitas. Cuando el edge encuentra el archivo pedido, lo entrega sin arrancar ningún isolate, y por tanto sin consumir una invocación de Worker. No pagas por servir tu CSS, tus imágenes ni tu HTML; solo pagarías si una petición tuviera que caer en código, algo que un sitio puramente estático nunca hace.