Trabajadores de Cloudflare versus páginas: la diferencia que importa antes de elegir

La mayoría de los tutoriales sobre Cloudflare Workers y Pages hacen una comparación incorrecta. Coloca a los dos como competidores directos, como si hubiera que elegir entre un framework y otro. Los trabajadores y las páginas resuelven diferentes problemas en diferentes capas, y elegir sin comprender esta distinción crea arquitecturas que son costosas o requieren refactorización en seis meses.

Qué es realmente cada uno

Workers es una plataforma informática. Usted escribe código, lo implementa con wrangler deploy y ese código se ejecuta en aislados V8 distribuidos en la red Cloudflare, actualmente en más de 300 puntos de presencia. El modelo de ejecución está basado en eventos: cada solicitud HTTP, mensaje en cola, activador cron o controlador de correo electrónico genera una invocación. El arranque en frío es inferior a 1 ms porque los aislados V8 comparten el mismo proceso, a diferencia de los contenedores que comienzan desde cero.

Pages es una plataforma de alojamiento. El caso central es: tiene un sitio web o SPA, construye git push, Cloudflare ejecuta su compilación (npm run build, Hugo, Astro, lo que sea) y los activos estáticos resultantes se distribuyen en su CDN global. Las solicitudes de estos activos (HTML, JS, CSS, imágenes) se atienden directamente desde la CDN, sin pasar por ningún tiempo de ejecución informático.

Pages también tiene funciones de páginas, que son scripts de trabajadores implementados mediante convención de directorio (/functions). La confusión comienza aquí: las funciones de páginas se ejecutan en el mismo tiempo de ejecución V8 que los trabajadores, tienen los mismos enlaces (D1, KV, R2, objetos duraderos), los mismos límites de CPU y memoria. La diferencia entre Pages Functions y Workers puros no es técnica: es operativa.

La cuenta que lo cambia todo

En el plan pagado por trabajadores ($5/mes), tiene 10 millones de solicitudes incluidas y paga $0,30 por millón por encima de eso. Cada solicitud HTTP procesada por el tiempo de ejecución cuenta.

En Pages, las solicitudes de activos estáticos no cuestan nada por solicitud: son atendidas por la CDN de Cloudflare sin activar el tiempo de ejecución de Workers. Pagas por las compilaciones ($20 al mes para el plan profesional, con hasta 5000 compilaciones al mes y 5 compilaciones simultáneas). Las solicitudes de funciones de páginas consumen el mismo presupuesto que los trabajadores.

Traducido a un caso real: un sitio web con 100 millones de solicitudes mensuales, 90% para activos estáticos (paquetes JS, imágenes, páginas HTML) y 10% para rutas API. En Pages, los 90 millones de solicitudes estáticas cuestan 0 dólares. Los 10 millones de llamadas a funciones son parte de las funciones gratuitas del plan profesional. En la arquitectura equivalente con trabajadores puros que prestan servicios a los mismos activos a través de fetch() en comparación con un depósito R2, pagaría $27 al mes solo por la diferencia ($0,30 × 90 millones de solicitudes por encima de los 10 millones incluidos).

Esta diferencia es estructural y no desaparece a medida que aumenta la escala: empeora.

Donde los trabajadores tienen una ventaja real

Ciertos primitivos existen sólo en Workers. Los activadores cron (la capacidad de ejecutar código en un momento programado) no existen en Pages. Si necesita un trabajo que se ejecute cada hora para sincronizar datos, procesar una cola o limpiar registros caducados, este es Workers. No tiene equivalente en Páginas.

Workers también admite consumidores de colas (procesar mensajes de colas de Cloudflare de forma asincrónica), trabajadores de correo electrónico (recibir y procesar correos electrónicos) y trabajadores para plataformas (envío de scripts implementados por el usuario, útil para SaaS multiinquilino). Estos activadores que no son HTTP solo existen en el modelo Workers.

Los Durable Objects funcionan en ambos, pero la coordinación compleja entre múltiples instancias (por ejemplo, un servidor WebSocket con estado distribuido) tiende a ser más limpia en Workers, donde usted tiene control total sobre la implementación y el enrutamiento.

La superposición real

Las funciones y trabajadores de Pages comparten exactamente el mismo tiempo de ejecución. Los límites son idénticos: 128 MB de memoria (límite estricto), 10 MB de script comprimido en el plan pago, 1000 subsolicitudes por invocación en el plan pago, 30 segundos de CPU por solicitud. Los enlaces disponibles son los mismos: D1, KV, R2, Objetos duraderos, AI, Enlaces de servicio para llamar a otros trabajadores.

Esto significa que se puede crear una API de rango medio completamente en Pages Functions sin sacrificar nada en términos de capacidad de tiempo de ejecución. La pregunta no es "cuál tiene más potencia informática", sino "qué modelo de implementación y facturación tiene más sentido para mi carga de trabajo".

Los criterios de decisión

La heurística funciona así: si su proyecto tiene activos estáticos generados por compilación (cualquier marco de interfaz, generador de sitios estáticos, SPA), Pages es el punto de partida natural. Obtiene una CDN global para activos sin costo por solicitud, implementaciones de vista previa automática por sucursal y un canal de compilación integrado. Las rutas API están en /functions y se ejecutan en el mismo tiempo de ejecución de Workers.

Si el proyecto es de computación primero (sin activos estáticos significativos o con activadores que no sean HTTP como cron, colas y correo electrónico), Workers es la opción directa. El modelo de implementación a través de wrangler.toml es más explícito, versionable en código y se integra mejor con flujos de trabajo de CI/CD personalizados.

La mayoría de los proyectos no viven en un solo extremo. Un SaaS típico tiene una interfaz (Pages, con CDN gratuito), una API (Funciones de Pages, misma base de código, misma implementación) y un conjunto de trabajos en segundo plano (Trabajadores separados, con activadores cron). Estos trabajadores en segundo plano se conectan al proyecto Pages a través de enlaces de servicio: llamadas directas entre trabajadores sin pasar por la Internet pública.

Lo que la documentación no explica

Cloudflare documenta a los trabajadores y las páginas como productos separados con páginas separadas, lo que oscurece un detalle importante: un proyecto de páginas puede llamar a trabajadores externos a través de enlaces de servicios, y los trabajadores externos pueden servir activos de un proyecto de páginas. No son silos. Son piezas que se unen.

El error más común es volver a implementar en Workers lo que Pages hace de forma gratuita (servir activos estáticos) porque alguien leyó primero sobre Workers y pensó que era "más avanzado". Workers no es más avanzado que Pages. Es una herramienta diferente para una capa diferente del problema.