Edge runtime : les configurations où il est devenu plus lent que Node

L'argument marketing de l'edge est convaincant : exécuter le code au plus proche de l'utilisateur, réduire la latence réseau, éliminer les aller-retours vers une région centralisée. Vercel, Cloudflare, Netlify, tous poussent vers l'edge par défaut. Mais "plus proche de l'utilisateur" ne signifie pas automatiquement "plus rapide", et plusieurs configurations courantes inversent l'équation.

Pourquoi l'edge est censé être plus rapide

L'argument de base est géographique. Si votre serveur Node.js tourne à Paris et votre utilisateur est à Tokyo, chaque requête subit une latence réseau aller-retour d'environ 240 ms. Si votre fonction s'exécute sur un nœud edge à Tokyo, cette latence tombe à quelques millisecondes.

Pour du contenu statique ou des opérations sans état, c'est un gain réel. Pour une API de recherche avec un seul paramètre, traitement minimal, et réponse simple, l'edge est effectivement plus rapide.

Le problème commence quand on ajoute de la dépendance : une base de données, une API tierce, un cache distribué, un ORM complet.

Cas 1 : la base de données n'est pas à l'edge

C'est le piège le plus fréquent. Vous déployez votre middleware ou votre route handler en edge function. Votre base de données PostgreSQL tourne sur une instance RDS à eu-west-1. Votre utilisateur est à São Paulo.

Sans edge : requête São Paulo → Paris (serveur Node) → Paris (RDS). Latence réseau : 200 ms + quelques millisecondes de traitement.

Avec edge : requête São Paulo → nœud edge São Paulo → Paris (RDS) → São Paulo. Latence : 2 ms (edge local) + 200 ms (edge → RDS) + 200 ms (retour). Vous avez ajouté un aller-retour.

La latence totale augmente parce que vous avez introduit un saut supplémentaire sans déplacer la source de données. L'edge gagne sur la proximité réseau avec l'utilisateur, mais perd sur la distance avec la ressource stateful.

Les bases de données distribuées résolvent théoriquement ce problème : PlanetScale, Neon, Turso, CockroachDB proposent des répliques en lecture dans plusieurs régions. En pratique, configurer et maintenir la cohérence entre répliques ajoute une complexité opérationnelle significative, et les latences d'écriture restent contraintes par la région primaire.

Cas 2 : le cold start edge vs Node

L'edge est souvent associé à l'absence de cold start. Ce n'est pas tout à fait exact.

Sur Cloudflare Workers, les isolates V8 démarrent en quelques millisecondes, c'est le modèle d'isolation sans container. Sur Vercel Edge Functions (qui repose sur Cloudflare), le cold start est effectivement minimal.

Mais sur d'autres environnements edge, notamment AWS Lambda@Edge, le modèle de déploiement repose sur Lambda classique distribuée sur des points de présence CloudFront. Le cold start y est de l'ordre de 500 ms à 1 s sur les régions moins actives, comparable à une Lambda Node standard. Le branding "edge" masque une implémentation qui n'a pas les propriétés de latence des Workers natifs.

Mesure concrète publiée par Fastly sur des scénarios réels : la latence P99 de Lambda@Edge sur des régions peu fréquentées (Asie du Sud-Est, Amérique du Sud) est souvent supérieure à une Lambda Node.js standard dans une région centrale, parce que le pool d'instances warm est plus petit.

Cas 3 : les restrictions d'API runtime

L'edge runtime dans Next.js ne supporte pas l'ensemble de l'API Node.js. La liste des modules indisponibles comprend notamment fs, crypto (partiel), net, child_process, et une partie des modules stream.

Cette restriction casse silencieusement certains outils :

export const runtime = "edge";

// Ceci va lever une erreur au runtime, pas à la compilation
import { readFileSync } from "fs";

// Ceci aussi, aws-sdk v2 utilise des modules Node non supportés
import AWS from "aws-sdk";

Les SDKs tiers qui ont été écrits pour Node.js standard ne fonctionnent pas en edge runtime sans version spécifique "edge-compatible". Stripe, certains SDKs d'authentification, des clients de cache comme ioredis, tous nécessitent soit une alternative, soit un contournement.

La conséquence en production : un middleware edge qui échoue silencieusement à importer un module peut renvoyer une réponse vide ou un 500 sans message d'erreur clair, selon la plateforme. Le debugging est plus difficile qu'en Node.js standard où les stack traces sont complètes.

Cas 4 : les payloads de réponse volumineux

Les edge functions ont des limites de taille mémoire strictes. Sur Cloudflare Workers : 128 Mo de RAM par défaut, extensible à 512 Mo sur le plan Workers Unbound. Sur Vercel Edge Functions : 128 Mo.

Pour une API qui sérialise de gros objets JSON, génère des PDF, ou traite des images, ces limites sont atteintes rapidement. Un traitement qui fonctionne sans problème sur une Lambda Node avec 1 Go de RAM échoue en edge.

La limite de durée d'exécution est aussi contraignante : 30 secondes sur Vercel Edge, contre 15 minutes sur Lambda. Tout traitement long doit être déplacé vers une fonction asynchrone non-edge.

Quand l'edge reste le bon choix

L'edge fonctionne bien pour un ensemble de cas précis :

• Redirection et réécriture d'URL (middleware stateless)
• Authentification légère par vérification de token JWT (sans appel réseau externe)
• Géolocalisation et personnalisation basée sur les headers de la requête
• Rate limiting basé sur l'IP avec stockage edge distribué (KV Cloudflare, Vercel KV)
• Réponses entièrement calculables à partir de la requête sans dépendance externe

Pour tout ce qui implique une base de données relationnelle, une API tierce avec latence variable, ou des opérations CPU-intensives, Node.js dans une région bien choisie reste généralement plus simple, plus prévisible, et souvent plus rapide en P99.

L'arbitrage n'est pas "edge ou Node", c'est "quel composant de mon système bénéficie de la proximité avec l'utilisateur, et quel composant est contraint par ses dépendances stateful ?"