La paridad de 2026: por qué Workers reemplaza a Pages

Durante años, Cloudflare ofreció dos caminos que se solapaban de forma incómoda: Pages, pensado para sitios y front-ends, con su hosting estático, sus previsualizaciones por rama y su integración con Git; y Workers, pensado para compute en el edge, con sus bindings, su cron y su acceso completo a la plataforma. Elegir uno te obligaba a renunciar a lo mejor del otro. En marzo de 2026 esa disyuntiva desapareció: Workers alcanzó la paridad total con Pages en assets estáticos, renderizado en servidor y dominios, y con ello absorbió todo lo que hacía especial a Pages sin perder nada de lo que ya lo hacía superior. Esta lección explica qué significa esa paridad y por qué cambia dónde deberías construir.

Dos productos que resolvían mitades

Pages nació para hacer fácil lo que Workers hacía engorroso: publicar un front-end. Traía integración con Git y despliegues automáticos en cada push, una URL de previsualización única por cada rama y cada commit, hosting estático gratuito e ilimitado, y una experiencia pulida para desplegar el resultado de cualquier framework.

A cambio, su acceso a la plataforma era de segunda clase: los bindings llegaron tarde y a medias, no había cron nativo, y el modelo de funciones se sentía como un añadido sobre un producto que en el fondo era un CDN con despliegues bonitos.

Workers era el reverso exacto. Tenía la plataforma entera —todos los bindings, cron con triggers, Durable Objects, colas, RPC entre servicios— pero servir un montón de archivos estáticos era históricamente incómodo, y no traía de serie las previsualizaciones por rama ni la integración con Git que hacían a Pages tan cómodo. El resultado era una elección falsa: sitio estático cómodo pero limitado, o plataforma completa pero incómoda para el front-end.

flowchart TD
subgraph Antes
  P[Pages: assets, previsualizaciones, Git] 
  W[Workers: bindings, cron, RPC, estado]
end
P --> U[Un solo Worker en 2026]
W --> U
U --> R[Assets, SSR, dominios, bindings y cron juntos]
style U fill:#89b4fa,color:#11111b
style R fill:#a6e3a1,color:#11111b

Los tres frentes de la paridad

Lo que ocurrió en 2026 no fue añadir una función suelta, sino cerrar la brecha en los tres frentes exactos que retenían a la gente en Pages. Con ellos cubiertos, ya no queda ninguna capacidad de Pages que Workers no iguale.

El corazón de la paridad es que los assets estáticos son gratuitos, igual que en Pages. Esto era imprescindible: nadie migraría un sitio de mucho tráfico a un modelo que cobrara por cada imagen servida. Al no contar las peticiones de assets como invocaciones, Workers iguala exactamente la economía de Pages para la parte estática, y reserva el coste solo para el cómputo real —el SSR, la API, la lógica— que es justamente lo que aporta valor.

Un solo manifiesto lo gobierna todo

La consecuencia práctica de la paridad es un cambio de forma: lo que antes eran dos productos con dos configuraciones ahora es un único wrangler.jsonc que declara la aplicación entera. Un mismo archivo define el directorio de assets, el punto de entrada del código, los bindings a datos e IA, y los horarios de cron:

{
  "name": "mi-app",
  "main": "src/index.ts",
  "compatibility_date": "2026-03-01",
  "assets": {
    "directory": "./dist",
    "not_found_handling": "single-page-application"
  },
  "d1_databases": [{ "binding": "DB", "database_name": "app", "database_id": "..." }],
  "triggers": { "crons": ["0 3 * * *"] }
}

Ese manifiesto describe algo que antes exigía dos proyectos y pegamento entre ellos: un front-end estático servido gratis, una API con acceso a una base de datos D1, y una tarea programada que corre cada madrugada, todo en una sola unidad. Esa unidad se versiona junto, se despliega junto y comparte el objeto env. La aplicación full-stack dejó de ser un ensamblaje de servicios para convertirse en un artefacto único.

Para los proyectos que ya viven en Pages existe una ruta de migración guiada que traduce su configuración a este formato; el paso mental clave es entender que el _headers, el _redirects y el directorio de salida siguen existiendo, solo que ahora cuelgan del bloque assets de un Worker.