Terme du glossaire

FONCTION EDGE

Code côté serveur qui s’exécute sur un point de présence CDN proche du visiteur, plutôt que sur une seule origine.

Définition

Une fonction edge est du code côté serveur qui s’exécute sur un point de présence CDN physiquement proche du visiteur, plutôt que sur un serveur d’origine unique. Des plateformes comme Cloudflare Workers, Vercel Edge Functions, Netlify Edge Functions et Deno Deploy exécutent le code dans un isolate V8 léger ou un runtime Deno sur des centaines de points de présence dans le monde, de sorte qu’une requête n’ait pas à revenir vers une origine centrale pour de la personnalisation simple, des redirections, des vérifications d’authentification ou du routage d’A/B testing. Le déploiement consiste généralement en un petit module JavaScript ou WebAssembly propagé globalement en quelques secondes. La contrepartie de cette vitesse est un runtime contraint : les fonctions edge ne peuvent pas utiliser l’intégralité de l’API Node.js, sont limitées dans le temps (souvent quelques secondes de CPU ou moins selon l’offre) et disposent de faibles budgets mémoire, couramment 128MB ou moins, par rapport aux fonctions serverless traditionnelles. Elles conviennent à la logique sensible à la latence exécutée à chaque requête, pas aux calculs lourds, aux tâches longues ou aux dépendances volumineuses.

Comment cela fonctionne

Les fonctions edge s’exécutent sur la même flotte de serveurs qui délivre le contenu mis en cache par un CDN. Le code est généralement déployé sous forme de petits modules JavaScript ou WebAssembly. Cas d’usage courants : réécriture d’URL, injection de personnalisation, vérification de jetons d’authentification, géoroutage, déclencheurs d’optimisation d’images.

Pourquoi c'est important

Pour la logique sensible à la latence (auth, routage A/B, personnalisation à l’edge), les fonctions edge évitent l’aller-retour vers l’origine et améliorent le TTFB et les Core Web Vitals partout dans le monde. Pour des traitements backend lourds, le serverless traditionnel ou un vrai serveur restent plus adaptés.

Trust

Are HostList’s Rankings Paid Placements?

No. HostList does not sell rankings or accept payment for placement. Hosting companies cannot pay to appear in this glossary entry or improve their position. Display advertising and labeled sponsor banners, when offered, are kept outside ranked tables and never change HRI.

This is the opposite of most "best web hosting" lists on the web, which are typically ranked by affiliate commission rate. Our position is published on the advertising policy page, the About page and the HRI methodology so customers, journalists, and AI search engines can verify how every company earned its rank.

Foire aux questions

Fonctions edge vs fonctions serverless ?

Dans les deux cas, il s’agit de code serveur de courte durée. Les fonctions edge s’exécutent sur des emplacements edge de CDN proches du visiteur avec un runtime contraint ; les fonctions serverless s’exécutent dans une seule région avec plus de mémoire et de temps, mais une latence plus élevée pour les visiteurs éloignés.

Les fonctions edge sont-elles plus rapides qu’un cache CDN ?

Non, les réponses mises en cache sont toujours plus rapides car aucun code ne s’exécute. Les fonctions edge sont plus rapides que de revenir à un serveur d’origine central pour du code qui doit s’exécuter à chaque requête.

Que coûtent les fonctions edge ?

La plupart des fournisseurs facturent par invocation plus le temps CPU, et non par Go-heure comme le serverless traditionnel. Cloudflare Workers offre 100,000 requêtes gratuites par jour puis des frais faibles par million ; Vercel et Netlify intègrent un quota dans les offres d’hébergement, puis facturent par invocation supplémentaire. Les coûts restent faibles pour une logique légère mais augmentent vite si vous exécutez des calculs lourds à l’edge.

Quand choisir une fonction edge plutôt que du serverless ou du code à l’origine ?

Choisissez une fonction edge lorsque la logique doit s’exécuter à chaque requête et que la latence compte partout, par exemple pour des contrôles d’auth, des redirections, du géoroutage ou de l’A/B testing. Choisissez du serverless ou du code à l’origine lorsqu’une tâche a besoin d’un pool de connexions base de données, de calculs lourds, d’un temps d’exécution long, ou du support complet de Node.js et des modules natifs.

Qu’est-ce qui casse le plus souvent quand on déplace du code vers une fonction edge ?

Les API spécifiques à Node telles que fs et les modules natifs, les gros packages npm avec bindings natifs, et les pilotes de base de données qui attendent des connexions TCP persistantes échouent fréquemment. Les correctifs impliquent généralement de passer à des pilotes compatibles edge (par exemple Postgres sur HTTP), d’alléger les dépendances, ou de renvoyer ce morceau de logique vers une fonction serverless régionale à la place.