Budget et tests de performance d'une application créative

Mesurer le parcours, pas seulement la page

Les Core Web Vitals restent utiles au chargement et à l'interaction, mais un éditeur doit aussi mesurer ses tâches longues, la latence commande-vers-image/son, la stabilité de cadence, le pic mémoire, les files d'encodage/décodage et la récupération après une session longue.

Scénarios de référence

Démarrage froid puis chaud, ouverture d'un projet petit et d'un projet à la limite annoncée.
Scrub/zoom/déplacement continus pendant calcul, autosave et synchronisation.
Export complet, annulation à mi-parcours et nouvel export sans recharger la page.
Vingt cycles ouvrir/fermer pour révéler les ressources non libérées.
Réseau lent/hors ligne, CPU ralenti, mémoire contrainte et appareil milieu de gamme réel.

Tableau de bord minimal

Temps jusqu'à l'interface utilisable et à la première prévisualisation.
INP/tâches longues du thread principal et temps de traitement Worker.
FPS ou échéances audio ratées selon le produit.
Mémoire JS et compte des ressources natives/GPU lorsque les outils le permettent.
Longueur maximale des queues, trames perdues, temps d'export et taille du projet.
Taux de récupération réussie après fermeture forcée.

Discipline

Capturer une baseline reproductible avant optimisation. Modifier une variable à la fois, conserver appareil, document et scénario identiques, puis enregistrer coût de complexité et gain. Les chiffres de Photopea ou CapCut sont des études de cas propres à leurs moteurs, pas des objectifs transférables.

Gate

Chaque projet fixe ses seuils à partir de l'usage et des appareils cibles. Une fonctionnalité avancée ne passe pas en production si elle améliore la moyenne mais dégrade fortement le pire cas, augmente la mémoire sans plafond ou supprime le repli.