Cloudflare Workers o Vercel: velocidad y coste del SSR

Para una aplicación Next.js que necesita compatibilidad amplia con Node.js y recursos configurables, Vercel suele ofrecer la integración más directa. Cloudflare Workers puede resultar más económico para respuestas breves y compatibles con su runtime, sobre todo cuando se repiten a gran escala. En las pruebas publicadas por Vercel, Fluid compute rindió entre 1,2 y 5 veces más rápido en determinadas cargas intensivas de renderizado, con funciones de 2 vCPU y 4 GB frente a Workers de CPU compartida y 128 MB por isolate. Esa ventaja describe las configuraciones ensayadas, no una diferencia universal entre plataformas.

Una respuesta SSR más rápida puede justificar un mayor gasto en una ruta importante, pero la factura cambia con el número de solicitudes, el tiempo de CPU y la memoria que permanece asignada mientras la función trabaja. Por eso conviene separar dos preguntas: cuánto tarda la misma respuesta en llegar al usuario y cuánto cuesta producirla al volumen previsto. La ubicación de los datos, los aciertos de caché y la concurrencia también pueden cambiar ambas respuestas.

Por qué los benchmarks dan respuestas distintas

El ensayo citado por Vercel mide cargas de renderizado con recursos diferentes. Sirve para observar el rendimiento de cada despliegue probado, pero no para atribuir toda la diferencia de latencia al motor de ejecución. Una función con más memoria y capacidad de CPU puede procesar una carga intensa con ventaja; una ruta dominada por la espera de una base de datos puede mostrar un resultado distinto para el usuario.

En su análisis de los benchmarks, Cloudflare explicó que modificó ajustes de su plataforma y corrigió problemas de la prueba; en sus nuevas mediciones declaró paridad con Vercel en los casos examinados, salvo el basado en Next.js. También cambió las condiciones de ejecución del ensayo, incluida la ubicación del cliente de prueba y la capacidad asignada a la función de Vercel. Las cifras de ambas publicaciones corresponden, por tanto, a pruebas con métodos y configuraciones distintos. La excepción de Next.js merece atención propia porque su adaptación a Workers interviene en el renderizado.

Qué hay que igualar para comparar latencia

La unidad útil es una ruta concreta que entregue el mismo HTML a partir de los mismos datos. Deben mantenerse la versión del framework, las dependencias y la política de caché. Si una plataforma responde desde caché y la otra ejecuta SSR en cada solicitud, la diferencia mide sobre todo dos decisiones de arquitectura. También conviene distinguir el tiempo de CPU del tiempo total de respuesta: una función puede consumir poca CPU mientras espera datos remotos y, aun así, responder lentamente.

La memoria no siempre se puede igualar. El límite por isolate de Workers y la memoria configurable de Vercel obligan a comparar primero configuraciones en las que la aplicación realmente funciona. Después se puede observar qué parte de la latencia procede del renderizado, de una llamada a la base de datos o de la entrega al usuario. Para esa comparación, la región elegida en Vercel y la ubicación de los datos importan tanto como la cercanía del código al visitante: una ejecución próxima al usuario todavía puede depender de una consulta lejana.

La concurrencia altera especialmente el coste de la espera. Si varias solicitudes comparten una instancia de Fluid compute, el tiempo durante el cual mantiene memoria asignada se reparte entre ellas. Una prueba con solicitudes aisladas no reproduce necesariamente ese patrón. Para una API independiente de Next.js, tampoco conviene trasladar sin más una medición hecha con ese framework y su adaptador: la carga que se ejecuta es otra.

Cuánto cuestan tres niveles de tráfico

La tarifa oficial de Workers Paid fija un mínimo de 5 dólares al mes, con 10 millones de solicitudes y 30 millones de milisegundos de CPU incluidos; el exceso cuesta 0,30 dólares por millón de solicitudes y 0,02 dólares por millón de milisegundos de CPU. Cloudflare no añade un cargo por transferencia de salida de Workers. La duración de una solicitud mientras espera una respuesta externa no se factura como CPU, aunque los servicios adicionales que utilice la aplicación pueden generar otros cargos.

La tarifa oficial de Fluid compute cobra en Pro las invocaciones a 0,60 dólares por millón y, en Washington D. C., la CPU activa a 0,128 dólares por hora y la memoria aprovisionada a 0,0106 dólares por GB-hora. La CPU deja de acumular consumo durante una espera de entrada o salida; la memoria sigue asignada mientras la instancia atiende solicitudes. El crédito mensual de uso de Pro puede reducir el importe que finalmente se paga.

El siguiente es un ejemplo condicional de consumo de funciones, no una medición ni una predicción de factura. Supone que la misma respuesta viable en ambas plataformas emplea 100 ms de CPU y mantiene activa la solicitud durante 300 ms. Para Vercel se asignan 4 GB en Washington D. C. y se supone que ninguna solicitud comparte instancia con otra; para Cloudflare se aplica Workers Paid. Los importes excluyen créditos, almacenamiento, otros servicios y la transferencia que Vercel pudiera facturar:

Con 1 millón de solicitudes dinámicas al mes: 6,40 dólares en Workers y 7,69 dólares de consumo bruto en Fluid compute.
Con 10 millones: 24,40 dólares en Workers y 76,89 dólares de consumo bruto en Fluid compute.
Con 100 millones: 231,40 dólares en Workers y 768,89 dólares de consumo bruto en Fluid compute.

El cálculo muestra cómo crece una diferencia de precio bajo supuestos fijos; no incorpora la ventaja de velocidad observada en el benchmark. Si Vercel termina antes la misma tarea, puede consumir menos CPU y mantener la memoria asignada durante menos tiempo. Si atiende varias solicitudes en una instancia, también reparte el coste de esa memoria. A la inversa, una ruta que espera mucho por un servicio externo conserva memoria aprovisionada durante la espera. Esas variaciones pueden cambiar el orden económico, especialmente con poco tráfico.

El adaptador cambia el caso de Next.js

La guía de Vercel sobre Next.js distingue la ejecución nativa en Vercel Functions del despliegue en Workers mediante el adaptador OpenNext para Cloudflare. Este transforma la salida de compilación para el runtime de Workers, que ofrece compatibilidad con APIs de Node.js mediante una capa específica. Algunas APIs tienen soporte parcial, por lo que una dependencia que funciona en un servidor Node.js puede requerir cambios al trasladarla.

También difieren las piezas necesarias para ciertas funciones del framework. En Cloudflare, la regeneración incremental y determinados tipos de invalidación requieren configurar servicios de caché adicionales. Vercel integra esas capacidades en su despliegue de Next.js. Esa diferencia afecta al trabajo de mantenimiento y puede intervenir en la latencia de una ruta; no significa que todo SSR en Workers dependa de Next.js o de OpenNext.

Cuando una aplicación necesita middleware de Node.js, dependencias con APIs completas de ese entorno o más memoria por función, Vercel ofrece un camino más directo. Workers resulta una opción razonable si la aplicación cabe en sus límites, sus dependencias son compatibles y predominan respuestas cortas para usuarios distribuidos. Para decidir entre ambas, la comparación que importa combina la latencia de las rutas dinámicas con su consumo proyectado y trata por separado los recursos estáticos servidos desde caché.