Les frameworks Web tels qu'Angular, React, Vue et Svelte facilitent l'écriture et la maintenance d'applications Web complexes à grande échelle.
Toutefois, ces frameworks introduisent une couche d'abstraction au-dessus du modèle d'application du navigateur. En fait, le code écrit par les développeurs à l'aide de ces abstractions finit généralement par être transpilé en code illisible, minifié et regroupé. Par conséquent, les développeurs peuvent avoir du mal à exploiter pleinement la puissance des outils de développement pour déboguer et profiler ces applications.
Par exemple, lorsque vous profilez une application Angular avec le panneau Performances dans les outils de développement, voici ce qui s'affiche :
Avec ces informations présentées de cette manière, il peut être difficile d'identifier les goulots d'étranglement des performances dans votre code. En effet, il manque le contexte des constructions du framework et une bonne partie des informations affichées est en code minifié. Il est également difficile de faire la distinction entre l'activité directement liée au code que vous avez écrit, les éléments internes du framework et les autres codes tiers pouvant s'exécuter sur la même page.
Les auteurs de frameworks et d'abstractions sont souvent motivés par l'implémentation de leurs propres extensions DevTools, qui présentent les données de profilage en termes de concepts de framework. Ces outils sont très utiles pour déboguer et profiler des applications créées avec un framework spécifique. Toutefois, vous aurez souvent besoin de corréler les données du framework dans le profileur de votre framework avec les informations sur l'exécution du navigateur dans le panneau Performances des outils pour les développeurs. Le fait que ces deux sources de données soient présentées séparément dans des outils indépendants rend difficile l'identification et la résolution des goulots d'étranglement, en particulier lorsque l'application devient plus complexe. Voici un exemple de visualisation de profil dans le profileur Angular DevTools :
Dans l'idéal, les développeurs disposeraient d'une vue dans laquelle les deux sources de données sont affichées ensemble dans le même contexte, mappées sur la même timeline.
C'est pourquoi nous avons collaboré avec l'équipe Angular pour intégrer les données d'exécution Angular directement dans le panneau Performances à l'aide de l'API d'extensibilité du panneau "Performances". Dans cet article, nous allons examiner les possibilités offertes par l'API et la façon dont elle a été utilisée dans le framework Angular pour y parvenir. L'implémentation peut servir d'exemple pour d'autres frameworks et abstractions qui souhaitent améliorer leur expérience de développement en instrumentant leurs propres outils et en aidant les développeurs à utiliser les outils pour les développeurs Chrome.
Qu'est-ce que l'API d'extensibilité du panneau "Performances" ?
L'API vous permet d'ajouter vos propres entrées de timing à la trace du panneau Performances, dans la même chronologie que le reste des données du navigateur. Deux mécanismes vous permettent de le faire :
- API User Timing
- L'API
console.timeStamp
API User Timing
Vous pouvez utiliser performance.mark et performance.measure pour ajouter les entrées comme suit :
// Mark used to represent the start of some activity you want to measure.
// In this case, the rendering of a component.
const renderStart = performance.now();
// ... later in your code
performance.measure("Component rendering", {
start: renderStart,
detail: {
devtools: {
dataType: "track-entry",
track: "Components",
color: "secondary",
properties: [
["Render reason", "Props changed"],
["Priority", "low"]
],
}
}
});
La piste Composants sera alors ajoutée à votre timeline avec la mesure suivante :
Cette API vous permet d'ajouter des entrées au tampon Performance timeline, tout en les affichant dans l'UI du panneau Performances des outils de développement.
En savoir plus sur cette API et l'objet devtools dans la documentation
L'API console.timeStamp
Cette API est une alternative légère à l'API User Timing. En reprenant l'exemple précédent, vous pourriez avoir :
// Mark used to represent the start of some activity you want to measure.
// In this case, the rendering of a component.
const renderStart = performance.now();
// ... later in your code
console.timeStamp(
"Component rendering",
/* start time */ renderStart,
/* end time (current time) */ undefined,
/* track name */ "Components",
/* track group name */ undefined,
/* color */ "secondary"
);
Cette API fournit une méthode performante pour instrumenter les applications : contrairement à l'alternative User Timing API, elle ne crée pas de données mises en mémoire tampon. Cette API ajoute exclusivement des données au panneau **Performances** des outils de développement. Cela signifie que lorsque les outils de développement n'enregistrent pas de trace, les appels à l'API sont des no-ops (ils ne font rien), ce qui les rend beaucoup plus rapides et adaptés aux chemins chauds sensibles aux performances. Le choix d'utiliser des arguments positionnels au lieu d'un objet contenant tous les paramètres de personnalisation permet également de maintenir l'API aussi légère que possible.
Découvrez comment utiliser console.timeStamp pour étendre le panneau "Performances" et les paramètres que vous pouvez transmettre dans la documentation.
Comment Angular a intégré l'API d'extensibilité des outils de développement
Nous allons voir comment l'équipe Angular a utilisé l'API d'extensibilité pour s'intégrer aux outils pour les développeurs Chrome.
Éviter la surcharge avec console.timestamp
L'instrumentation d'Angular avec l'API d'extensibilité du panneau Performances est disponible à partir de la version 20. Le niveau de précision souhaité pour les données de performances dans les outils de développement nécessite une API rapide. La demande d'extraction (60217) qui a ajouté l'instrumentation a donc choisi d'utiliser l'API console.timeStamp. Cela empêche les performances d'exécution de l'application d'être affectées par la surcharge potentielle de l'API de profilage.
Données instrumentées
Pour donner une bonne idée du code Angular qui s'exécute et de la raison pour laquelle il s'exécute, plusieurs parties des pipelines de démarrage et de rendu sont instrumentées, y compris :
- Amorçage de l'application et des composants.
- Création et mise à jour de composants.
- Exécution des écouteurs d'événements et des hooks de cycle de vie.
- et bien d'autres (par exemple, la création de composants dynamiques et le rendu différé des blocs).
Codes couleur
Un code couleur permet d'indiquer au développeur la catégorie dans laquelle se trouve une entrée de mesure donnée. Par exemple, les couleurs utilisées pour les entrées marquant l'exécution du code TypeScript créé par le développeur sont différentes de celles utilisées pour le code produit par le compilateur Angular.
Dans la capture d'écran suivante, vous pouvez voir comment cela se traduit par des points d'entrée (comme la détection des modifications et le traitement des composants) en bleu, du code généré en violet et du code TypeScript (comme les écouteurs d'événements et les hooks) affiché en vert.
Notez que l'argument de couleur transmis à l'API n'est pas une valeur de couleur CSS, mais un jeton sémantique qui est mappé à une couleur correspondant à l'interface utilisateur des outils de développement. Les valeurs possibles sont primary, secondary et tertiary,, avec leurs variantes -dark et -light respectives, ainsi qu'une couleur error.
Titres
Au moment de la rédaction, toutes les données d'exécution Angular sont ajoutées à la même piste (intitulée "🅰️ Angular"). Toutefois, il est possible d'ajouter plusieurs pistes à la trace et même de les regrouper. Par exemple, étant donné les appels suivants à l'API console.timeStamp :
console.timeStamp("Component 1", componentStart1, componentEnd1, "Components", "Client", "primary");
console.timeStamp("Component 2", componentStart2, componentEnd2, "Components", "Client", "primary");
console.timeStamp("Hook 1", hookStart, hookEnd, "Hooks", "Client", "primary");
console.timeStamp("Fetch data base", fetchStart, fetchEnd, "Server", "primary");
Les données sont organisées en pistes de la manière suivante :
L'utilisation de pistes distinctes peut être utile, par exemple, lorsque vous avez une activité asynchrone, plusieurs tâches s'exécutant en parallèle ou simplement des groupes d'activités suffisamment distincts pour être séparés dans différentes zones de l'UI.
Pourquoi est-ce important pour les développeurs Angular ?
L'objectif de cette intégration directe est de fournir une expérience d'analyse des performances plus intuitive et complète. En affichant les données de performances internes d'Angular directement dans le panneau **Performances**, les développeurs bénéficieront des avantages suivants :
- Visibilité améliorée : les événements de performances spécifiques à Angular, tels que le rendu des composants, les cycles de détection des modifications, etc., sont visibles dans la chronologie plus large du navigateur.
- Meilleure compréhension : grâce à des informations riches en contexte sur les processus internes d'Angular, vous pouvez identifier plus efficacement les points faibles en termes de performances.
Activer l'intégration
L'utilisation de l'API d'extensibilité est officiellement disponible dans les versions de développement à partir d'Angular 20. Pour l'activer, vous devez exécuter l'utilitaire global `ng.enableProfiling()` dans votre application ou dans la console DevTools. Pour en savoir plus sur l'intégration, consultez la documentation Angular (https://angular.dev/best-practices/profiling-with-chrome-devtools).
Autres points à prendre en compte
Voici quelques points importants à prendre en compte.
Mappages source et code minimisé :
Les mappages source sont un outil largement adopté qui vise à combler le fossé entre le code regroupé / minifié et son homologue créé.
Les mappages source ne sont-ils pas censés résoudre le problème du code minimisé dans les applications groupées ?
Bien que les cartes sources soient utiles, elles n'éliminent pas complètement les difficultés liées au profilage des applications Web complexes et minimisées. Les mappages source permettent aux outils de développement de mapper le code minimisé à votre code source d'origine, ce qui facilite le débogage. Toutefois, s'appuyer uniquement sur les cartes sources pour l'analyse des performances peut encore présenter certaines limites. Par exemple, il est difficile de choisir la manière dont les éléments internes du framework et le code créé sont séparés visuellement avec les cartes sources seules. L'API d'extensibilité, quant à elle, offre la flexibilité nécessaire pour faire cette distinction et la présenter de la manière que le développeur juge la plus pratique.
Extensions Chrome DevTools :
Les extensions Chrome qui utilisent l'API DevTools sont un outil largement utilisé pour étendre les outils pour les développeurs.
Les profileurs dédiés (par exemple, les extensions Chrome DevTools) sont-ils inutiles ou déconseillés maintenant que cette API est disponible ?
Non, cette API n'est pas destinée à remplacer ni à décourager le développement de profileurs dédiés tels que les extensions Chrome DevTools. Elles peuvent toujours proposer des fonctionnalités, des visualisations et des workflows spécialisés adaptés à des besoins spécifiques. L'API d'extensibilité du panneau Performances vise à intégrer de manière fluide les données personnalisées aux visualisations du navigateur dans le panneau Performances.
La voie à suivre
Perspectives de l'API d'extensibilité.
Utiliser davantage de frameworks et d'abstractions
Nous sommes ravis que d'autres frameworks et abstractions adoptent l'API pour améliorer l'expérience de profilage de leurs développeurs. React, par exemple, a implémenté une adoption expérimentale de l'API pour son framework. Cette instrumentation permet d'afficher le rendu des composants client et serveur, ainsi que les données des API de planification React. Pour en savoir plus et découvrir comment l'activer, consultez la page de React.
Compilations de production
L'un des objectifs de cette API est de fonctionner avec les frameworks et les fournisseurs d'abstraction en général pour adopter et activer l'instrumentation dans les versions de production. Cela pourrait avoir un impact important sur les performances des applications développées avec ces abstractions, car les développeurs pourraient profiler l'application telle que leurs utilisateurs la perçoivent. Nous pensons que l'API console.timeStamp permet d'y parvenir, compte tenu de sa rapidité et de sa faible surcharge. Toutefois, pour le moment, les frameworks expérimentent encore l'API et cherchent à déterminer quels types d'instrumentations sont plus évolutifs et utiles pour les développeurs.