Analyse des performances de la version publiée

Cette page rassemble les éléments probants relatifs au nettoyage de mai 2026 concernant les performances, la taille du paquet, les dépendances et le fichier shrinkwrap d’OpenClaw. Elle constitue le complément technique du billet de blog public. Deux audits sont regroupés ici :

• Analyse des performances des versions : versions GitHub de v2026.5.28 jusqu’à la version stable v2026.4.23, à l’aide du workflow OpenClaw Performance, avec profile=smoke et le parcours de fournisseur simulé. La plupart des lignes de versions utilisent un seul échantillon ; les lignes v2026.5.27 et v2026.5.28 utilisent les derniers artefacts de branche de version répétés trois fois.
• Contexte antérieur d’avril : mesures de référence publiées de clawgrit-reports avec fournisseur simulé, de v2026.4.1 à v2026.5.2, utilisées uniquement pour éviter de considérer les versions défectueuses de fin avril comme référence publique de performances.
• Analyse de l’empreinte d’installation : installations propres avec npm install --ignore-scripts dans des paquets temporaires, avec du -sk node_modules pour la taille et un parcours de node_modules pour compter les instances de paquets.
• Analyse de la taille du paquet npm : npm pack openclaw@<version> --dry-run --json pour les versions publiées, avec relevé de la taille de l’archive compressée, de la taille décompressée et du nombre de fichiers.

​

Vue d’ensemble

Couverture des performances : 77 versions demandées, 74 points étayés par des artefacts et 3 exécutions CI indisponibles. Dernier point stable mesuré : v2026.5.28.

​

Modifications apportées dans la version 5.28

Le nettoyage effectué entre v2026.5.27 et v2026.5.28 a réduit le graphe d’installation par défaut sans supprimer les fonctionnalités elles-mêmes.

​

Chiffres clés

N’utilisez pas les lignes défectueuses de fin avril comme références publiques de performances. v2026.4.23 et v2026.4.29 constituent des éléments utiles pour analyser les régressions, mais les écarts importants de type 14x décrivent principalement le rétablissement après une mauvaise série de versions. Pour le récit du blog, utilisez la référence publiée du début avril comme ordre de grandeur. La référence est v2026.4.14, issue de l’exécution avec fournisseur simulé publiée dans clawgrit-reports (trois répétitions ; cette exécution a échoué uniquement parce que la chronologie de diagnostic n’a pas été produite, de sorte que les médianes à froid, à chaud et de RSS restent utiles comme ordre de grandeur approximatif). Considérez-la comme un contexte narratif, et non comme une statistique servant de critère de validation des versions. Dans l’analyse de mai, la dernière ligne de branche de version a évolué de manière significative par rapport à v2026.5.2 : Par rapport à la version stable précédente :

​

Empreinte d’installation

​

Taille du paquet npm

2026.5.12 constitue le jalon visible de l’extraction des plugins dans le journal des modifications : Amazon Bedrock, Bedrock Mantle, Slack, le bac à sable OpenShell, Anthropic Vertex, Matrix et WhatsApp ont été retirés du chemin de dépendances du cœur, afin que leurs ensembles de dépendances soient installés avec ces plugins plutôt qu’avec chaque installation du cœur.

​

Résumé des tours de l’agent Kova

La série stable d’avril raconte deux histoires différentes. Le début avril était lent, mais reconnaissable. La fin avril s’est transformée en véritable précipice de régression. v2026.5.2 est la première version où le parcours avec fournisseur simulé descend dans la plage de 3 à 5 secondes et commence à réussir régulièrement dans l’analyse fournie. Contexte publié antérieur : Analyse fournie :

​

Sondes du code source

Les sondes du code source ont été ignorées pour 17 anciennes références réussies, car ces arborescences de code source ne disposaient pas encore des points d’entrée requis pour les sondes. Les mesures de tours d’agent existent néanmoins pour ces références. Points représentatifs des sondes du code source : Le pic de santé de la CLI dans v2026.5.22 est visible dans ce tableau, même si le parcours de tours d’agent a tout de même réussi. Conservez les sondes du code source lors de l’analyse de régressions ciblées de la CLI ou du Gateway.

​

Audit de l’empreinte d’installation

Les échantillons de dépendances utilisent une version stable par mois, ainsi que l’événement d’introduction du shrinkwrap dans 2026.5.22 et la dernière version 2026.5.28.

​

Limite du shrinkwrap

La version 2026.5.20 a été publiée sans shrinkwrap racine ni arborescence volumineuse de dépendances OpenClaw imbriquées. La version 2026.5.22 a introduit le shrinkwrap racine et installé 911.8MB sous le répertoire imbriqué openclaw/node_modules. La version 2026.5.28 conserve le shrinkwrap et installe toujours 259.7MiB sous le répertoire imbriqué openclaw/node_modules, mais n’installe plus aucun paquet @napi-rs/canvas lors de l’audit local d’une nouvelle installation. L’inspection des archives tar publiées confirme cette limite : Distinction importante : le shrinkwrap lui-même n’est pas le problème. La version v2026.5.28 inclut toujours le shrinkwrap racine. Le problème résidait dans la structure du paquet, qui conduisait npm à matérialiser une volumineuse arborescence de dépendances OpenClaw imbriquées ainsi que les 12 paquets de plateforme @napi-rs/canvas. L’arborescence imbriquée est plus petite dans v2026.5.28, et l’ensemble des plateformes Canvas n’apparaît plus dans l’audit local. Pour une explication accessible du shrinkwrap et des vérifications de paquets destinées aux responsables de maintenance, consultez shrinkwrap npm.

​

Interprétation pour la chaîne d’approvisionnement

Le nombre de dépendances est une métrique de sécurité opérationnelle, et pas seulement une métrique de taille d’installation. Chaque paquet élargit l’ensemble des responsables de maintenance, des archives tar, des mises à jour transitives, des binaires natifs facultatifs et des comportements lors de l’installation auxquels les opérateurs doivent faire confiance. La démarche de nettoyage consiste à :

• maintenir les fonctionnalités lourdes et facultatives hors de l’installation par défaut du cœur
• faire en sorte que les paquets de Plugin possèdent leur propre graphe de dépendances d’exécution
• éviter toute réparation par le gestionnaire de paquets à l’exécution pendant le démarrage du Gateway
• préserver la reproductibilité des installations sans provoquer la matérialisation de paquets natifs pour toutes les plateformes
• maintenir les scripts d’installation désactivés dans les parcours d’acceptation et de mesure des paquets
• détecter les arborescences de dépendances imbriquées et les explosions de dépendances natives facultatives avant la publication

Documentation associée :

• Résolution des dépendances des Plugins
• Inventaire des Plugins
• Validation complète d’une version