Una web Next.js estática en Cloudflare Workers

Esta web está hecha con Next.js y React, pero no hay ningún servidor Node.js en marcha en ninguna parte. Cada página pública se genera como HTML estático en el build y se sirve desde el edge de Cloudflare. Un pequeño Worker se ocupa de las pocas cosas que de verdad necesitan servidor. Este es el porqué y cómo encajan las piezas.

#Primero, estático

Casi todo en una web de portfolio y demos es contenido estable: descripciones de demos, artículos, casos prácticos, páginas de herramientas. Nada de eso cambia de un visitante a otro, así que generarlo en cada petición añadiría retraso y coste sin ningún beneficio.

Con output: "export", Next.js genera cada ruta —incluidas las dinámicas como /demos/[slug], enumeradas con generateStaticParams— como archivos HTML simples. El resultado:

• Primera carga rápida: el HTML llega completo, sin tiempo de renderizado en el servidor.
• JavaScript mínimo: los componentes de servidor no envían código al cliente; solo se activan las piezas interactivas (filtros, calculadoras, el visor de demos).
• Coste casi nulo: los archivos estáticos en Cloudflare se sirven desde la caché.
• Fallos simples: no hay servidor de aplicación que pueda caerse.

#Dónde sigue haciendo falta un servidor

Tres cosas no pueden ser estáticas:

1. La zona de administración debe protegerse antes de enviar ningún contenido.
2. Las estadísticas y los informes de errores necesitan un endpoint que los reciba.
3. Las funciones comerciales deben rechazarse en el servidor, no solo ocultarse.

Un Worker se coloca delante de los archivos estáticos solo para /admin y /api/*. Comprueba una cookie de sesión firmada en las rutas de administración, limita los intentos de acceso, registra el número de visitas en un Durable Object sin cookies ni direcciones IP y responde 403 a cualquier endpoint comercial salvo que haya un flag activado explícitamente en el servidor. Cualquier otra petición va directamente a los archivos estáticos.

#Los borradores nunca llegan a publicarse

El contenido tiene un estado: borrador, vista previa, publicado o archivado. El build solo genera páginas para lo publicado y las vistas previas; las vistas previas llevan noindex y no aparecen en listados ni en el mapa del sitio. Los borradores nunca se convierten en archivos, así que no hay nada que pueda filtrarse.

#Cabeceras de seguridad en un archivo

Los archivos estáticos en Workers admiten un archivo _headers, así que las cabeceras de seguridad se declaran una sola vez: una política de seguridad de contenido estricta que solo permite en marcos el origen del generador de demos, X-Content-Type-Options, una política de referrer prudente y una política de permisos que desactiva los sensores que la web no usa.

#404 correctos

La configuración de archivos estáticos sirve el 404.html generado con un código 404 real para las rutas desconocidas, así que los buscadores no indexan páginas soft-404.

#Compromisos

• Sin personalización por petición. Todo lo dinámico tiene que ejecutarse en el navegador o en el Worker.
• Publicar exige un nuevo build. Los cambios de contenido requieren build y despliegue. Para una web que cambia unas cuantas veces por semana es una ventaja: cada cambio se revisa y se versiona.
• Sin optimización de imágenes incluida. Las capturas se convierten a WebP al crearse y se sirven en tamaños fijos.

Para una web de muestra, los compromisos compensan con creces: el resultado es rápido, barato, seguro de serie y fácil de entender.