La mayoría de las webs corporativas que nos llegan para mantener tienen la misma forma: un WordPress en un alojamiento compartido, cuarenta peticiones a base de datos para pintar una página que no cambia desde hace dos años, y una factura mensual que nadie ha revisado desde que se contrató.
Casi siempre se puede hacer lo mismo por cero euros. No por magia, sino porque el modelo de coste de las plataformas modernas premia justo lo que un sitio corporativo necesita.
La regla que decide la factura
En Cloudflare Workers, la regla es de una línea:
Las peticiones a ficheros estáticos son gratuitas e ilimitadas. Las invocaciones de código no lo son.
El plan gratuito da 100.000 invocaciones diarias. Parece poco para una web con tráfico, y lo sería si cada visita ejecutase código. La cuestión es que no tiene por qué hacerlo.
Si las páginas se generan durante el build y se publican como ficheros, cada visita se resuelve leyendo un fichero desde el nodo de Cloudflare más cercano. Eso no cuenta. Las 100.000 invocaciones quedan íntegras para lo poco que de verdad necesita un servidor.
Qué queda de dinámico
En una web como esta, exactamente una cosa: el formulario de contacto. Una
ruta, /api/contact, que recibe el envío, lo valida y lo convierte en un correo.
La configuración deja esa frontera explícita:
"assets": {
"directory": "./dist",
"binding": "ASSETS",
"run_worker_first": ["/api/*"]
}Todo lo que no sea /api/* se sirve como fichero sin despertar al Worker. Si
mañana el sitio recibe cien mil visitas en un día, el coste sigue siendo cero;
lo que consume cuota son los formularios enviados, y no van a ser cien mil.
Lo que se gana además del dinero
El modelo estático no sólo es barato, es que es más rápido por construcción. No hay base de datos que consultar ni plantilla que renderizar: el fichero ya existe y está replicado en la red de Cloudflare.
Algunas decisiones concretas de este sitio:
- La hoja de estilos va incrustada en el HTML. Son unos 7 kB; separarla costaría una petición bloqueante más de la que ahorra.
- No hay JavaScript de terceros. El formulario funciona sin JavaScript; unas veinticinco líneas en línea lo mejoran cuando está disponible.
- El navegador prerenderiza la página siguiente con
speculationrules, una etiqueta declarativa que no descarga ninguna librería. - Un único logotipo vectorial lleva dentro su propia regla
prefers-color-scheme, así que la versión de color y la blanca son el mismo fichero y la misma petición.
El resultado: una visita nueva descarga alrededor de 10 kB para ver la portada completa, y las páginas siguientes rondan los 3 kB.
Cuándo esto no aplica
Conviene ser honestos sobre los límites. Este enfoque encaja cuando el contenido cambia por decisión de alguien, no por cada visita: webs corporativas, catálogos, documentación, blogs. No encaja con un panel de usuario, un carrito con stock en tiempo real o cualquier cosa que dependa de quién está mirando.
La pregunta útil no es «¿estático o dinámico?», sino «¿qué parte de esto cambia de verdad en cada petición?». En la mayoría de los sitios que nos encontramos, la respuesta sincera es: casi nada.