Publié le 4 avril 2025
Pour résoudre les problèmes de performances dans le monde réel, vous devez combler l'écart entre votre environnement de développement et les différentes expériences de performances de vos utilisateurs. Dans cet article, nous allons examiner les nouvelles fonctionnalités de Chrome DevTools qui vous aident à baser davantage vos décisions de débogage des performances sur des données réelles plutôt que sur des suppositions.
Calibrer les attentes
À partir de Chrome 134, les outils pour les développeurs incluent le calibrage du forçage du processeur, un nouvel outil qui permet de choisir le bon niveau de forçage du processeur sans incertitude. Exécutez la calibration une fois, et DevTools générera des préréglages de limitation pour les appareils mobiles bas de gamme et milieu de gamme, spécifiques à votre ordinateur de développement.
Un problème courant dans le travail sur les performances Web est que, en tant que développeurs, nous créons souvent des sites sur des ordinateurs rapides, alors que de nombreux utilisateurs utilisent des appareils mobiles plus modestes. Il peut être difficile de détecter un problème de performances lorsqu'il ne se produit que sur un appareil doté d'un processeur beaucoup plus lent.
Le débogage à distance sur un véritable appareil mobile est la norme, mais depuis près de dix ans, Chrome est également compatible avec le throttling du processeur pour des cycles d'itération rapides et légers pendant le développement.
Mais quel niveau de limitation du processeur devez-vous choisir ? 4 x ? 20 x ? Comment savoir quelle taille correspond le mieux au type d'appareils que vous savez consulter votre site ? Et en quoi la vitesse de votre propre machine change-t-elle cette décision, que vous utilisiez une station de travail haut de gamme ou un Chromebook de huit ans sur la route ?
Processus de calibrage du débit
Lorsque le panneau "Performances" est ouvert, les paramètres de l'environnement comportent une liste déroulante permettant de définir le niveau de limitation du processeur. Si vous n'avez jamais effectué de calibrage, deux options sont désactivées sous "Préparérages calibrés " dans le menu déroulant, et une option Calibrer s'affiche tout en bas.
Vous serez alors redirigé vers les préréglages de limitation du processeur dans Paramètres (vous pouvez également y accéder directement).
- Cliquez sur le bouton Calibrer.
- Cliquez sur Continuer lorsqu'il vous avertit qu'il va quitter brièvement la page actuelle.
- Un benchmark rapide est exécuté pour mesurer la vitesse de votre machine actuelle. L'étalonnage est terminé.
Les options d'étranglement sont désormais renseignées avec les préréglages calibrés pour les appareils de bas et moyen de gamme.
Ces deux préréglages devraient suffire pour la plupart des cas d'utilisation de développement. Nous recommandons généralement le préréglage "moyen", car il correspond à un appareil mobile "typique" sur le Web. Si vous savez que de nombreux utilisateurs disposent d'appareils encore plus lents ou qu'un problème de performances ne se produit généralement que pour ces utilisateurs, l'option "bas de gamme" doit être suffisamment lente pour couvrir même la longue traîne des appareils d'entrée de gamme.
Enfin, si vous pensez que l'étalonnage a mal fonctionné ou que votre machine locale a changé d'une manière ou d'une autre, vous pouvez toujours réétalonner l'étalonnage via le menu déroulant de la limitation ou dans les paramètres. Le benchmark sera alors réexécuté et les préréglages mis à jour.
Fonctionnement du lissage du processeur dans DevTools
Si vous vous êtes déjà demandé comment fonctionne la limitation du processeur dans DevTools, sachez que le principe est relativement simple. Lorsque vous activez le débit limité pour un onglet, Chrome lance un thread de limitation distinct qui interrompt et suspend le thread principal de l'onglet pour de courtes rafales fréquentes. L'objectif est de suspendre le thread principal suffisamment longtemps au total pour que la durée de toute tâche donnée augmente en fonction du facteur de limitation.
Par exemple, avec un étranglement du processeur de 4 fois, le thread principal sera suspendu environ 75% du temps, ce qui fait que toute tâche du thread principal prend quatre fois plus de temps à être effectuée.
L'avantage de cette approche est qu'elle est presque transparente pour le reste de Chrome. Aucun code spécialisé n'est nécessaire pour ralentir JavaScript, la mise en page ou chacun des nombreux autres types de tâches qu'un navigateur doit effectuer. Toutes les tâches effectuées sur le thread principal prennent plus de temps, car le thread lui-même n'est autorisé à s'exécuter que pendant une fraction du temps.
Lorsque le forçage du processeur se comporte comme un véritable appareil mobile
Par conséquent, de nombreux types de tâches mobiles liées au processeur sont bien simulés par la limitation du processeur. Si une interaction déclenche JavaScript et la mise en page, par exemple, il y a de fortes chances que l'exécution soit très similaire à celle sur un appareil mobile.
Prenons l'exemple d'une tâche déclenchée par un clic sur un bouton, qui exécute JavaScript pour ajouter de nouveaux éléments au DOM, ce qui oblige le navigateur à exécuter des calculs de style et de mise en page pour positionner le nouveau contenu:
Avec le préréglage de limitation du processeur "mobile de milieu de gamme" étalonné (3,7 fois sur cette machine de développement), l'interaction semble très similaire, mais la durée augmente considérablement, ce qui devient une tâche longue:
Tester la même interaction sur un appareil de niveau intermédiaire réel à l'aide du débogage à distance donne un résultat remarquablement similaire, tant au niveau de la forme que de la durée de la trace de l'interaction. Étant donné que cette tâche est principalement liée au processeur dans le thread principal (exécution du code JavaScript de la page et du code de style et de mise en page de Chrome), le débit limité calibré recrée précisément les performances réelles sur mobile:
Quand vous souhaitez quand même effectuer des tests sur un véritable appareil mobile
Bien qu'il soit très utile, le forçage du processeur ne peut pas simuler tous les aspects du matériel mobile. Sur un téléphone, la vitesse du disque est plus lente, la bande passante de la mémoire est plus limitée et la régulation thermique peut s'activer à tout moment pour réduire la vitesse d'exécution.
Une limitation courante de l'étranglement concerne les tâches nécessitant une utilisation intensive du GPU. Les GPU mobiles et les GPU pour ordinateurs de bureau diffèrent d'un point de vue architectural, et Chrome exécute les opérations GPU dans un processus distinct du thread principal de la page. Par conséquent, le contrôle de la consommation du processeur par les outils pour les développeurs n'affecte pas le processus GPU (ce qui est préférable, car cela aurait un impact sur la réactivité des outils pour les développeurs eux-mêmes et sur le reste du navigateur).
La peinture, le compositing et le style basé sur de nombreux effets sont des problèmes de performances courants qui peuvent sembler acceptables sur une machine de développement, mais ralentir de manière inattendue sur mobile. Il peut être difficile de s'apercevoir qu'il existe un problème lorsque vous essayez de le recréer sur votre machine de développement.
Prenons la même interaction qu'auparavant (cliquer et ajouter de nombreux éléments au DOM). Cette fois, les nouveaux éléments sont stylisés avec un nombre excessif d'ombres portées et de filtres de floutage qui sollicitent le GPU.
La forme et la durée de début de l'interaction sont similaires, mais il y a une nouvelle peinture de thread principal longue à la fin pour les effets ajoutés:
Sur un téléphone de milieu de gamme réel, la partie du thread principal de l'interaction ressemble beaucoup à celle simulée, y compris la peinture supplémentaire, mais un processus GPU sauvage semble effectuer une quantité énorme de travail avant que le résultat de l'interaction puisse s'afficher à l'écran:
Le travail du GPU prolonge l'interaction de 300 millisecondes supplémentaires. Il s'agit d'un travail qui n'existe presque pas pour le GPU de l'ordinateur portable, même si le contrôle de la fréquence d'horloge du processeur (thread principal) est activé.
Il existe d'autres cas où l'émulation présente des inconvénients importants, comme les chargements de pages à dépendances profondes, où il existe une interaction entre le débit réduit simulé du réseau, les communications inter-processus et l'accès aux caches de disque et de mémoire.
Veillez toujours à tester votre application sur de vrais appareils mobiles à un moment donné. Si vous ne parvenez pas à recréer en laboratoire sur votre ordinateur de bureau un problème qui, selon vos données sur le terrain, affecte les utilisateurs mobiles, essayez de faire du débogage à distance avec un appareil réel pour voir s'il existe une différence que vous avez manquée.
Autres améliorations du débogage basées sur les données
D'autres nouvelles fonctionnalités ont récemment été lancées pour vous aider à baser plus facilement les paramètres et les décisions de débogage sur vos utilisateurs réels.
Si les données de champ sont activées, le panneau Performances vous donnera des suggestions sur le débit limité en fonction des utilisateurs du 75e percentile, comme mesuré par le rapport d'expérience utilisateur Chrome (CrUX). La vue des métriques en temps réel vous avertira si vos métriques mesurées localement diffèrent des données de champ. Nous avons abordé ce sujet en détail dans un post précédent sur l'importation de données Core Web Vitals réelles dans DevTools.
Les insights du panneau "Performances" dans la barre latérale vous avertissent désormais également si les métriques mesurées dans une trace ne correspondent pas à ce que vos utilisateurs vivent dans le monde réel.
Si vous activez les données de terrain, vous pourrez également utiliser le 75e percentile des Core Web Vitals pour déterminer l'ordre dans lequel les insights s'affichent dans la barre latérale. Par exemple, si vos utilisateurs ont généralement un excellent LCP (Largest Contentful Paint), mais un INP (Interaction to Next Paint) médiocre, les insights qui aident à améliorer l'INP seront généralement en haut de la liste.
Enfin, si vous avez déjà basculé entre plusieurs traces ou chargé des traces à partir d'un disque, il peut être difficile de vous souvenir exactement des paramètres d'émulation mobile et de limitation que vous avez utilisés dans chaque trace. Le menu déroulant de sélection de la trace en haut du panneau Performances affiche désormais des informations d'émulation pour chaque trace.
Arrêter, calibrer et écouter
En fin de compte, nous devons baser nos décisions de débogage sur le monde réel: en commençant par les données sur le terrain issues des analyses et des rapports des utilisateurs pour identifier les problèmes, puis en recréant ces expériences utilisateur en laboratoire pour les diagnostiquer. Ces nouvelles fonctionnalités DevTools devraient vous aider à simplifier ce processus.
Le calibrage du lissage du processeur et les alertes sur les divergences entre les expériences sur le terrain et en laboratoire vous aident à déterminer si vous êtes sur la bonne voie et à obtenir une approximation plus cohérente des performances réelles. En éliminant les conjectures de la configuration et en mettant en évidence les écarts potentiels, DevTools vise à vous aider à consacrer plus de temps à la résolution des problèmes de performances réels qui affectent vos utilisateurs.
Avez-vous des idées d'améliorations ou des suggestions de nouvelles fonctionnalités ? N'hésitez pas à nous le dire !