Deux heures. 1 738 modifications. Ce qui a été testé.

#De vraies modifications, dans de vrais navigateurs

Le test a duré 7 201 secondes et appliqué 1 738 modifications JavaScript et CSS. Quatre onglets Chromium ont utilisé des applications de test App Router et Pages Router. Des erreurs de syntaxe volontaires ont interrompu la séquence 28 fois pour vérifier la récupération.

Les contrôles conservaient un marqueur de document et l’état des composants : une simple réponse HTTP 200 ne suffisait pas. Le scénario vérifiait aussi l’ordre des réponses en streaming et l’accès au cache après la réponse HTTP.

Le scénario comprenait aussi 175 appels de Server Actions. Chaque réponse devait correspondre à la génération attendue de l’application, plutôt que réussir uniquement au niveau HTTP. Après la réparation d’une erreur de syntaxe, la page devait redevenir utilisable sans réinitialiser l’état des onglets sans rapport.

Quatre onglets, avec conservation du document et de l’état des composants. 28 récupérations après des erreurs de syntaxe forcées. 174 vérifications de streaming et 174 vérifications de tâches en arrière-plan et de cache. Aucune erreur de page enregistrée par le navigateur.

#Mesurer tous les processus du service

L’arbre de processus mesuré incluait Node.js, esbuild et le service Rust. Le pic de mémoire proportionnelle observé était de 536,51 Mio. La croissance entre les fenêtres définies de régime stable était de 59,05 Mio, avec dix processus au maximum lors des relevés.

Ces mesures sont restées dans les budgets du test. Elles décrivent cette application, cette méthode d’échantillonnage et cette machine. Elles ne constituent ni une exigence mémoire universelle ni une preuve qu’aucune fuite ne puisse exister.

Mesurer uniquement le service natif masquerait le coût des workers JavaScript et des outils de compilation. La mémoire proportionnelle traite aussi les zones partagées autrement qu’une somme de mémoires résidentes. Le pic et la croissance en régime stable doivent donc rester associés à leur méthode lors d’une comparaison.

#Préciser exactement la version testée

Le test de deux heures utilisait un code figé avant l’ajout final de la protection des frontières .mts/.cts. Les fichiers modifiés étaient en JavaScript et JSX. La protection finale a passé des tests distincts de régression, de packaging et de plateforme, ainsi qu’un essai plus court sur quatre onglets.

Un moniteur auxiliaire de rétention des fichiers a aussi connu une interruption de 25 minutes. Les contrôles principaux du navigateur et de mémoire ont continué. Il faut conserver cette limite dans le rapport plutôt que prétendre à une observation continue qui n’a pas eu lieu.

La distinction entre les versions testées compte particulièrement pour une correction de sécurité. La protection ajoutée ensuite possède ses propres résultats de régression et de cycle de vie, mais ils ne changent pas rétroactivement le code exécuté pendant deux heures. Conserver les deux traces permet de comprendre la portée exacte de chaque résultat.

#Ce que ces résultats permettent de conclure

Sur ce scénario Linux x64, les modifications répétées, la récupération et les budgets de ressources ont tenu. Windows x64 a fait l’objet de validations distinctes de packaging, de cycle de vie et de navigateur. Des tests séparés vérifient aussi la conservation d’état des composants anonymes et les nouvelles réponses des Server Actions.

Il ne valide pas macOS ou ARM64, ne remplace pas les tests de votre application et ne démontre pas de nouveau gain face à Next.js. Ce sont d’autres questions, qui nécessitent d’autres mesures.

Pour vérifier votre application, gardez plusieurs pages représentatives ouvertes, utilisez-les avant de modifier le code et introduisez une erreur de syntaxe volontaire avant de la corriger. Observez les erreurs du navigateur et les processus du service en plus du temps de compilation. Le contrôle porte ainsi sur la continuité du travail, plutôt que sur l’actualisation la plus rapide.