Netlify a basculé l’exécution de ses Edge Functions depuis des isolats V8 pilotés par un service externe vers des microVM Firecracker tournant directement dans son propre réseau de périphérie. Le changement, détaillé dans un billet technique publié le 1er octobre 2026, ne touche à aucune API publique mais redessine en profondeur la latence et l’isolation des fonctions exécutées en edge.
Une architecture qui rapatrie l’exécution en interne
Jusqu’ici, une requête destinée à une Edge Function Netlify était routée vers un service d’exécution tiers avant de revenir dans le réseau de l’hébergeur. Avec les microVM Firecracker, popularisées par AWS Lambda pour leur démarrage rapide et leur isolation matérielle légère, le code s’exécute désormais à l’intérieur même de l’infrastructure de périphérie de Netlify. L’entreprise maîtrise ainsi l’intégralité du trajet de la requête, de l’entrée sur son réseau jusqu’à la réponse.
Les gains de performance mesurés
Netlify publie des chiffres précis issus de sa propre télémétrie de production, comparant l’ancienne et la nouvelle architecture pour les invocations dites « chaudes », c’est-à-dire sans démarrage à froid.
| Indicateur | Avant (isolats V8) | Après (microVM Firecracker) |
|---|---|---|
| Latence médiane (p50) | 25 à 40 ms | 5 à 6 ms |
| Latence p99 | référence | -47,4 % |
| Disponibilité mesurée | – | 99,998 % |
| Invocation à froid (≈1,2 % des requêtes) | – | ≈9 ms avec récupération d’image |
Aucun changement requis côté code
Pour les équipes qui exploitent déjà des Edge Functions, la bascule est transparente : les imports par URL, les paquets npm utilisés et la configuration existante continuent de fonctionner à l’identique. Un développeur qui s’appuie sur des outils CLI habituels pour son flux de déploiement n’a donc rien à adapter.
export default async (request, context) => {
const country = context.geo?.country?.code ?? "FR";
const response = await context.next();
response.headers.set("x-edge-country", country);
return response;
};
export const config = { path: "/*" };
Une isolation renforcée entre clients
Contrairement aux isolats V8, qui partagent un même processus pour plusieurs exécutions, chaque microVM Firecracker dispose de ses propres ressources noyau virtualisées. Une fonction compromise ou instable chez un client ne peut donc pas affecter les workloads d’un voisin sur la même machine physique, un argument que les équipes qui gèrent elles-mêmes leur infrastructure auto-hébergée connaissent bien sous l’angle inverse : plus l’isolation est forte, moins la supervision doit compenser.
La latence médiane des Edge Functions de Netlify passe de 25-40 millisecondes à 5-6 millisecondes, sans aucune modification de code côté développeur.
Ce que Netlify prépare ensuite
En contrôlant désormais l’ensemble du cycle de requête, Netlify indique vouloir faire sortir le support des paquets npm volumineux de son statut bêta, revoir à la hausse certaines limites d’exécution, et gérer directement le routage réseau plutôt que de dépendre d’un prestataire tiers pour cette étape.
Ce qu’il faut retenir
Le passage aux microVM Firecracker réduit fortement la latence médiane des Edge Functions Netlify sans exiger de migration côté développeur. L’essentiel du bénéfice vient de la suppression d’un saut réseau vers un service d’exécution externe, désormais internalisé.
Ce genre d’annonce mérite d’être lu avec un peu de recul sur les chiffres fournis par l’éditeur lui-même : une division par quatre ou cinq de la latence médiane est un résultat remarquable, mais il vaut la peine d’être revérifié en conditions réelles avant de l’intégrer dans un argumentaire commercial. Ce qui compte davantage ici, c’est la logique de fond : les plateformes d’edge computing rapatrient progressivement des briques qu’elles sous-traitaient encore il y a deux ans, signe que le marché est en train de se consolider autour de quelques architectures maison. — Simon Janvier
Pour aller plus loin : le billet technique de Netlify, « 5x faster Edge Functions: from V8 isolates to Firecracker MicroVMs ».
