Résolution des problèmes de performances courants
Les utilisateurs attendent des pages interactives et fluides. Chaque étape du pipeline de pixels représente une opportunité d’introduire jank (interruptions de rendu). Découvrez les outils et les stratégies permettant d’identifier et de résoudre les problèmes courants qui ralentissent les performances du runtime.
Résumé
N’écrivez pas de code JavaScript qui force le navigateur à recalculer la disposition. Séparez les fonctions de lecture et d’écriture, puis effectuez les lectures en premier.
Ne compliquez pas trop votre CSS. Utilisez moins de CSS et gardez vos sélecteurs CSS simples.
Évitez autant que possible la disposition. Choisissez CSS qui ne déclenche pas du tout la disposition.
La peinture peut prendre plus de temps que toute autre activité de rendu. Attention aux goulots d’étranglement de peinture.
JavaScript
Les calculs JavaScript, en particulier ceux qui déclenchent des modifications visuelles importantes, peuvent bloquer les performances de l’application. Ne laissez pas javascript mal chronoéré ou de longue durée d’interférer avec les interactions utilisateur.
JavaScript : Outils
Prenez un enregistrement dans l’outil Performance et recherchez les événements suspects longs Evaluate Script
.
Si vous remarquez un certain nombre d’interruptions de rendu (jank) dans votre code JavaScript, vous devrez peut-être passer à un niveau supérieur et collecter un profil de processeur JavaScript. Les profils d’UC indiquent où l’exécution est passée dans les fonctions de votre page. Découvrez comment créer des profils d’UC dans Accélérer le runtime JavaScript.
JavaScript : Problèmes
Le tableau suivant décrit certains problèmes JavaScript courants et des solutions potentielles.
Problème | Exemple | Solution |
---|---|---|
Gestionnaires d’entrée coûteux affectant la réponse ou l’animation. | Défilement tactile, parallaxe. | Laissez le navigateur gérer les interactions tactiles et les défilements, ou liez l’écouteur le plus tard possible. Consultez Gestionnaires d’entrée coûteux dans la liste de contrôle des performances d’exécution de Paul Lewis. |
JavaScript mal chronoté affectant la réponse, l’animation, la charge. | L’utilisateur défile juste après le chargement de la page, setTimeout/ setInterval. | Optimiser le runtime JavaScript : utilisez requestAnimationFrame , répartissez la manipulation DOM sur les trames, utilisez des workers web. |
JavaScript de longue durée affectant la réponse. | L’événement DOMContentLoaded se bloque car il est submergé par le travail JS. | Déplacez le travail de calcul pur vers web Workers. Si vous avez besoin d’un accès DOM, utilisez requestAnimationFrame . |
Scripts garbage-y affectant la réponse ou l’animation. | Le garbage collection peut se produire n’importe où. | Écrire moins de scripts garbage-y. Consultez Garbage Collection in Animation in Paul Lewis’s runtime performance checklist. |
Style
Les modifications de style sont coûteuses, en particulier si ces modifications affectent plusieurs éléments dans le DOM. Chaque fois que vous appliquez des styles à un élément, le navigateur détermine l’impact sur tous les éléments associés, recalcule la disposition et repeints.
Style : Outils
Prenez un enregistrement dans l’outil Performance . Vérifiez l’enregistrement pour les événements volumineux Recalculate Style
(affichés en violet).
Sélectionnez un Recalculate Style
événement pour afficher plus d’informations le concernant dans le volet Détails . Si les changements de style prennent beaucoup de temps, il s’agit d’un résultat de performance. Si les calculs de style affectent un grand nombre d’éléments, il s’agit d’un autre domaine qui peut être amélioré.
Pour réduire l’impact des événements, réduisez l’utilisation Recalculate Style
des propriétés CSS qui déclenchent la disposition, la peinture et le composite. Ces propriétés ont le plus grand impact sur les performances de rendu. Pour plus d’informations, consultez Conserver les propriétés Compositor-Only et Gérer le nombre de couches
Style : Problèmes
Le tableau suivant décrit certains problèmes de style courants et des solutions potentielles.
Problème | Exemple | Solution |
---|---|---|
Calculs de style coûteux affectant la réponse ou l’animation. | Toute propriété CSS qui modifie la géométrie d’un élément, comme la largeur, la hauteur ou la position ; le navigateur vérifie tous les autres éléments et recalcule la disposition. | Éviter les css qui déclenchent des dispositions |
Sélecteurs complexes affectant la réponse ou l’animation. | Les sélecteurs imbriqués forcent le navigateur à tout savoir sur tous les autres éléments, y compris les parents et les enfants. | Référencez un élément dans votre CSS avec une seule classe. |
Disposition
La disposition (ou redistribuation dans Firefox) est le processus par lequel le navigateur calcule les positions et les tailles de tous les éléments d’une page. Le modèle de disposition du web signifie qu’un élément peut en affecter d’autres. par exemple, la largeur de l’élément <body>
affecte généralement les largeurs des éléments enfants, et ainsi de suite, jusqu’au haut et au bas de l’arborescence. Le processus peut être très impliqué pour le navigateur.
En règle générale, si vous demandez une valeur géométrique à partir du DOM avant qu’un cadre ne soit terminé, vous allez vous retrouver avec des « dispositions synchrones forcées », ce qui peut être un goulot d’étranglement important en matière de performances si elles sont répétées fréquemment ou effectuées pour une grande arborescence DOM.
Disposition : Outils
Le volet Performances identifie quand une page provoque des mises en page synchrones forcées. Ces Layout
événements sont marqués avec des barres rouges.
Le « thrashing de disposition » est une répétition de conditions de disposition synchrones forcées. Cela se produit lorsque JavaScript écrit et lit à partir du DOM à plusieurs reprises, ce qui force le navigateur à recalculer la disposition encore et encore. Pour identifier le thrashing de disposition, recherchez un modèle de plusieurs avertissements de disposition synchrones forcés. Consultez la figure précédente.
Disposition : Problèmes
Le tableau suivant décrit certains problèmes de disposition courants et des solutions potentielles.
Problème | Exemple | Solution |
---|---|---|
Disposition synchrone forcée affectant la réponse ou l’animation. | Forcer le navigateur à effectuer la disposition plus tôt dans le pipeline de pixels, ce qui entraîne des étapes répétées dans le processus de rendu. | Commencez par traiter par lot votre style, puis effectuez les écritures. |
Thrashing de disposition affectant la réponse ou l’animation. | Boucle qui place le navigateur dans un cycle lecture-écriture-lecture-écriture-écriture, forçant le navigateur à recalculer la disposition encore et encore. | Traitement par lot automatique des opérations de lecture-écriture à l’aide de la bibliothèque FastDom. |
Peinture et composite
La peinture est le processus de remplissage des pixels. Il s’agit souvent de la partie la plus coûteuse du processus de rendu. Si vous avez remarqué que votre page ne fonctionne pas comme prévu, il est probable que vous ayez des problèmes de peinture.
La composition est l’endroit où les parties peintes de la page sont rassemblées pour être affichées à l’écran. Pour la plupart, si vous vous en tenez aux propriétés compositrices uniquement et que vous évitez complètement la peinture, vous devriez remarquer une amélioration majeure des performances, mais vous devez watch en cas de nombres de couches excessifs.
Peinture et composite : Outils
Pour connaître la durée de la peinture ou la fréquence de la peinture :
Dans DevTools, dans l’outil Performance , cliquez sur le bouton Paramètres de capture (
») et cochez la case Activer l’instrumentation de rendu avancée .
Prenez un enregistrement.
Si la plupart de votre temps de rendu est consacré à la peinture, vous rencontrez des problèmes de peinture. Pour plus d’informations, consultez Activer l’instrumentation de rendu avancée dans Référence des fonctionnalités de performances.
Peinture et composite : problèmes
Le tableau suivant décrit certains problèmes courants liés à la peinture et aux composites, ainsi que des solutions potentielles.
Problème | Exemple | Solution |
---|---|---|
Orages de peinture affectant la réponse ou l’animation. | Grandes zones de peinture ou peintures coûteuses affectant la réponse ou l’animation. | Évitez la peinture, promouvez les éléments qui se déplacent vers leur propre couche, utilisez des transformations et l’opacité. |
Explosions de couches affectant les animations. | La surpromotion d’un trop grand nombre d’éléments avec translateZ(0) affecte considérablement les performances de l’animation. |
Effectuez une promotion en couches avec parcimonie, et seulement quand vous savez qu’elle offre des améliorations tangibles. |
Remarque
Certaines parties de cette page sont des modifications fondées sur le travail créé et partagé par Google et utilisées conformément aux conditions décrites dans la licence internationale 4,0 d’attribution créative. La page d’origine est disponible ici et est créée par Kayce Basques (Rédacteur technique, Chrome DevTools & Lighthouse) et Meggin Kearney (Rédacteur technique).
Cette œuvre est concédée sous licence creative commons attribution 4.0 international.
Commentaires
https://aka.ms/ContentUserFeedback.
Bientôt disponible : Tout au long de 2024, nous allons supprimer progressivement GitHub Issues comme mécanisme de commentaires pour le contenu et le remplacer par un nouveau système de commentaires. Pour plus d’informations, consultezEnvoyer et afficher des commentaires pour