Vercel Fluid vs Cloudflare Workers. 💬"Según mis hallazgos, Vercel es de 1.2x a 5x más rápido que CloudFlare para el renderizado del servidor." Hicimos un intento muy, muy serio con Workers cuando exploramos el runtime / mundo edge. No hay "conflicto", tuvimos que migrar por razones técnicas. Para ser justos con ellos, trajeron nuevas ideas al mercado. La fijación de precios basada en CPU, por ejemplo, fue buena y Vercel Fluid también la tiene. Los principales problemas que encontramos: 1️⃣ Mal rendimiento de CPU, baja capacidad, latencia muy irregular y con picos. Las pruebas de rendimiento te muestran esto. 2️⃣ Runtime de un solo proveedor. No puedes ejecutar "Node.js 24". Ejecutas "lo que ellos te den, que intenta parecerse a Node.js pero no lo es" 3️⃣ Conectividad realmente mala a las nubes. Medimos el tiempo de ida y vuelta entre AWS y CF Workers como estando en los bajos 10s a 100s de milisegundos. El resultado de nuestra migración fue el lanzamiento de Fluid. Pagas por CPU, maneja la concurrencia como un servidor (costo-efectivo), controlas el tamaño / memoria de las funciones, obtienes runtimes completos y abiertos como @nodejs y Python, obtienes 1ms de latencia a los servicios en la nube… La mayoría de la gente hoy está usando Fluid y ni siquiera se da cuenta, porque simplemente funciona® con todo el ecosistema. Aquí están los benchmarks que @theo realizó:

Algunas personas preguntaron sobre 3️⃣. Si tu función está conectada a una base de datos (Supabase, PlanetScale, Neon) o servicio (Stripe), entonces los benchmarks se verían aún más dramáticos. La ventaja de latencia en la nube es formidable. "Edge" fue un error no solo en tiempo de ejecución, sino en la ubicación de computación para la lógica central de la aplicación. El problema es doble, cascadas (I/O) y CPU.