La documentación de la plataforma tiende a describir cada producto de forma aislada, desde el mejor ángulo posible. Esto crea una lectura en la que Workers parece más poderoso que Pages y Pages parece más simple que Workers. Ninguna lectura es correcta. Tienen capacidades genuinamente únicas en cada dirección y una amplia zona de superposición donde la diferencia está sólo en el modelo de implementación.
Lo que solo tienen los Trabajadores
Los activadores cron son la primitiva más relevante que no existe en Pages. En wrangler.toml:
[triggers] crons = ["0 3 * * *", "*/15 * * * *"]
Esto registra dos cron: uno a las 3 a. m. todos los días y otro cada 15 minutos. El controlador correspondiente es el método scheduled del objeto exportado por el Trabajador. Pages no tiene esta primitiva. No es una limitación del tiempo de ejecución, es una decisión del producto. Si necesita ejecución periódica, es un Trabajador autónomo.
Los consumidores de cola operan de manera similar. Cloudflare Queues le permite poner en cola mensajes y procesarlos de forma asincrónica. El consumidor, el trabajador que lee de la cola, está configurado en wrangler.toml con [[queues.consumers]]. Las funciones de páginas no pueden ser consumidores de cola; solo puede publicar mensajes en colas mediante enlace.
Los trabajadores de correo electrónico reciben correos electrónicos directamente. Configura una ruta de correo electrónico en Cloudflare para que apunte a un trabajador, y el trabajador recibe el correo electrónico como un objeto con un remitente, un destinatario, encabezados y un cuerpo. Esto le permite procesar rebotes, analizar recibos de facturas o enrutar correos electrónicos a diferentes colas, todo sin su propio servidor de correo electrónico. Pages no admite este activador.
Workers for Platforms es el mecanismo multiinquilino donde los usuarios de SaaS pueden implementar sus propios trabajadores dentro de la cuenta del operador. El operador utiliza un trabajador de despacho que recibe solicitudes y las reenvía al script del inquilino correcto. Es una infraestructura primitiva para plataformas que necesitan ejecutar código de usuario arbitrario con aislamiento garantizado. Exclusivo para Trabajadores.
Los sockets TCP (en versión beta) permiten conexiones TCP directas desde un trabajador, lo que resulta útil para conectarse a bases de datos que no tienen una API HTTP, como PostgreSQL o Redis sin Upstash. Aún en evolución, pero sin equivalente en Pages.
Las alarmas de objetos duraderos merecen una mención aparte de los objetos duraderos en general. Los DO funcionan en ambos, pero las alarmas (temporizadores que activan un DO específico en un momento definido) son una primitiva de programación que complementa los activadores cron para casos con estado por entidad (programar un recordatorio por usuario, por ejemplo). Disponible en ambos tiempos de ejecución, pero la orquestación normalmente comienza desde un trabajador con un cron o activador de cola.
Lo que solo tiene Pages
Alojar activos estáticos sin costo por solicitud es la capacidad más subestimada de Pages y la más costosa de replicar fuera de Pages. Cuando implementas un proyecto de Pages, los archivos estáticos (HTML, CSS, JavaScript, imágenes, fuentes) se distribuyen a través de la CDN global de Cloudflare. Las solicitudes de estos activos no pasan por el tiempo de ejecución de Workers: se atienden directamente desde el borde de la CDN, sin activar ninguna lógica informática, sin contar como una invocación, sin costo por solicitud más allá del plan Pages.
El plan gratuito de Pages incluye solicitudes CDN ilimitadas. El plan pago cuesta $20 al mes y agrega 5000 compilaciones al mes y hasta 5 compilaciones simultáneas. Para un sitio con decenas de millones de páginas vistas mensuales, esta falta de costo por solicitud estática es una ventaja de facturación significativa sobre cualquier arquitectura basada en Workers puros.
La vista previa de implementaciones automáticas por sucursal es la segunda diferencia. Cada envío a una rama no principal genera una URL única en el formato hash-branch.seuprojeto.pages.dev, con activos y funciones ejecutándose juntos. Sin configuración adicional ni scripts de CI que escribir. Workers no replica esto de forma nativa; debe configurar el flujo de "implementación de sucursal" manualmente en su CI.
El proceso de construcción integrado también es único. Pages detecta el marco (Next.js, Astro, SvelteKit, Nuxt, Hugo, Gatsby), configura los valores predeterminados de compilación y ejecuta el proceso de compilación en un entorno aislado con cada inserción. Para los trabajadores, la compilación es responsabilidad de su CI, que es más flexible, pero significa más configuración que mantener.
Las convenciones _redirects y _headers le permiten configurar redirecciones y encabezados HTTP para activos estáticos a través de archivos de texto sin formato en la raíz del proyecto, sin código. Útil para migraciones de URL, HSTS, política de seguridad de contenido y encabezados de caché. Los trabajadores pueden implementar lo mismo con código, pero es más detallado.
¿Qué tienen los dos en común?
El tiempo de ejecución del V8 es idéntico. Los límites son los mismos: 128 MB de memoria (dura), 10 MB de script comprimido en el plan pago, 30 segundos de CPU por solicitud, 1000 subsolicitudes por invocación. Cualquier código que se ejecute en Workers se ejecuta en Pages Functions sin cambios.
Los enlaces de datos se comparten: D1 (SQLite en el borde), KV (valor-clave distribuido), R2 (almacenamiento de objetos), Objetos duraderos (estado de coordinación consistente), AI (inferencia de modelo en el borde). Puede hacer que ambas funciones de páginas y un trabajador autónomo accedan a una base de datos D1 configurada en el mismo wrangler.toml con el enlace apuntando al mismo ID de base de datos.
Los enlaces de servicios funcionan en ambos sentidos: una función de páginas puede llamar a un trabajador independiente directamente a través de un enlace interno, sin latencia de la red pública. Un Trabajador puede llamar a otro Trabajador. La llamada es un fetch() normal contra el enlace, pero se enruta internamente en la red de Cloudflare.
La arquitectura que utiliza cada uno en el lugar correcto
El patrón que surge de los proyectos que utilizan trabajadores y páginas correctamente tiene tres capas. El primero es el proyecto Pages: sirve al SPA o sitio web generado por compilación, con activos estáticos en la CDN sin costo por solicitud. Las rutas API están en /functions/api/: Funciones de páginas ubicadas junto con la interfaz, con vista previa de rama incluida, accediendo a D1 y KV para los datos de la aplicación.
La segunda capa son los trabajadores para trabajos asincrónicos: scripts independientes con activadores cron para el procesamiento programado, consumidores de cola para trabajos asincrónicos desacoplados de la ruta crítica HTTP, trabajadores de correo electrónico para el procesamiento de correo electrónico. Estos trabajadores acceden a los mismos enlaces de datos que el proyecto Pages: la misma base de datos D1, el mismo espacio de nombres KV.
La tercera capa es la comunicación entre ellos a través de enlaces de servicio. Una función de páginas que necesita un procesamiento intensivo llama al trabajador especializado directamente, sin HTTP externo. El trabajador cron que necesita activar una notificación puede llamar a la función de páginas de envío a través del enlace de servicio.
Esta arquitectura no es teórica. Esto es lo que sucede cuando usas cada primitiva que resuelve el problema con un costo operativo más bajo: CDN gratuito de Pages para activos, mismo tiempo de ejecución para la API coubicada, trabajadores independientes para los activadores que Pages no admite.
El mapa de decisiones
La pregunta que organiza la decisión es: ¿qué desencadena este código? Si se trata de una solicitud HTTP y el código convive con una interfaz, Pages Functions. Si es una solicitud HTTP pero el proyecto no tiene una interfaz (servicio API puro), trabajadores con configuración en wrangler.toml. Si se trata de algo que no sea HTTP (hora programada, mensaje en cola, correo electrónico entrante), los trabajadores no tienen otra alternativa.
Ambos lados de la mesa tienen capacidades que el otro no puede replicar sin costos o complejidad adicionales. Una decisión que ignora esto (usar solo Trabajadores porque cree que es más "serio", o solo Páginas porque cree que es más simple) alcanzará un límite que requerirá una refactorización antes de lo necesario.
Lea también
- Cloudflare Workers vs Pages: la diferencia que importa antes de elegir
- Migrar de Pages a Workers: cuándo tiene sentido y el coste real del cambio
- Trabajadores y Páginas: despliegue, enrutamiento y lo que esconde cada modelo
- Funciones de páginas: cuándo usar en lugar de trabajadores puros
- KV para limitación de velocidad, indicadores de funciones y configuración distribuida: dónde funciona y dónde falla
- Cloudflare KV: ¿Qué significa distribuido globalmente cuando necesitas escribir?