Mesurer les performances du navigateur avec User Timing API
Mesurez des parcours applicatifs maîtrisés, interprétez le bruit et conservez uniquement les données nécessaires.
BotBrowser Team
Vous voulez la documentation structurée pour Plateforme ?
Cet article fait partie de la bibliothèque éditoriale. Pour les étapes de configuration, la référence et les mises à jour continues, passez directement à la section docs.
User Timing API permet à une application de nommer des points de son propre travail et de mesurer l'intervalle entre eux. Elle répond à une question bornée comme « combien de temps la validation du paiement a-t-elle pris dans cette version ? ». Ce n'est ni un benchmark d'appareil ni un signal d'identité. Une mesure utile part d'un résultat visible, place ses limites là où l'application peut les expliquer et n'enregistre que les champs nécessaires à la décision.
Marques et mesures
performance.mark(name) inscrit un point nommé sur la chronologie du document. performance.measure(name, startMark, endMark) crée un intervalle entre deux marques. Choisissez des noms stables décrivant une étape visible, par exemple search-submit-start, results-visible et payment-validation-complete.
performance.mark('cart-submit-start');
try {
await validateCart();
performance.mark('cart-submit-end');
performance.measure('cart-submit', 'cart-submit-start', 'cart-submit-end');
} finally {
performance.clearMarks('cart-submit-start');
performance.clearMarks('cart-submit-end');
}
La spécification W3C User Timing Level 3 définit les entrées et MDN documente les méthodes. Détectez les fonctions, gérez une marque absente ou une opération refusée et gardez la tâche principale utilisable. Utilisez try/finally pour nettoyer les chemins réussi, échoué et annulé; donnez aux travaux concurrents un nom propre afin qu'un composant ne supprime pas les marques d'un autre.
Mesurer des parcours maîtrisés
Commencez par le parcours et son résultat d'acceptation. Pour une recherche, mesurez l'envoi jusqu'aux résultats visibles, puis séparez requête, analyse et rendu seulement si chaque intervalle éclaire une décision. Gardez Navigation Timing, Resource Timing et User Timing distincts: une marque applicative ne prouve pas la durée réseau ou serveur.
Marquez les limites que votre équipe contrôle. Si un widget tiers termine l'étape, décrivez cette limite comme une observation. Conservez annulation et nouvelle tentative et utilisez un petit fixture id, jamais le contenu de page ou un identifiant de compte.
L'artefact concret est le fixture copiable ci-dessus et le tableau suivant. Il couvre succès, erreur, annulation, API absente et achèvement tardif. Le résultat attendu est une page utilisable, une mesure bornée seulement quand les deux marques existent et aucune marque conservée après nettoyage.
| Résultat | Enregistrer | Action visible |
|---|---|---|
| Deux marques présentes | une durée et un label d'exécution | continuer |
| API indisponible | measurement-unavailable | continuer sans mesure |
| Validation échouée | état et durée bornée si possible | afficher l'erreur et réessayer |
| Annulation utilisateur | état annulé, aucune durée inventée | conserver la saisie et arrêter |
| Achèvement obsolète | ignorer si l'exécution est périmée | garder la vue actuelle |
BotBrowser peut exécuter des parcours autorisés dans des contextes contrôlés et comparer des résultats visibles sur une configuration déclarée. Il ne rend pas le travail applicatif déterministe, ne modifie pas la spécification et ne certifie pas qu'une durée représente l'appareil d'une personne.
Minimiser les données
Collectez seulement le nom de mesure, une durée agrégée ou par classe, le label de version, le fixture id et le résultat. Évitez URL, requêtes, texte, comptes et historique durable. Avant l'export, définissez le système destinataire, le groupe autorisé, la durée de conservation et le chemin de suppression. Même sans texte, des événements répétés reliés par des horodatages ou d'autres enregistrements peuvent décrire une session. Si la décision ne demande pas un diagnostic par exécution, agrégez avant le transfert. Limitez le diagnostic à la fenêtre de l'incident ou du test, fixez son expiration, puis supprimez la clé de liaison et la trace détaillée. Utilisez un identifiant court durant cette fenêtre puis faites-le expirer. Exportez une liste autorisée et nettoyez les entrées; ne combinez pas les marques avec d'autres propriétés du navigateur pour profiler.
Une précision réduite ou une entrée absente est normale après restauration bfcache, pré-rendu, Service Worker ou changement de visibilité. Étiquetez ces contextes séparément et ne remplacez jamais une valeur absente par une durée « typique » inventée.
Interpréter le bruit
Cache, réseau, charge serveur, ordonnanceur CPU, état de page, version et travail concurrent font varier les distributions. Comparez le même fixture, la route, la version et la fenêtre; utilisez percentiles et effectifs, pas une moyenne unique. Un p95 plus lent avec médiane stable indique peut-être une queue; un déplacement de tous les percentiles peut signaler un changement d'environnement.
Vérifiez d'abord visibilité, conservation de la saisie et nettoyage, puis examinez les agrégats. Ne fixez pas de seuil universel ni de seuil de détection. Timeout, marque absente et promesse rejetée restent des résultats applicatifs avec repli documenté. Rejouez le plus petit fixture et comparez timestamps serveur, ressources, file d'attente et version. User Timing localise une frontière de régression, sans en prouver seul la cause.
Les exécutions simultanées exigent un nom propre à chaque run; un nom global peut associer le mauvais début et la mauvaise fin.
Une promesse rejetée peut manquer la marque finale; gardez l'état d'erreur et nettoyez la marque de début.
Une annulation doit invalider l'exécution avant la suivante afin qu'une réponse tardive ne modifie pas la vue actuelle.
Quand l'API est absente, not-measured n'est pas une durée nulle et le parcours doit continuer.
Le fixture doit déclarer des entrées synthétiques, des attentes bornées et une réinitialisation sans entrées résiduelles.
Avant chaque essai, supprimez seulement les marques dont le préfixe appartient au fixture; ne réinitialisez pas la chronologie d'un autre composant.
Une mesure reproductible n'exige pas une durée identique: elle exige les mêmes transitions et règles de nettoyage.
Décrivez si l'intervalle inclut les reprises, la file, l'animation ou l'attente de rendu, et gardez cette définition stable.
Une marque ne doit pas bloquer l'envoi ni remplacer l'erreur applicative si le nettoyage échoue.
Comparez d'abord le résultat fonctionnel, puis la distribution temporelle pour choisir où enquêter.
Consignez la révision du fixture, la classe de route, la version du navigateur, la fenêtre et le nombre d'échantillons.
Séparez le résumé des diagnostics détaillés et supprimez les identifiants temporaires à la fin de la fenêtre autorisée.
Si le sens d'un label change, commencez une nouvelle série plutôt que de mélanger des intervalles différents.
Un parcours de l'envoi au résultat visible répond à une question produit; il ne dit pas si un appareil est rapide.
L'état superseded explique l'absence d'une mesure sans inventer une durée.
Une entrée absente peut être une preuve utile lorsque le parcours s'est terminé par annulation, erreur ou changement de page.
Liste de lancement
Figez noms, propriétaires des bornes, entrées du fixture, configuration navigateur, fenêtre, agrégation et rétention. Testez support et absence d'API, erreurs, annulation, nouvelle tentative, répétition, localisation et page restaurée. Vérifiez que le nettoyage ne supprime pas les entrées d'un autre composant et inspectez les largeurs bureau et mobile.
La séquence sûre est: définir une question maîtrisée; marquer les limites; mesurer seulement avec les deux points; nettoyer; agréger des exécutions comparables; retenir le minimum d'éléments. Les décisions restent ainsi explicables sans transformer le temps applicatif en mesure clandestine.
Sources publiques
Lectures associées
Articles Connexes
Faites passer BotBrowser de la recherche à la production
Utilisez ces guides pour comprendre le modèle, puis passez à la validation multi-plateforme, aux contextes isolés et au déploiement navigateur prêt pour l'échelle.