Lorsque les équipes évaluent les plateformes sans serveur, elles parlent généralement des démarrages à froid comme si chaque fonction était de la même forme. Ce n'est pas le cas. Un processus Node.js qui démarre un runtime plus grand et un arbre de dépendances est une machine différente d’un runtime isolé qui commence avec une surface API plus petite et beaucoup moins de frais généraux de processus.
C'est pourquoi les isolats V8 semblent souvent rapides en périphérie. Ils ne font pas de magie. Ils partent d'un modèle plus étroit.
Pourquoi les isolats V8 démarrent plus vite
Un runtime isolé est mieux adapté lorsque la logique de requête est éphémère et principalement légère en CPU :
- vérifications d'authentification et de bot
- réécriture d'en-têtes et de cookies
- attribution A/B
- routage géographique
- lectures de fonctionnalités
Une forme typique de middleware de périphérie ressemble à ceci :
export default async function middleware(request: Request) {
const country = request.headers.get("x-country") ?? "unknown";
const bucket = country === "DE" ? "eu-homepage" : "global-homepage";
return new Response(null, {
status: 307,
headers: {
Location: `/${bucket}`,
},
});
}
Cette logique bénéficie d'un démarrage rapide, d'un placement global et de faibles frais généraux par requête. Elle n'a pas besoin de modules Node natifs, d'accès au système de fichiers local ou d'une longue fenêtre d'exécution.
Ce que vous abandonnez
Le compromis est réel :
- moins d'APIs spécifiques à Node
- limites d'exécution plus restrictives
- moins de tolérance pour les dépendances lourdes
- plus de friction si vous avez besoin de modules natifs ou de travaux en arrière-plan longs
Cela signifie que les runtimes isolés ne sont pas un remplacement universel pour les fonctions sans serveur traditionnelles. Si la charge de travail implique le traitement d'image, la génération de PDF, les navigateurs sans interface ou l'accès à des données complexes, un runtime complet est souvent un meilleur choix même si les démarrages à froid sont plus élevés.
La règle pratique
Utilisez des isolats lorsque la requête est proche de la périphérie du réseau et que la logique métier est petite, déterministe et sensible à la latence. Utilisez un runtime plus complet lorsque le gestionnaire nécessite des capacités de plateforme plus larges.
Les équipes qui prennent cette décision de manière judicieuse cessent généralement de demander : "Quelle plateforme est la plus rapide ?" et commencent à demander : "Quel modèle d'exécution correspond à ce chemin de requête ?"
Lectures complémentaires