Vercel Fluid vs Cloudflare Workers. 💬"D'après mes constatations, Vercel est 1,2x à 5x plus rapide que CloudFlare pour le rendu côté serveur." Nous avons fait un essai très, très sérieux avec Workers lorsque nous avons exploré le runtime / monde edge. Il n'y a pas de "conflit", nous avons dû migrer pour des raisons techniques. Pour être juste envers eux, ils ont apporté de nouvelles idées sur le marché. La tarification basée sur le CPU, par exemple, était bonne et Vercel Fluid l'a également. Les principaux problèmes que nous avons rencontrés : 1️⃣ Mauvaise performance CPU, faible capacité, latence très irrégulière et en pics. Les benchmarks vous le montrent. 2️⃣ Runtime à fournisseur unique. Vous ne pouvez pas exécuter "Node.js 24". Vous exécutez "ce qu'ils vous donnent, qui essaie de ressembler à Node.js mais ce n'est pas le cas" 3️⃣ Connectivité vraiment mauvaise avec les clouds. Nous avons mesuré le temps de réponse entre AWS et CF Workers comme étant dans les faibles dizaines à centaines de millisecondes. Le résultat de notre migration a été l'expédition de Fluid. Vous payez pour le CPU, il gère la concurrence comme un serveur (économique), vous contrôlez la taille / la mémoire des fonctions, vous obtenez des runtimes complets et ouverts comme @nodejs et Python, vous obtenez une latence de 1 ms vers les services cloud… La plupart des gens aujourd'hui utilisent Fluid et ils ne s'en rendent même pas compte, car cela fonctionne simplement® avec tout l'écosystème. Voici les benchmarks que @theo a réalisés :

Certaines personnes ont posé des questions sur 3️⃣. Si votre fonction est connectée à une base de données (Supabase, PlanetScale, Neon) ou à un service (Stripe), alors les benchmarks seraient encore plus dramatiques. L'avantage de latence en cloud est formidable. "Edge" était une erreur non seulement en termes d'exécution, mais aussi en ce qui concerne l'emplacement de calcul pour la logique principale de l'application. Le problème est double, les cascades (I/O) et le CPU.