Calcul en périphérie pour votre site : cas d’usage et performances de Cloudflare Workers et Vercel Edge
1. Le edge computing, c’est quoi exactement, et quel est son lien avec le CDN
Un CDN classique ne fait que mettre en cache des fichiers statiques : la requête de l’utilisateur arrive et le cache est renvoyé directement. Le edge computing exécute un petit bout de code JavaScript sur les nœuds du CDN pour appliquer une logique avant de renvoyer la réponse : rediriger vers une page selon la position géographique, choisir une version selon le cookie, vérifier la validité d’un JWT. Cette logique s’exécute sur un nœud situé à quelques dizaines de millisecondes de l’utilisateur, sans repasser par le serveur d’origine.
La différence avec le rendu côté serveur (SSR) : le SSR tourne sur votre propre serveur, et tous les utilisateurs du monde doivent traverser les océans pour l’atteindre ; une fonction en périphérie tourne simultanément sur plus de 300 nœuds dans le monde, et l’utilisateur se connecte au plus proche. Pour un site B2B indépendant à l’international, cet écart de distance décide directement si le TTFB est de 100 ou de 800 millisecondes. Pour le lien entre CDN et périphérie, voir Accélération mondiale par CDN.
Un constat contre-intuitif : le edge computing n’est pas un “serveur plus rapide”, c’est un “serveur plus petit”. Le temps CPU de chaque fonction en périphérie est strictement plafonné, aucun calcul lourd n’est possible. Si vous déplacez en périphérie une requête à la base de données qui prend 200 millisecondes, le résultat sera plus de 3 fois plus lent qu’en serveur d’origine, car le nœud de périphérie est loin de la base.
| Environnement d’exécution | Emplacement | Plafond de temps CPU | Démarrage à froid | Accès à la base de données | Modèle de coût |
|---|---|---|---|---|---|
| Serveur classique (VPS) | Une seule salle machine | Aucune limite stricte | Aucun (permanent) | Local/réseau interne, rapide | Forfait mensuel, fixe |
| Cloudflare Workers | Plus de 300 nœuds dans le monde | 10 ms en gratuit/30 ms en payant | Quasi nul (isolation V8) | Base externe à connecter, lent | Facturation à la requête |
| Vercel Edge Functions | Plus de 25 nœuds dans le monde | Jusqu’à 30 secondes | 10 à 50 millisecondes | Compatible Edge DB | Facturation à la durée d’appel |
| AWS Lambda@Edge | Nœuds CloudFront mondiaux | Jusqu’à 5 secondes | 10 à 100 millisecondes | RDS à connecter via Internet | À la requête + à la durée |
2. Trois cas où le edge computing vaut vraiment le coup
Premier cas d’usage : rediriger selon la géolocalisation et la langue. Sur un site destiné à l’international, un visiteur allemand est envoyé automatiquement vers la version allemande /de/, un visiteur du Moyen-Orient vers la version arabe /ar/. La méthode classique consiste à lire une base d’adresses IP sur le serveur pour décider, ce qui oblige chaque requête à revenir à l’origine. Avec Cloudflare Workers, dix lignes de code suffisent pour renvoyer un 301 directement depuis le nœud de périphérie selon le pays de l’IP, et le TTFB passe de 400 ms à 50 ms. Pour configurer hreflang sur un site multilingue, voir Mise en place du hreflang multilingue.
Deuxième cas d’usage : répartir le trafic pour un test A/B. Vous voulez proposer deux versions de votre page d’accueil, 50 % des visiteurs voient la version A, 50 % la version B. La méthode classique lit un cookie côté serveur pour décider quelle version afficher. L’approche en périphérie est plus simple : Workers hache le cookie et réécrit directement les chemins de ressources dans le HTML ou injecte des variables différentes, sans que l’origine ne s’en aperçoive. La répartition elle-même s’effectue en 10 ms, sans impacter le TTFB.
Troisième cas d’usage : authentification légère et anti-scraping. Pour les requêtes envoyées après connexion, on vérifie d’abord la validité du JWT en périphérie ; s’il est invalide, on renvoie un 401 sans revenir à l’origine. L’origine ne traite ainsi que les requêtes légitimes, ce qui économise bande passante et CPU. L’anti-scraping peut aussi se faire en périphérie : dès qu’un UA suspect ou une fréquence de requêtes trop élevée est détecté, on renvoie directement une page de défi sans laisser la requête atteindre l’origine.
| Situation | Mise en œuvre en périphérie | Gain de performance | Charge de développement | Priorité recommandée |
|---|---|---|---|---|
| Redirection géographique | Workers lit request.cf.country | TTFB réduit de 50 à 150 ms | Une demi-journée | Élevée |
| Répartition de test A/B | Workers répartit selon le hachage du cookie | N’augmente pas le TTFB | 1 à 2 jours | Moyenne |
| Authentification JWT en périphérie | Vérifie le token en périphérie, refuse si invalide | Charge de l’origine réduite de 20 % à 40 % | 2 jours | Élevée |
| Anti-scraping / limitation de débit | Détecte l’UA et la fréquence en périphérie | Les requêtes malveillantes ne reviennent pas à l’origine | 1 jour | Élevée |
| Rendu de pages personnalisées | Assemble les fragments HTML en périphérie | Efficace uniquement sur les fragments répétés | 3 à 5 jours | Faible |
Trois, deux pièges à éviter avec le calcul en périphérie
Premier piège : déplacer les requêtes à la base de données en périphérie. Beaucoup pensent que « le calcul en périphérie, c’est très avancé » et y déplacent aussi la logique de requête de l’espace utilisateur. Résultat : le nœud de périphérie se connecte à une base de données distante, et un aller-retour réseau pour une seule requête prend 200 ms, soit 5 fois plus lent qu’une requête locale à l’origine. Une fonction en périphérie convient à une logique « sans état, peu calculatoire, reposant sur le cache », pas à une logique « qui doit interroger une base de données ».
Deuxième piège : déplacer tout le SSR en périphérie. Le mode Edge Runtime de Next.js permet certes d’exécuter le rendu React sur les nœuds de périphérie de Vercel, mais le temps CPU pour rendre une page complexe peut dépasser 100 ms, ce qui heurte les limites de la version gratuite, ou le démarrage à froid fait attendre 50 ms de plus au premier visiteur. Le rendu serveur complexe doit rester à l’origine, la périphérie ne servant que de couche intermédiaire légère. Pour gérer les scripts tiers, voir Gestion des scripts tiers.
Exemple concret : un SaaS qui se lance à l’international doit interroger sa base de données pour afficher le tableau de bord utilisateur. L’équipe, enthousiaste, réécrit cette page avec Vercel Edge Runtime. Verdict : la latence entre le nœud edge et leur base AWS RDS atteint 80 ms, et avec le temps de rendu, le TTFB passe de 250 ms à 450 ms. Ils rapatrient ensuite le tableau de bord sur le serveur d’origine et ne gardent en edge que la vérification de connexion et le routage. Le TTFB redescend alors à 250 ms.
| Piège | Bénéfice apparent | Ce que ça donne | Bonne pratique |
|---|---|---|---|
| Déplacer les requêtes base de données en edge | “Plus proche des utilisateurs” | Le réseau edge-DB est long, la latence est multipliée par 3 à 5 | Garder les requêtes DB sur le serveur d’origine, l’edge ne fait que de la lecture en cache |
| Faire tourner tout le SSR en edge | “Accélération mondiale” | CPU saturé ou démarrage à froid lent, le TTFB augmente au contraire | L’edge ne sert que de couche intermédiaire, le rendu reste sur le serveur d’origine |
| Nombreuses lectures et écritures de fichiers | “Traitement local” | Pas de disque persistant en edge, mémoire limitée | Passer par l’API de stockage objet pour les opérations sur fichiers |
| Tâches de calcul longues | “Plus rapide en parallèle” | Dépassement du CPU : erreur 1102 directe | Découper en petites tâches ou passer par une file de messages |
4. Coûts et choix : Cloudflare Workers vs Vercel Edge
Cloudflare Workers et Vercel Edge Functions sont aujourd’hui les deux plateformes edge les plus utilisées par les sites indépendants. Le choix dépend surtout de votre stack technique et de votre volume de trafic. Cloudflare Workers repose sur V8 isolate, avec un démarrage à froid quasi nul et 100 000 requêtes par jour en version gratuite : idéal pour du routage léger et de l’authentification. Vercel Edge Functions s’intègre profondément à Next.js : si vous utilisez déjà Next.js, la migration coûte le moins cher, mais le démarrage à froid est plus lent que sur Workers.
Côté coûts, la version payante de Cloudflare démarre à 5 $/mois, avec 10 millions de requêtes incluses ; Vercel Pro démarre à 20 $/mois, les fonctions edge étant facturées au temps d’exécution, la facture grimpe vite quand le trafic augmente. Pour un site B2B indépendant de taille moyenne avec moins de 100 000 PV par mois, la version gratuite de Cloudflare suffit largement. Pour savoir comment surveiller les performances, voir Surveillance et alertes du site.
| Dimension | Cloudflare Workers | Vercel Edge Functions | AWS Lambda@Edge |
|---|---|---|---|
| Démarrage à froid | Quasi nul (V8) | 10 à 50 millisecondes | 10 à 100 millisecondes |
| Quota gratuit | 100 000 requêtes/jour | 100 GB-heures/mois | 1 million de requêtes/mois |
| Offre payante à partir de | 5 $/mois | 20 $/mois | À l’usage, sans forfait mensuel |
| Langage de développement | JavaScript/TypeScript | JavaScript/TypeScript | Node.js/Python |
| Frameworks adaptés | Fonctions pures/middleware | Intégration profonde à Next.js | Sites de l’écosystème AWS |
| Couverture des nœuds | Plus de 300 villes | Plus de 25 pays | CloudFront mondial |
FAQ — Questions fréquentes
La version gratuite de Cloudflare Workers suffit-elle vraiment ?
Quel est le rapport entre les fonctions edge et le cache CDN ?
Vercel Edge Functions ou Cloudflare Workers, lequel est le plus rapide ?
Une fonction edge peut-elle optimiser le SEO ?
Comment revenir en arrière si une fonction edge plante ?
Dans quels cas l’edge computing n’accélère-t-il pas un site ?
Pour conclure
L’edge computing est une optimisation ciblée, pas une révolution de l’architecture de tout un site. Il résout un goulot d’étranglement précis : « chaque requête doit revenir à l’origine ». Il convient à de la logique légère de routage, d’authentification ou de répartition. Si vous partez avec l’idée qu’« passer en edge va doubler la vitesse de tout le site », vous serez probablement déçu : la plupart des lenteurs viennent des requêtes en base de données et des scripts tiers, pas de la distance réseau.
Conseil de mise en œuvre : commencez par un cas d’usage minimal. Configurez d’abord une redirection géographique avec Cloudflare Workers pour envoyer automatiquement les utilisateurs allemands vers la version allemande du site. Cette modification peut être déployée en une demi-journée, avec un gain de performance immédiat et un risque minimal. Après deux semaines de fonctionnement stable, envisagez d’ajouter un test A/B ou une authentification en périphérie. Ne cherchez pas à migrer tout le site vers l’edge dès le départ.
Une phrase à retenir : l’edge computing, c’est le point de livraison le plus proche de l’utilisateur, pas l’entrepôt le plus proche de la base de données. Confiez-lui le tri, mais ne déplacez pas l’entrepôt chez lui.