Migrar de Pages a Workers: cuándo tiene sentido y el coste real del cambio

Los equipos adoptan Pages porque el flujo de git push con compilación automática e implementación instantánea es realmente más simple que crear una canalización de CI desde cero. Esa es una ventaja real, no marketing. El problema aparece cuando el proyecto crece y comienzas a alcanzar límites que Pages no puede resolver: activadores cron, múltiples trabajadores con responsabilidades separadas, puesta en escena con diferentes enlaces. En este punto, migrar a Workers parece obvio, pero el costo real rara vez se calcula antes de comenzar.

Los verdaderos desencadenantes de la migración

El desencadenante más común son los desencadenadores cron. Pages no admite cron de forma nativa. Si necesita un trabajo que se ejecute periódicamente (procesar pagos, sincronizar datos externos, generar informes programados), ya tiene un trabajador independiente ejecutándose junto con su proyecto de páginas. A medida que crece el número de trabajadores satélite, el equipo empieza a preguntarse si tendría más sentido consolidar todo en trabajadores.

El segundo desencadenante es la fragmentación de la implementación. Un proyecto de Pages es una unidad de implementación monolítica: interfaz, funciones, todo junto. Cuando desea dividir responsabilidades entre trabajadores especializados (uno para la API pública, uno para el procesamiento interno y otro para los webhooks), Pages no ofrece esa granularidad. La implementación de un cambio en el controlador de webhooks desencadena una reconstrucción de toda la interfaz.

La tercera es la puesta en escena con paridad de producción. Las páginas tienen entornos de producción y vista previa, pero no tienen entornos con nombre con enlaces completamente diferentes. Si desea una base de datos provisional D1 completamente separada de la de producción, con diferentes variables de entorno y tal vez incluso un modelo KV diferente, la solución en Pages es crear un proyecto de Pages separado y administrar la sincronización manualmente. En Trabajadores, esto está en wrangler.toml con los bloques [env.staging] y [env.production].

Lo que pierdes cuando sales de Pages

Antes de migrar, el cálculo correcto es enumerar las ofertas de Pages que necesitarás reemplazar.

El proceso de construcción es el elemento más subestimado. Pages se conecta al repositorio, detecta el marco, ejecuta la compilación y carga los activos. En Workers, usted asume esta responsabilidad: poseer CI/CD (GitHub Actions, GitLab CI, lo que sea), crear script y cargar activos en R2 si aún necesita entregar archivos estáticos.

Las implementaciones preliminares por sucursal son el segundo elemento. Pages genera automáticamente una URL de vista previa para cada rama: push, URL disponible, comentario en relaciones públicas. Replicar esto en Workers requiere trabajo: un script de CI que detecta el nombre de la rama, se implementa con un nombre de trabajador derivado de la rama (minha-api-pr-247) y comenta la URL en el PR a través de la API de GitHub. Funciona, pero es un código de infraestructura que usted escribe y mantiene.

El tercer elemento es la CDN para activos estáticos. Este es el más caro de ignorar.

La cuenta de activos estáticos.

En Pages, los activos estáticos (HTML, CSS, JS, imágenes) se entregan directamente desde la CDN de Cloudflare sin activar el tiempo de ejecución de Workers. Cada solicitud de un activo estático cuesta $0 por solicitud, independientemente del volumen.

En Workers, no tienes esta primitiva de forma nativa. Para servir activos, necesita R2 (almacenamiento de objetos) y lógica en el trabajador que busca el activo correcto, aplica encabezados de caché y devuelve el contenido. Cada solicitud que pasa por el tiempo de ejecución cuenta como una invocación de trabajador.

El plan pagado de los trabajadores incluye 10 millones de solicitudes por mes y cobra $0,30 por millón por encima de eso. Un sitio web con 100 millones de solicitudes mensuales, 90 millones de las cuales son para activos estáticos: en Pages, el costo de la solicitud es $0. En Workers, hay 90 millones de invocaciones por encima del paquete incluido: $27/mes solo para este delta, creciendo linealmente con el tráfico.

Para un sitio web con 500 millones de solicitudes mensuales con un 85% de activos estáticos: la diferencia asciende a más de 120 dólares al mes. El costo del plan profesional de Pages es de $20 al mes. Migrar a Trabajadores, en este escenario, es una decisión que aumenta los costos operativos a cambio de flexibilidad.

El wrangler.toml para servir los activos de R2

Si la migración tiene sentido a pesar del costo, el patrón correcto para servir activos estáticos en Workers utiliza R2 con API de caché:

# wrangler.toml
name = "meu-site"
main = "src/index.ts"
compatibility_date = "2024-09-24"

[[r2_buckets]]
binding = "ASSETS"
bucket_name = "meu-site-assets"

[[routes]]
pattern = "meusite.com/*"
zone_name = "meusite.com"

// src/index.ts
export default {
  async fetch(request: Request, env: Env): Promise<Response> {
    const cache = caches.default;
    const cached = await cache.match(request);
    if (cached) return cached;

    const url = new URL(request.url);
    const key = url.pathname.slice(1) || "index.html";
    const object = await env.ASSETS.get(key);

    if (!object) {
      return new Response("Not Found", { status: 404 });
    }

    const response = new Response(object.body, {
      headers: {
        "Content-Type": object.httpMetadata?.contentType ?? "application/octet-stream",
        "Cache-Control": "public, max-age=31536000, immutable",
      },
    });

    await cache.put(request, response.clone());
    return response;
  },
};

Esto replica el comportamiento de CDN de Pages, pero usted paga por cada pérdida de caché (primera solicitud por archivo por PoP de Cloudflare). La CDN de Pages tiene esta capa de almacenamiento en caché sin costo adicional por solicitud.

Cómo migrar sin tiempo de inactividad

La secuencia menos riesgosa: primero, mantener el proyecto de Pages en ejecución. Crear nuevos trabajadores en paralelo. Configure rutas que envíen tráfico a nuevos trabajadores para rutas específicas (comenzando por las de menor riesgo, como webhooks o rutas de administración). Validar el comportamiento en producción con tráfico real antes de mover las rutas principales. Sólo entonces desactive las funciones de páginas correspondientes.

Para la interfaz, no migre los activos de Pages a R2 hasta que esté seguro de que el costo adicional está dentro del presupuesto del proyecto. En muchos casos, la arquitectura híbrida (páginas para frontend y activos, trabajadores para trabajos asincrónicos y servicios especializados) es más barata e igualmente flexible que una migración completa.

Lo que realmente resuelve la migración

Activadores cron, múltiples trabajadores con enrutamiento granular y preparación con entornos completamente aislados: estos son los problemas reales que justifican la migración. Si está migrando por otro motivo, vale la pena comprobarlo para asegurarse de no cambiar una limitación por un costo mayor.

La flexibilidad de los trabajadores tiene un precio operativo concreto: usted asume el proceso de CI, la implementación preliminar y el costo de dar servicio a los activos estáticos. Para servicios de backend puros sin activos importantes, este costo es bajo. Para aplicaciones con una interfaz pesada y un gran volumen de tráfico estático, puede ser sustancial.