Utiliser les DevTools dans le panneau
L’attention va à l’aperçu multi-appareils. Ce qui fait cesser de basculer vers le navigateur, ce sont les DevTools en dessous.
Simulator Panel intègre console, réseau et stockage, aux côtés du profilage de performance et d’accessibilité. La plupart des gens utilisent l’aperçu d’appareils et n’ouvrent jamais ces outils — dommage, car ils répondent précisément aux questions que l’aperçu soulève.
Le réseau d’abord, toujours
Quand une page dérape à une largeur et pas à une autre, l’onglet réseau tranche en quelques secondes. Vous cherchez deux choses : une requête qui a échoué silencieusement, et une requête partie deux fois.
C’est la seconde qui surprend. Un composant qui se re-rend au redimensionnement redemande souvent, et le seul endroit où cela se voit est un panneau réseau avec deux lignes identiques. La page continue de marcher, donc personne ne s’en aperçoit avant la facture ou la limite de débit.
La console à chaque largeur, pas à une seule
Les erreurs ne sont pas indépendantes de la largeur. Une mise en page qui s’effondre à un petit point de rupture peut lever une erreur là où le bureau n’en lève pas : une mesure qui renvoie zéro, un élément pas encore dans le DOM à cette taille.
Lisez donc la console spécifiquement dans l’aperçu du petit téléphone. C’est celui qu’on saute, et c’est là que les erreurs se concentrent.
Le stockage, pour le bug qui n’arrive qu’à vous
L’outil de stockage clôt le « chez moi ça marche ». La moitié de ces cas est une valeur périmée dans le stockage local venant d’un build antérieur : un drapeau de fonctionnalité, un jeton en cache, une bannière fermée qui ne reviendra jamais.
Videz et rechargez avant de passer une heure sur un bug qu’aucun nouveau visiteur ne verra.
Le profilage à faire une fois
Avant un lancement, lancez le profilage performance et accessibilité à la plus petite largeur que vous supportez. Pas en bureau : c’est sur le petit téléphone qu’une page lourde devient vraiment lente et que les cibles tactiles échouent.
Une réserve à dire clairement : cela mesure la page dans votre navigateur, sur votre machine. Cela parle de la page, pas d’un Android de quatre ans dans un train. Considérez un bon score comme nécessaire, pas suffisant.
Questions fréquentes
Pourquoi vérifier la console à plusieurs largeurs ?
Les erreurs ne sont pas indépendantes de la largeur. Une mise en page qui s’effondre à un petit point de rupture peut lever une erreur là où le bureau n’en lève pas : mesure renvoyant zéro, élément pas encore dans le DOM à cette taille.
Comment repérer une requête dupliquée ?
L’onglet réseau montre deux lignes identiques. Les composants qui se re-rendent au redimensionnement redemandent souvent ; la page continue de marcher et personne ne le voit avant une limite de débit ou une facture.
Un bon score de profilage suffit-il avant le lancement ?
Non. Il mesure la page dans votre navigateur sur votre machine. Il est nécessaire mais pas suffisant : un vrai téléphone d’entrée de gamme sur un vrai réseau est le test qu’il ne remplace pas.
