Cloudflare Workers ou Vercel Functions : 128 Mo peuvent faire basculer le choix

Pour une API légère qui reçoit des appels du monde entier, Cloudflare Workers offre un coût de départ bas et une exécution proche des visiteurs. Pour un rendu Next.js gourmand en mémoire, la faisabilité peut trancher avant le prix : le comparatif Next.js de Vercel indique une limite fixe de 128 Mo par isolate Worker, contre une mémoire configurable jusqu’à 4 Go par fonction Vercel.

Le bon choix dépend donc de ce que fait chaque appel, et pas seulement du trafic mensuel. Une route qui renvoie une petite réponse après une attente réseau sollicite peu le processeur ; un rendu qui conserve beaucoup de données en mémoire peut dépasser la capacité d’un Worker même avec peu de visiteurs. La durée de vie de la fonction, la région des données et l’intégration de Next.js modifient ensuite la facture et la latence.

Quand la mémoire décide avant le prix

Les 128 Mo sont la capacité de l’isolate dans lequel tourne un Worker, pas une allocation que l’on augmente pour une route exigeante. Si le traitement doit garder simultanément en mémoire un ensemble de données volumineux et les objets nécessaires au rendu, cette limite peut empêcher son exécution sans modification. Il faut alors réduire l’empreinte du traitement, répartir le travail ou choisir un environnement offrant davantage de mémoire.

Vercel Functions permet d’allouer plus de mémoire à une fonction Next.js. Cette possibilité rend praticable une charge qui ne tient pas telle quelle dans un Worker, mais elle ne signifie pas que toute application Next.js en a besoin. Une route courte, compatible avec le runtime Workers et peu consommatrice de mémoire peut profiter du modèle Cloudflare ; l’empreinte du rendu doit être examinée séparément du nombre de pages vues.

Appels, processeur, mémoire et siège : quatre postes distincts

La tarification de Cloudflare Workers fixe le minimum de l’offre Paid à 5 $ par mois, avec 10 millions de requêtes et 30 millions de millisecondes de processeur incluses ; les dépassements coûtent respectivement 0,30 $ par million de requêtes et 0,02 $ par million de millisecondes. Cloudflare n’ajoute pas de frais de transfert sortant ou de bande passante à ce barème. Le temps passé à attendre une réponse externe n’est pas du temps de processeur actif.

Sur Vercel, les compteurs de Fluid Compute suivent une autre logique. La grille des fonctions Vercel facture sur Pro chaque appel, le processeur actif et la mémoire provisionnée pendant la vie de l’instance ; à Paris, elle affiche 0,177 $ par heure de processeur, 0,0146 $ par Go-heure de mémoire et 0,60 $ par million d’appels. Le processeur cesse d’être facturé pendant une attente d’entrée-sortie, tandis que la mémoire allouée reste facturable tant que l’instance traite une requête. Plusieurs requêtes peuvent partager une instance, ce qui change le coût de mémoire par appel.

Le plan Pro de Vercel coûte 20 $ par mois, comprend un siège développeur et accorde 20 $ de crédit mensuel d’usage ; un siège développeur supplémentaire coûte 20 $ par mois. Le CDN du plan Pro est présenté à tarif forfaitaire. Pour comparer les fonctions ci-dessous, le calcul retient un siège, applique le crédit aux frais d’usage et laisse de côté les autres produits, les taxes et les éventuels frais hors de ce périmètre.

Trois charges mensuelles calculées avec les mêmes règles

Les simulations de Morph examinent 1, 10 et 100 millions de requêtes, avec 10 ms de processeur par appel pour leur API type. Leur calcul Vercel utilise une région américaine et exclut la mémoire provisionnée ; il inclut aussi des hypothèses de facturation du CDN différentes du forfait Pro affiché actuellement. Les exemples conditionnels suivants utilisent les tarifs de Paris et comptent la mémoire, sans prétendre mesurer la performance des plateformes.

Chaque scénario suppose qu’une requête atteint effectivement la fonction et déclenche un appel facturable. Pour Vercel, l’allocation est fixée à 2 Go et chaque instance traite une requête à la fois ; le temps de vie indiqué correspond à la période pendant laquelle sa mémoire est provisionnée. Ces hypothèses rendent le calcul lisible, mais la concurrence entre requêtes, la mise en cache et d’autres services utilisés par l’application peuvent modifier une facture réelle.

Un million d’appels pour une API légère. Supposons 10 ms de processeur actif et 50 ms de vie d’instance par appel. Workers reste à 5 $ : appels et processeur demeurent dans les volumes inclus. Sur Vercel, le processeur représente environ 0,49 $, la mémoire 0,41 $ et les appels 0,60 $, soit 1,50 $ d’usage arrondi. Ce montant tient dans le crédit Pro : avec le siège retenu, le total du périmètre calculé est de 20 $. À cette échelle, l’écart provient surtout du prix de départ du plan.

Dix millions d’appels pour un rendu Next.js exigeant. Supposons que chaque requête exige réellement 1 Go de mémoire, consomme 250 ms de processeur et maintienne son instance en vie pendant 2 secondes. Ce traitement ne tient pas tel quel dans la limite mémoire d’un Worker. Avec 2 Go alloués sur Vercel, les opérations donnent environ 122,92 $ de processeur, 162,22 $ de mémoire et 6 $ d’appels. L’usage atteint ainsi 291,14 $ ; après le crédit appliqué au prix du plan, le total de ce périmètre est également d’environ 291,14 $. L’attente comprise dans la vie de l’instance explique pourquoi la mémoire coûte ici davantage que le processeur.

Cent millions d’appels pour la même API légère. En reprenant 10 ms de processeur et 50 ms de vie d’instance par appel, Workers atteint 51,40 $ : 5 $ de base, 27 $ de requêtes supplémentaires et 19,40 $ de processeur supplémentaire. Sur Vercel, les postes représentent environ 49,17 $ de processeur, 40,56 $ de mémoire et 60 $ d’appels. Leur somme, 149,72 $ après arrondi, dépasse le crédit Pro ; le total calculé reste donc d’environ 149,72 $ avec un siège. Le volume favorise Workers dans cet exemple parce que le travail par appel demeure court et compatible avec sa limite mémoire.

La région et Next.js déplacent aussi le point d’équilibre

Par défaut, un Worker s’exécute près de la requête entrante, tandis qu’une fonction Vercel s’exécute dans une région choisie. Pour une API qui répond presque entièrement sur place à des visiteurs répartis dans plusieurs pays, cette proximité peut réduire le trajet réseau. Si chaque appel doit joindre une base de données concentrée dans une région, le trajet entre la fonction et les données peut compter davantage : placer le calcul près de cette base devient alors un critère de latence.

L’intégration du framework pèse sur le travail de l’équipe. Vercel exécute Next.js dans son environnement natif ; sur Workers, le déploiement passe par une adaptation au runtime Cloudflare et demande de considérer la compatibilité des dépendances et la configuration du cache. Pour un site dont le rendu serveur et la revalidation sont centraux, ce travail fait partie du choix, même si les seuls compteurs de calcul paraissent avantageux.

Quel choix retenir ?

Workers convient à une API légère, très sollicitée et compatible avec sa capacité mémoire ; les scénarios courts montrent l’effet de son forfait et de ses volumes inclus. Vercel Functions devient le choix praticable quand une fonction Next.js a réellement besoin de plus de mémoire, ou quand son exécution régionale et son intégration directe répondent mieux à l’architecture de l’application. La comparaison mensuelle gagne à partir des appels qui atteignent la fonction, du processeur actif, de la durée pendant laquelle la mémoire reste provisionnée et de la région des données : un même volume de trafic peut produire des coûts et des contraintes très différents.

À lire aussi :

• Cloudflare Workers limite enfin un jeton CI/CD à une seule application
• Homebrew 6 : faire confiance à une formule sans ouvrir tout le dépôt
• Ando lève 20 M$ : ses agents peuvent rejoindre une conversation sans invitation