Edge runtime
Définition
Exécution du code serveur sur un réseau mondial de points de présence (CDN), au plus près de l'utilisateur. Latence très faible, idéal pour les routes critiques d'une app globale.
Comment ça marche
Un edge runtime exécute votre code serveur sur un réseau de points de présence (PoP) mondiaux, au lieu d'un datacenter unique. Une requête HTTP est routée vers le PoP le plus proche géographiquement, où la fonction tourne et renvoie sa réponse. Vercel s'appuie sur Cloudflare Workers (architecture V8 isolates), Cloudflare Workers utilise sa propre infrastructure, Deno Deploy fait pareil. Le runtime est plus léger qu'un Node.js complet : démarrage en quelques millisecondes (pas de cold start de plusieurs centaines de ms), exécution dans un isolate V8 partagé, limites strictes de CPU et de mémoire. C'est conçu pour la latence avant tout.
À quoi ça sert
Le edge runtime sert les cas où chaque milliseconde compte. Middleware de redirections et de réécritures (A/B testing, internationalisation, redirections SEO). Authentification rapide (vérification d'un JWT, lecture d'un cookie de session). Pages statiques personnalisées (afficher un nom utilisateur sans casser le SSG). Webhooks à fort volume où le cold start de Lambda serait pénalisant. APIs lecture-seule à faible logique métier. Pour ces cas, on passe de 300 ms de latence côté serveur à 30 ms, ce qui change radicalement l'expérience perçue, surtout sur des audiences internationales.
Les contraintes du runtime
Le edge runtime n'est pas Node.js. Pas de système de fichiers, pas de child_process, pas de net.Socket. Les API Web standards (fetch, Request, Response, Headers, crypto.subtle) fonctionnent. Beaucoup de libs npm ne marchent pas si elles dépendent d'API Node spécifiques. Les ORM lourds (Prisma sans Data Proxy) sont incompatibles, alors que Drizzle marche bien. Les bibliothèques de PDF, d'images lourdes, de calcul scientifique sont à oublier. La durée d'exécution est limitée (50 ms CPU sur Cloudflare Free, plus sur Workers Paid). Avant de passer une route en edge, on vérifie systématiquement la compatibilité des dépendances.
Edge vs Node serverless
Node serverless (Vercel Functions Node, AWS Lambda Node) offre la compatibilité complète avec l'écosystème npm. C'est le défaut pour la majorité des routes API d'un projet Next.js. Le edge runtime ne le remplace pas, il le complète : on bascule en edge les routes qui en bénéficient (latence, scale mondial), on garde en Node celles qui ont besoin de Node. Next.js permet de choisir runtime par route via export const runtime = 'edge' ou 'nodejs'. Sur un projet moyen, 10 à 20% des routes vont en edge, le reste reste en Node. La cohabitation est transparente côté code.
Quand l'utiliser
On choisit le edge runtime pour les middleware Next.js (obligatoires en edge), les redirections géographiques ou liées au cookie, l'A/B testing sans flash, l'authentification de session JWT, les pages avec personnalisation légère (nom, locale, theme). Pour un site international ou e-commerce mondial, le gain de TTFB est significatif. Sur un dashboard interne avec utilisateurs concentrés en France, l'apport est marginal et ne justifie pas les contraintes. La question à se poser : est-ce que mes utilisateurs sont géographiquement dispersés ? Si oui, edge. Si non, Node serverless ou serveur classique.
Quand ne pas l'utiliser
On évite le edge runtime pour tout ce qui demande Node natif : utilisation de Prisma client classique, traitement d'images avec sharp, génération de PDF avec puppeteer, accès à un système de fichiers local, connexions persistantes (WebSocket serveur, long polling). Pour les jobs longs (au-delà de quelques secondes de CPU), c'est éliminatoire. Pour les workflows avec retry, transactions distribuées, ou orchestration complexe, un container ou un serveur classique reste plus adapté. Et pour les volumes très faibles où la latence n'est pas critique, l'effort d'adaptation au runtime contraint n'a pas de retour sur investissement.
Les pièges à éviter
Le piège principal : utiliser une lib qui dépend d'API Node sans le savoir. Le build passe, le runtime crash. On teste systématiquement les routes edge avec un déploiement preview avant la prod. La limite de CPU (50 à 100 ms selon les plans) bloque les calculs lourds : on déporte alors la logique vers une fonction serverless classique ou un service dédié. Les variables d'environnement sont accessibles différemment en edge (pas de process.env classique partout). Les middleware tournent à chaque requête : un middleware mal écrit (appel API tiers à chaque page) explose les coûts. On les garde minimaux.