Cloudflare Pages + Workers: La pila estática-pero-dinámica

Existe un mito persistente de que el renderizado del lado del servidor (SSR) es necesario para un buen SEO. No lo es. Googlebot rastrea HTML pre-renderizado más rápido y de manera más confiable que cualquier respuesta SSR, porque no hay esperas de TTFB, no hay riesgo de timeouts, no hay vértigo de hidratación. Un archivo HTML servido desde un PoP de borde a 30ms es la señal de rendimiento más fuerte que puedes enviar a un buscador.

El segundo argumento contra lo estático es la "personalización". En la práctica, los sitios orientados a contenido rara vez personalizan el contenido del documento; personalizan widgets accesorios (un saludo, un carrito, una bandera regional). Esos widgets pueden hidratarse en el lado del cliente después de la pintura inicial, o renderizarse en un Worker, sin tocar el HTML cacheado. El documento canon permanece cacheable.

El tercer argumento es la "experiencia de desarrollador". Aquí el panorama ha cambiado: generadores de sitios estáticos modernos (Astro, Eleventy, Hugo, Next.js en modo de exportación estática) compilan miles de páginas en segundos. La construcción de Pillar de 14,000+ archivos HTML se ejecuta en menos de dos minutos. No hay penalización de DX por elegir estático cuando los datos viven en archivos locales o JSON.

La tentación con cualquier herramienta de cómputo serverless es construir gradualmente una aplicación dentro de ella. Empiezas con una función de redirección, añades validación, añades autenticación, añades una capa de base de datos, y de repente has reinventado Express.js dentro de un isolate de V8. Resiste esto. Un Worker debe ser pegamento: traduce de la solicitud entrante a una llamada de servicio externo, o aplica una transformación trivial (firma una URL, establece una cookie, dirige a Stripe).

Pillar tiene un solo Worker. Su trabajo: recibir una solicitud al endpoint de checkout, mirar qué dominio está comprando el usuario y emitir una redirección HTTP 302 al Stripe Payment Link correcto. Eso es. Sin sesión, sin base de datos, sin secretos en el código del Worker (los IDs de Stripe Payment Link son referencias públicas, no credenciales). El Worker es esencialmente una tabla de búsqueda con conciencia HTTP.

Esta restricción —mantén el Worker como pegamento— es lo que mantiene la arquitectura comprensible. Cuando un nuevo desarrollador se incorpora, no hay un grafo de servicios que aprender. Hay HTML estático, y hay un Worker pequeño. Cualquier lógica de pago real vive en Stripe, donde pertenece. Cualquier captura de formulario vive en Formspree. Cualquier envío de email vive en un proveedor SMTP. El sustrato de Cloudflare no es donde reside el estado; es donde se enrutan las solicitudes.

Vercel se construyó alrededor de Next.js y su modelo de precios refleja eso: vas a pagar por funciones serverless, por ancho de banda y por minutos de build una vez que el tráfico crece. Para sitios mayormente estáticos, estás pagando por capacidades de SSR que no usas. El plan Pro comienza alrededor de $20/mes por miembro del equipo y los excedentes de ancho de banda pueden volverse significativos con el aumento del tráfico orgánico.

Netlify ofrece una historia estática más limpia pero cobra agresivamente por minutos de build, lo cual duele cuando tienes una capa estática grande que se reconstruye a menudo. La integración de funciones es funcional pero menos elegante que el modelo de isolates de Workers, y su huella de borde es más pequeña que la de Cloudflare.

AWS S3 + CloudFront es el clásico "ensambla tú mismo". Es poderoso, configurable y barato a escala, pero requiere que conozcas IAM, políticas de bucket, comportamientos de caché, certificados ACM, configuración de Route 53 y Lambda@Edge si necesitas lógica dinámica. El costo total de propiedad —contando el tiempo del operador— rara vez supera a Cloudflare Pages para un equipo pequeño. Cloudflare ganó en la categoría de "no tienes que pensar en ello".

El flujo en Cloudflare Pages es deliberadamente aburrido. Conectas un repositorio de Git, configuras un comando de build (npm run build o equivalente) y un directorio de salida (./dist, ./build, ./public). En cada push, Pages ejecuta el build, captura el output y lo despliega a la red. Cada build obtiene una URL única de vista previa, lo que significa que los rollbacks son una operación de un clic: apunta el alias de producción a un despliegue anterior y estás atrás en segundos.

Para los Workers, el flujo es similar vía la CLI de Wrangler. wrangler deploy empuja una nueva versión; wrangler rollback revierte. Las versiones se mantienen, por lo que puedes hacer despliegues progresivos (10% de tráfico al nuevo Worker, 90% al antiguo) sin infraestructura adicional. Esto es la liberación canary integrada.

El observability está incluido pero es ligero: registros en tiempo real vía wrangler tail, métricas en el dashboard, y la capacidad de exportar logs a un sink externo si necesitas análisis profundo. Para un sitio cuya superficie dinámica son unos pocos Workers, esto es suficiente. Si necesitas APM completo, estás probablemente operando algo más grande que un sándwich estático-pero-dinámico, y deberías reconsiderar la arquitectura.