Profilez un parcours client avant de changer le code
Choisissez un itinéraire et une interaction importants, par exemple ouvrir la navigation, filtrer des résultats ou soumettre un formulaire. Enregistrez-le dans le panneau Performance de Chrome DevTools depuis un état de navigateur propre. Répétez l'action et capturez un run avec CPU throttling ainsi qu'un run sur machine de développement ; les traces desktop peuvent masquer du travail perturbateur sur un téléphone moins puissant.
Utilisez la trace pour tester une hypothèse ciblée, pas pour blâmer un composant à partir d'un rapport de bundle. Dans le flame chart principal (Main flame chart), les barres plus larges prennent plus de temps et les barres empilées montrent la pile d'appels. Un triangle rouge sur une Task identifie une long task potentielle ; sélectionnez-la et suivez le lien vers le code initiateur. Sauvegardez les traces avant-après pour des changements significatifs.
Enregistrez juste avant l'action et arrêtez après le résultat visible.
Conservez route, état du compte et séquence d'action constants.
Attribuez chaque coût majeur à l'équipe ou au fournisseur capable de le modifier.
Lisez la trace comme une file de travail
Une tâche longue est un seuil d’investigation, pas un diagnostic complet. La spécification W3C Long Tasks recense les tâches qui durent 50 millisecondes ou plus. Examinez, sous une tâche, l’évaluation de JavaScript, un gestionnaire d’événements, le recalcul des styles, la mise en page ou le rendu. La pile d’appels indique par où commencer ; le minutage montre si le problème vient du code, du rendu ou d’un cadre tiers.
Priorisez les coûts qui se répètent pendant une interaction à valeur. Un handler court peut néanmoins paraître lent s'il déclenche un layout ou attend derrière un travail antérieur. La trace est une mesure de laboratoire : confirmez la correction sur des appareils représentatifs et, lorsque disponible, avec une télémétrie terrain soucieuse de la vie privée.
Le parsing au démarrage exige un remède différent d'un handler post-tap.
Repérez les motifs répétés d'écriture de style et de lecture de layout avant de refactorer.
Joignez la trace, le scénario et les principaux coûts à l'élément de travail.
Envoyez moins de code au moment où ça compte
Inventoriez les scripts par route et par usage. Supprimez les packages inutilisés, les duplicatas, les expériences obsolètes et le code pour des fonctionnalités terminées. Ensuite, découpez les fonctionnalités spécifiques à une route ou rarement utilisées pour qu'elles se chargent quand elles sont nécessaires plutôt que sur le chemin initial. Le chargement dynamique peut réduire le travail de démarrage, mais il peut créer un délai visible lorsque l'utilisateur a besoin de la fonctionnalité immédiatement.
Demandez-vous si un composant a réellement besoin d’un framework complet côté client, si un utilitaire fait doublon avec une capacité existante, ou si du HTML statique complété par une petite amélioration suffit. Testez l’état de repli d’un module chargé ultérieurement. La page doit pouvoir reporter proprement une fonction facultative plutôt que d’afficher une commande inactive.
Documentez quels scripts sont autorisés sur une route et pourquoi.
Envisagez ceci pour éditeurs optionnels, cartes, players ou vues de reporting.
Testez l'authentification, l'accessibilité, le paiement et la complétion de formulaire ; demandez une revue qualifiée quand des contrôles sont affectés.
Découpez le travail pour que le navigateur puisse répondre
Donner des noms à de plus petites fonctions ne crée pas de tâches navigateur séparées quand elles s'exécutent de façon synchrone. Pour une boucle longue, traitez par lots, mettez à jour l'état visible immédiatement, puis cédez la main avant de continuer. Cela permet au navigateur de traiter les entrées et le rendu entre les lots.
Là où c'est pris en charge, scheduler.yield() cède le thread principal et reprend le travail plus tard ; détectez la fonctionnalité et prévoyez un fallback pour les navigateurs non supportés. Ne cédez pas après chaque minuscule opération : cela a un coût et peut augmenter le temps d'achèvement. Choisissez les frontières à partir des mesures, préservez l'annulation et empêchez que des résultats obsolètes remplacent un état plus récent.
Affichez l'acceptation ou la progression avant un travail de suivi non visible.
Cédez avant que le travail mesuré ne devienne long, plutôt qu'une fois par élément.
Les recommandations web.dev actuelles ne préconisent pas une nouvelle stratégie basée sur isInputPending().
Déplacez le calcul, pas l'interface, vers un worker
Un Web Worker exécute un script sur un thread d'arrière-plan séparé du thread d'exécution principal. Il convient pour du parsing coûteux, la transformation de données, l'indexation de recherche et d'autres calculs qui n'ont pas besoin d'accès direct à l'interface. Envoyez une entrée définie, renvoyez un résultat défini, et conservez le rendu et les changements d'état visibles sur le thread principal.
Les workers ne conviennent pas à tous les cas. Ils ne peuvent pas manipuler directement le DOM ni utiliser Window, et la communication par messages copie généralement les données. La création d’un worker, le transfert des données et la coordination des erreurs peuvent coûter plus qu’un petit calcul. Mesurez l’interaction complète, arrêtez les workers devenus inutiles et prévoyez une solution de repli si leur traitement échoue.
Commencez par un calcul dont l'entrée et la sortie peuvent être sérialisées et testées.
Ignorez les résultats générés pour un ancien filtre, une route ou une action.
Communiquez une progression significative via l'interface normale.
Gérez le JavaScript tiers comme une dépendance de production
Analytics, publicité, expériences, embeds sociaux, players vidéo et widgets d'assistance peuvent ajouter des requêtes, de l'évaluation JavaScript, des iframes et des dépendances. Un script fournisseur peut être nécessaire, mais il échappe au contrôle direct de l'équipe applicative et peut affecter performance, confidentialité, sécurité et continuité. Inventoriez son objectif, les routes, la condition de chargement, l'approbateur, l'exigence de consentement et le propriétaire de la suppression.
Lorsque les conditions et les contrats le permettent, comparez une page représentative avec et sans une origine tierce. Les outils de performance peuvent révéler une évaluation coûteuse, des charges utiles importantes et l’attribution de tâches longues. Ne conservez une intégration légère ou différée que si sa valeur documentée justifie son coût mesuré. Vérifiez que le contenu essentiel et la transaction principale fonctionnent lorsqu’une dépendance facultative est lente ou indisponible.
Chargez un tag seulement sur les routes et conditions qui en ont besoin.
Incluez les changements du tag-manager dans la revue performance, confidentialité, sécurité et rollback.
Documentez et testez comment désactiver une intégration non critique.
Faites de la réactivité un garde-fou de release
Transformez la trace gagnante en une petite vérification de régression pour le parcours important. Définissez les interactions couvertes, la contrainte d'appareil ou de CPU, la réponse attendue et le réviseur. Associez-la à une revue d'inventaire des bundles et des tiers pour qu'un nouveau package ou tag ne puisse pas réintroduire silencieusement du travail sur le thread principal.
Status Is UP utilise cette preuve pour l'optimisation proactive et la remédiation sûre, pas pour remplacer la supervision de disponibilité en production. Avant un changement à haut risque, préparez le rollback et vérifiez le parcours critique après la mise en production. Les résultats varient selon l'appareil, le réseau, le navigateur, le contenu et l'état du compte ; considérez les seuils comme des garde-fous, pas des garanties.
Exigez des traces avant-après pour la navigation partagée, le checkout, la recherche ou les gros bundles.
Connaissez le feature flag, le réglage du tag ou la version de déploiement qui restaure le comportement connu comme bon.
Re-profilez après des releases majeures, des changements de fournisseurs ou des évolutions de la répartition des appareils.