Cold start WebAssembly : ce que les benchmarks disent vraiment (et ce qu’on ne peut pas encore affirmer)

Le cold start est redevenu un axe de différenciation commerciale entre runtimes WebAssembly, pas seulement un sujet de recherche académique. Wasmer en fait un argument de vente explicite avec une fonctionnalité nommée Instaboot, présentée comme une réponse directe au problème du démarrage à froid.

Ce réflexe rappelle exactement la dynamique déjà documentée dans notre article sur la méthodologie de benchmark backend : plusieurs fournisseurs concurrents affichent des chiffres de performance sur leur propre page produit, sans toujours préciser le protocole qui les a produits. Un chiffre de cold start sans méthode ne prouve rien de plus qu’un chiffre de latence sans méthode.

Un cold start n’est pas une seule opération : c’est une somme de phases distinctes, et deux fournisseurs ne mesurent pas forcément les mêmes phases sous le même nom.

Un chiffre qui ne compte que l’instanciation d’un module déjà chargé et déjà compilé en mémoire aura mécaniquement l’air meilleur qu’un chiffre qui inclut le chargement réseau et la compilation. Aucun des deux n’est faux en soi : le problème apparaît quand on les compare sans préciser lequel des deux a été mesuré.

Nous ne reprenons volontairement aucun chiffre précis tiré de ces publications dans cet article. Sans avoir revérifié en détail la méthodologie de chaque papier au moment de l’écriture, republier un nombre isolé reproduirait exactement le problème que cet article documente : un chiffre sans le contexte qui permettrait de savoir ce qu’il mesure vraiment.

Ce que cette variance apprend, en revanche, est directement utile : un cold start dépend fortement du contexte de mesure, exactement comme le rappelle la discipline de parité d’environnement décrite dans notre article de méthodologie générale (matériel identique, même région, même état de cache pour tous les systèmes comparés).

Pour le détail architectural complet entre les deux runtimes les plus souvent opposés dans les discussions serverless, voir notre comparatif dédié Wasmtime vs Wasmer.

Ce que cet article ne fait pas, en revanche, c’est reprendre un chiffre de performance affiché sur la page produit Wasmer. Sans savoir quel matériel, quelle charge de travail et quel protocole de mesure ont produit ce chiffre, le republier commettrait exactement l’erreur documentée plus haut : traiter un chiffre marketing comme un résultat de benchmark indépendant.

Aurabase fait tourner ses fonctions Edge sur Wasmtime en production, pas en projet pilote. Voici exactement ce que le dépôt permet d’affirmer, et où s’arrête cette affirmation.

La dépendance est déclarée en dur, avec les features async et cranelift activées, dans les dépendances de production du service, pas dans une dev-dependency ni un commentaire :

# Extrait réel du dépôt
[dependencies]
# WASM Runtime
wasmtime = { version = "43", features = ["async", "cranelift"] }

Ce que ce fichier ne dit pas : aucun chiffre de cold start mesuré selon le protocole décrit dans notre méthodologie de benchmark n’existe aujourd’hui dans le dépôt pour ce runtime. Tant qu’une mesure datée, avec percentiles, matériel et charge de travail disclosés, n’a pas été publiée, aucun chiffre Aurabase ne doit être cité comme une caractéristique mesurée du produit. Pour l’architecture générale de la plateforme, voir notre article pilier architecture Rust d’Aurabase. Pour une comparaison concrète entre cold start WASM et cold start conteneur, indépendante de la question méthodologique traitée ici, voir notre article dédié WASM vs conteneurs.

1. Quelles phases sont incluses ? Chargement réseau, validation, compilation, instanciation, premier appel : un chiffre qui n’en compte qu’une partie n’est pas comparable à un chiffre qui les compte toutes.
2. Le module était-il vraiment « froid » ? Un module déjà en cache mémoire ou disque ne teste pas la même chose qu’un module chargé pour la première fois.
3. Compilation JIT ou artefact précompilé (AOT) ? Les deux stratégies ont des coûts de démarrage structurellement différents.
4. Chiffre unique ou distribution ? Un meilleur run sur dix n’a pas la même valeur qu’un p95 sur mille exécutions.
5. Matériel et région précisés ? Un chiffre sans spécification matérielle ne peut pas être reproduit par un tiers.
6. Comparaison à charge et topologie égales ? Comparer un runtime auto-hébergé à un service managé sans le signaler fausse la lecture.
7. Date et version du runtime testé ? Un chiffre non daté sur un projet qui évolue vite ne veut plus rien dire au bout de quelques mois.