Conseils utiles et raccourcis DevTools (Chrome, Firefox, Edge)

À propos de l'auteur

Vitaly Friedman aime les beaux contenus et n'aime pas céder facilement. Quand il n’écrit pas ou ne prend pas la parole lors d’une conférence, il est probablement en train de courir
En savoir plus sur
Vitaly
↬

Parmi tous les outils disponibles au bout de nos doigts ces jours-ci, DevTools est probablement l'un des plus avancés. Au fil des ans, il est devenu un outil de débogage, de profilage, d'audit et même de prototypage – tous vivant dans la même interface, et toujours à un raccourci clavier. Pourtant, DevTools a beaucoup de gemmes obscures et de trésors non découverts, vivant à la lisière des onglets cachés et des paramètres expérimentaux. Corrigeons cela.

Dans cet article, passons en revue certaines des fonctionnalités utiles et obscures de DevTools . Nous examinerons tous les navigateurs modernes (Chrome, Firefox, Edge, Safari) et examinerons les outils utiles qu'ils nous fournissent, développeurs Web. Nous allons nous concentrer sur ceux que nous utilisons fréquemment sur SmashingMag, et sur quelques-unes des petites techniques et stratégies qui nous aident à corriger les bugs embêtants et à écrire un meilleur code.

Création de profils de navigateur

Quand il s'agit de profiler un site Web pour performances, ou suivi d'un problème d'accessibilité particulier, nous créons depuis un certain temps des profils de navigateur distincts pour chaque tâche. Nous travaillons généralement avec au moins 5 profils utilisateur, chacun avec ses propres extensions, signets, signets et fonctionnalités activés ou désactivés. Examinons-les de plus près.

• Profil d'accessibilité
  Un profil de navigateur propre qui comprend divers outils pour vérifier l'accessibilité, par ex. Accessibility Insights ax and a11y.css ainsi que quelques autres linters d'accessibilité et simulateur de vision des couleurs.

• Profil de débogage
  Un profil avec quelques paramètres expérimentaux pour le profilage activés, ainsi qu'une option pour ouvrir automatiquement DevTools à chaque nouvelle fenêtre, avec un CSS de diagnostic personnalisé pour un audit et un profilage rapides.

• Profil de performance
  Un profil propre sans extensions, avec quelques signets spéciaux pour l'audit avec Lighthouse, RequestMap une performance diagnostics CSS et quelques liens relatifs aux performances à garder à l'esprit (par exemple priorité des ressources lors du chargement ). Fonctionne toujours bien avec la limitation du processeur 4 × et la la limitation du réseau (3G lente).

• Client satisfait
  Sur la base des données que nous avons issues de nos analyses, c'est un profil qui est assez proche de celui que beaucoup de nos lecteurs (des gens formidables comme vous) auront. Il contiendra quelques extensions populaires des extensions de développement Web courantes, des bloqueurs de publicité, la gestion des onglets, Google Docs hors ligne, LastPass, VPN, Browserstack, Grammarly, etc. Aucune limitation d'utilisation.

• Un client mécontent [19659012] Un profil pour un lecteur sur une connexion lente et étranglée (3G lente), mémoire faible, CPU pauvre, avec 10 extensions de navigateur les plus populaires activées. Nous utilisons généralement ce profil pour tester nos pages les plus lourdes afin de vivre les pires expériences client possibles.

En fonction de la tâche à accomplir, nous pouvons accéder à l'un des profils dédiés. La commodité réelle vient de la disposition simple que chacun des profils a extensions spécifiques des signets et des paramètres de navigateur tous définis et prêts à l'emploi. Donc, si nécessaire, nous pouvons accéder directement au débogage des performances ou à l'audit d'accessibilité sans aucun problème pour rechercher les bonnes extensions.

Il va sans dire que nous faisons de notre mieux pour garder chaque profil propre et épuré – cela vaut pour les extensions de navigateur comme ainsi que les signets du navigateur, les cookies et le cache.

Raccourcis clavier globaux

Certes, avec la quantité de fonctionnalités disponibles dans DevTools, il n'est pas très surprenant que certaines d'entre elles soient assez difficiles à trouver entre les onglets, les panneaux, les icônes d'engrenage et des points. Cependant, il n'est pas nécessaire de mémoriser l'endroit où ils sont placés. Au lieu de cela, il vaut la peine de se souvenir de quelques raccourcis clavier globaux utiles – ils vous aideront à accéder plus rapidement à des fonctionnalités spécifiques.

• Ouverture du menu de commande (Chrome, Edge)
  Etant probablement l'un des meilleurs- connus, cette commande a en fait deux fonctionnalités. Cmd / Ctrl + Shift + P ouvre une recherche rapide de saisie semi-automatique pour les panneaux, les tiroirs et toutes les fonctionnalités de DevTools. Cmd / Ctrl + P ouvre un tiroir avec tous les fichiers disponibles utilisés sur la page en cours. Si vous avez besoin d'accéder rapidement à une fonctionnalité de DevTools, le menu de commande est un moyen rapide d'y accéder – pour les tiroirs généraux, les menus masqués ou les fonctionnalités spécifiques.

• Ouverture des paramètres de DevTools (tous les navigateurs modernes)
  Généralement là Il existe de nombreux outils et fonctionnalités obscurs cachés dans le panneau "Paramètres" – des périphériques émulés aux profils et expériences de limitation du réseau. Dans Chrome, vous pouvez cliquer sur l'icône d'engrenage dans le coin supérieur droit ou utiliser Shift + ? . Dans Firefox, vous pouvez accéder aux paramètres avec F1 .

• Activer / désactiver le mode Inspecter les éléments (tous les navigateurs modernes)
  Au lieu de cliquer sur une icône Inspecter puis de se concentrer sur l'élément que vous ' Si vous souhaitez déboguer, vous pouvez basculer le mode Inspecter les éléments avec Cmd / Ctrl + Shift + C .

• Basculer le mode HTML (tout navigateurs modernes)
  Lors de l'inspection d'un élément, vous souhaiterez peut-être modifier ses attributs, par exemple classes ou états. Au lieu de cliquer avec le bouton droit de la souris sur l'élément et d'ajouter des valeurs une par une, vous pouvez basculer le mode HTML sur l'élément actuellement sélectionné avec Fn + F2 (ou simplement F2 sous Windows).

• Basculer le mode périphérique (tous les navigateurs modernes)
  Pour passer au mode de la barre d'outils de l'appareil, par ex. pour afficher un aperçu de l'apparence de la maquette sur des écrans étroits ou déclencher un débogueur de requête multimédia, vous pouvez utiliser Cmd / Ctrl + Shift + M dans Chrome , et Cmd / Ctrl + Opt / Alt + M dans Firefox.

Il existe également de nombreux autres raccourcis clavier utiles, par exemple pour interrompre et reprendre l'exécution du script, et passez au crochet correspondant (pour les longues requêtes multimédias et les fonctions JS) dans l'éditeur source.

Vous pouvez trouver un aperçu complet de tous les raccourcis clavier sur Raccourcis clavier Chrome DevTools et Raccourcis clavier de Firefox DevTools – le plus souvent, ils sont assez cohérents dans les navigateurs modernes.

Activer les paramètres expérimentaux

DevTools est fourni avec un ensemble de paramètres expérimentaux qui ne sont pas tout à fait recommandés pour un large public, mais peut en effet être très utile pour le débogage. Un mot d'avertissement cependant: parfois, ces paramètres peuvent geler Chrome ou le rendre assez lent (c'est pourquoi ils sont expérimentaux en premier lieu).

Cependant, avec profils séparés en place, vous pouvez en toute sécurité activez certains de ces paramètres pour chaque profil, puis désactivez-les si nécessaire. Ainsi, alors que nous utilisons nos profils habituels sans que les expériences soient activées pour la navigation occasionnelle, en mode débogage, nous choisissons toujours d'abord un profil dédié, pour éliminer ces bogues un peu plus rapidement.

Avec DevTools ouvert dans Chrome, passez à «Paramètres» ( Shift + ? avec DevTools ouvert) et recherchez «Experiments» dans la barre latérale. De toute évidence, il existe de nombreux paramètres expérimentaux disponibles dans chaque DevTools, mais ceux mentionnés ci-dessous ne sont que ceux que nous trouvons très utiles pour notre travail.

Dans toutes les fonctionnalités répertoriées ici, il vaut la peine d'activer «Automatically pretty print dans le panneau Source »ce qui embellirait les styles et les scripts compressés par défaut lors de l'affichage de la source. Vous pouvez également activer le débogueur CSS Grid et le débogage Flexbox pour traiter les problèmes de mise en page. Il existe également un diff source et un visualiseur d'ordre source qui peuvent être utiles.

Et pour les audits de performance, vous pouvez cocher «Chronologie: initiateurs d'événements» et «Chronologie: suivi d'invalidation» qui afficheront dans le panneau Performances, en mettant en évidence les scripts qui ont entraîné des opérations coûteuses telles que des tâches longues et des recalculs de style. De plus, dans Edge, vous pouvez activer les calques composites en vue 3D.

Pour un profil donné, vous pouvez accéder à plus de fonctionnalités masquées en vous dirigeant vers chrome: // flags / dans le profil de navigateur de votre choix . par exemple, c'est ici que vous pouvez activer les dernières fonctionnalités JavaScript expérimentales les fonctionnalités expérimentales de la plate-forme Web ou activer les conseils de chargement des ressources pour fournir un aperçu des connexions réseau lentes.

Dans Firefox, accédez à Paramètres avec F1 . Au bas du dock, vous pouvez inviter le navigateur à afficher les styles du navigateur, activer / désactiver la saisie semi-automatique CSS, modifier les préférences de l'éditeur, activer le clignotement de la peinture, ajuster le comportement de la capture d'écran et activer les cartes source (non activée par défaut). Dans Safari, vous pouvez trouver les paramètres expérimentaux sous «Développer → Paramètres expérimentaux».

Basculer entre les états du Dock (Chrome, Edge, Firefox)

Certes, le volet d'affichage dans DevTools n'est pas une révélation particulièrement importante. Dans l'onglet «Styles» du dock, les styles apparaissent de haut en bas, classés par leur spécificité CSS. Cependant, une petite chose que nous oublions beaucoup depuis des années est un petit bouton à bascule : hov placé juste au-dessus des styles.

Il vous permet de forcer un état d'élément (: actif : focus : focus-within : hover : visité et : focus-visible et plus récemment : target ) sur un élément interactif particulier – par exemple pour appliquer : focus et : états actifs sur les boutons pour les contrôles d'accessibilité.

Dans Firefox, vous pouvez changer une pseudo-classe pour un élément DOM au fur et à mesure que vous l'inspectez – le Cette fonctionnalité est disponible avec un clic droit sur un nœud DOM.

Une chose qui gêne toujours est la position du dock qui fonctionne parfois mieux sur le côté droit, et parfois en bas – selon l'endroit où votre bogue a envahi votre arborescence DOM.

Pour basculer rapidement entre les états du dock vous pouvez utiliser Cmd / Ctrl + Shift ] + D . Un hic à garder à l'esprit est que le raccourci détachera DevTools dans une fenêtre séparée uniquement si DevTools a été dans sa position par défaut (ancrée à droite). Sinon, le raccourci basculera simplement entre la position par défaut et celle dans laquelle vous l'avez changé.

Affichage à trois volets (Firefox)

Bien que nous puissions être habitués à une vue à deux volets, Firefox fournit un utile ] triple-panes-view par défaut – il est légèrement différent selon les sections. Dans la vue Inspecteur, à côté du HTML et des styles, vous pouvez placer le débogueur de mise en page, afficher les styles de l'ordinateur ou suivre les modifications CSS – il est très utile d'avoir un accès rapide à toutes ces informations sans avoir à basculer entre les onglets.

Chaque fois que vous modifiez des styles dans Firefox, DevTools met en évidence les requêtes multimédias utilisées dans la page avec des sauts rapides vers les sections CSS où un comportement de point d'arrêt est défini. Tout cela est affiché juste à côté du code source, donc pas besoin de rechercher un point d'arrêt spécifique. (Sans parler des styles assez formatés par défaut – c'est pratique!).

Une vue similaire est également disponible dans Chrome et Edge, mais elle n'est disponible que dans le panneau "Éléments" (icône de la barre latérale dans le coin supérieur droit ), et jusqu'à présent, il n'affiche que les styles calculés (c'est pourquoi on l'appelle «Barre latérale des styles calculés»).

Filtrage des styles par propriété (Firefox)

En général, Firefox DevTools est largement sous-estimé. Une autre caractéristique remarquable de Firefox est une option pour filtrer tous les styles par une propriété particulière (indiquée par une icône de filtre). Par exemple, si vous remarquez que certains styles sont remplacés par d'autres dispersés quelque part dans la feuille de style, vous pouvez masquer toutes les définitions qui n'affectent pas cette propriété particulière avec un filtre rapide et voir où se produisent exactement les remplacements.

De plus, sur une page donnée, vous pouvez mettre en évidence toutes les instances qui correspondent à un sélecteur particulier. Par exemple, si vous remarquez un bogue avec le rendu des images de profil sur les sections sombres et claires de la page, vous pouvez mettre en évidence toutes les instances d'une classe particulière sans les rechercher manuellement ou ajouter des styles supplémentaires pour les mettre en évidence. Il suffit de localiser le sélecteur dans le panneau Styles et de choisir une icône cible pour «mettre en évidence tous les éléments correspondant à ce sélecteur».

Dans le panneau "Styles", Firefox explique également quelles propriétés CSS n'affectent pas l'élément sélectionné et pourquoi, ainsi que des recommandations sur ce qui pourrait aider à résoudre le problème ou éviter des imprévus comportement (la fonctionnalité est appelée CSS inactif ).

Une autre fonctionnalité pratique est que Firefox attribue les badges scroll et overflow aux éléments qui provoquent le débordement ou le défilement du conteneur ( ] débogage de débogage ) – très utile lorsque vous essayez de comprendre pourquoi une barre de défilement horizontale apparaît tout d'un coup, ou un élément ne se comporte pas comme prévu.

Extension des nœuds de manière récursive (Chrome, Edge, Firefox)

Lors de l'inspection d'un élément avec un DOM profondément imbriqué, il peut parfois prendre un certain temps pour parcourir l'arborescence, d'un nœud imbriqué à un autre. En cliquant avec le bouton droit sur la flèche sur un nœud, vous pouvez choisir «Développer récursivement» et le nœud actuellement sélectionné (et tous ses enfants) se développera en un seul clic. Vous pouvez également maintenir Option (ou Ctrl + Alt sous Windows) tout en cliquant sur l'icône en forme de flèche à côté du nom de l'élément.

Recueillir et exporter la couverture du code (Chrome, Edge)

Sur une page donnée, une grande partie du CSS et du JavaScript peut ne pas être utilisée du tout, bien qu'elle soit envoyée à le navigateur. Le panneau «Couverture du code» (menu Commande → «Afficher la couverture») vous permet d’explorer les styles et le code qui ne sont pas utilisés sur une page donnée. Nous utilisons la couverture de code pour collecter des CSS critiques pour chacun des modèles utilisés sur le site, et le faire manuellement peut être assez fatigant.

Avec la "Couverture de code" en place, en passant par quelques scénarios qui incluent beaucoup de tapotements, tabulations et redimensionnement de fenêtre, nous exportons également des données de couverture que DevTools collecte en JSON (via l'icône d'exportation / téléchargement). En plus de cela, vous pouvez utiliser Puppeteer qui fournit également une API pour collecter la couverture (mais nous n'y sommes pas encore).

Débogage des requêtes multimédias (Chrome, Edge)

Avec des dizaines de requêtes multimédias en vol pour une page donnée, il peut facilement devenir difficile de suivre les styles remplacés par d'autres styles inclus dans une requête multimédia. Pour trouver la section spécifique de votre fichier CSS qui pourrait provoquer un comportement inattendu, nous pourrions porter notre attention sur le débogueur de requêtes multimédias . Par défaut, il est caché derrière le rouage «Paramètres» dans la barre d'outils de l'appareil, mais c'est en fait très utile lorsqu'il est disponible par défaut.

Basculez la barre d'outils de l'appareil (mode réactif) avec Cmd / Ctrl + Shift + M et choisissez le trois points dans le coin supérieur droit. Choisissez ensuite «Afficher les requêtes multimédias». Vous devriez maintenant pouvoir voir des barres horizontales représentant la portée de chaque requête multimédia .

Elles peuvent sembler un peu déroutantes au début, mais la façon dont ces barres sont alignées représente la largeur de l'écran et est répliquée sur à gauche et à droite de la fenêtre. Les barres les plus proches du centre de l'écran sont écrasées par celles les plus éloignées du centre. La barre bleue en haut indique les requêtes multimédias max-width la verte min-width et max-width les requêtes multimédias, et l'orange représente uniquement Requêtes multimédias de largeur minimale .

Pour toutes les barres, vous pouvez suivre les requêtes multimédias qu'elles contiennent lorsque vous les survolez. Vous pouvez accéder à une plage de requêtes multimédias spécifique et inspecter en détail les problèmes de mise en page avec le panneau Styles ouvert. En cliquant sur n'importe quelle position sur une barre, vous pouvez déclencher des points d'arrêt spécifiques, et si vous cliquez avec le bouton droit sur une barre, vous pouvez révéler sa position dans le code source. En fait, vous pouvez rapidement passer d'une requête multimédia à l'autre, plutôt que de redimensionner manuellement l'écran et de vérifier la largeur de l'écran encore et encore.

En guise de remarque rapide, vous pouvez également spécifier votre émulation personnalisée périphériques au lieu de ceux prédéfinis – en fait, de nombreux préréglages de périphériques sont déjà disponibles. De plus, vous pouvez utiliser le volet «Capteurs» pour contrôler des capteurs de périphérique spécifiques si nécessaire. De plus, dans Firefox, vous pouvez activer et désactiver la simulation tactile et définir un agent utilisateur spécifique, par ex. pour vérifier le comportement de la page avec un moteur de recherche qui demande la page.

Émuler les requêtes de médias de préférence (Chrome, Edge, Firefox)

En plus des requêtes de médias liées à la taille de l'écran, nous pouvons également émuler des requêtes de médias spécifiques à l'accessibilité , par exemple préfère le jeu de couleurs préfère le mouvement réduit et les déficiences visuelles. Pour activer l'émulation, accédez au panneau de contrôle des commandes ( Cmd / Ctrl + Shift + P ) et tapez «Afficher le rendu». Désormais, dans les paramètres, vous pouvez choisir une émulation préférée.

(C'est aussi là que vous pouvez choisir de mettre en évidence les zones à repeindre («Paint Flashing»), les zones qui ont été déplacées («Layout Shift Regions») et le débogage problèmes de performances de défilement.)

Parlant d'émulation: rappelez-vous comment dans le passé vous avez peut-être eu du mal à trouver un bogue de mise en page pour votre feuille de style d'impression? Dans le même panneau, vous pouvez prévisualiser le fonctionnement de vos styles d'impression ici aussi – inutile d'imprimer un PDF d'une page aléatoire encore et encore pour déterminer ce qui a causé un problème de rendu majeur. [19659006] En outre, dans le même panneau de Chrome, vous pouvez ajouter toutes sortes de fonctionnalités de débogage de rendu – par exemple peinture clignotante, bordures des calques, problèmes de performances de défilement, désactivation d'AVIF et de WebP.

En remarque, il existe une option de barre d'outils DevTools pour « Force Dark Appearance » et « Force Print Media styles ”dans Safari, et vous pouvez simuler des déficiences visuelles dans l'onglet“ Accessibilité ”de Firefox. (Nous parlerons un peu plus de l'accessibilité plus tard.) Dans Firefox, la vue d'impression est également disponible au-dessus du volet «Styles» dans le mode «Inspecter».

Ouvrir automatiquement les DevTools dans chaque nouvel onglet (Chrome) [19659003] Avec les audits de performance, nous pourrions vouloir explorer plusieurs pages à la fois, et observer comment elles se comportent avec des DevTools séparés, sans avoir à nous demander quel DevTools est responsable de quelle fenêtre. Pour gagner un peu de temps lors du débogage, vous pouvez créer un raccourci avec une commande Terminal qui ouvrirait un navigateur avec DevTools s'ouvrant automatiquement par défaut dans chaque nouvel onglet.

Pour y parvenir, nous devons passez l'indicateur - auto-open-devtools-for-tabs lors de l'exécution d'un navigateur Chrome basé sur Edge. Nous exécutons un simple script Alfred pour ouvrir le navigateur Canary avec l'indicateur si nécessaire (pointe du chapeau à Addy ) – très utile lorsque vous en avez vraiment besoin:

 / Applications / Google  Chrome  Canary.app / Contents / MacOS / Google  Chrome  Canary --auto-open-devtools-for-tabs htps: //www.smashingmagazine.com 

Vous pouvez trouver un aperçu très complet de tous les commutateurs de ligne de commande Chrome, Edge dans Peter Guide de Beverloo sur Commutateurs de ligne de commande Chrome .

Captures d'écran pleine page (Chrome, Edge, Firefox)

Lors de la sélection d'un nœud HTML dans le volet «Éléments», vous pouvez cliquer avec le bouton droit sur le nœud et invitez les DevTools à créer une capture d'écran de ce nœud, et dans le «Mode réactif», vous pouvez capturer une capture d'écran de la partie visible de la page ou une capture d'écran en taille réelle (trois points dans le coin supérieur droit).

Pour créez une capture d'écran pleine taille un peu plus rapidement, vous pouvez également afficher une «Capture d'écran pleine page» dans le menu de commande ( Cmd / Ctrl + Shift + P → «Capture d'écran pleine page»). En général, c'est un peu plus rapide. Gardez simplement à l'esprit que les parties de la page qui sont chargées paresseusement ou rendues progressivement (par exemple avec content-visibilité ) peuvent ne pas s'afficher correctement dans la capture d'écran, vous devrez peut-être faire défiler tout le chemin vers le bas

Dans Firefox, vous pouvez générer une capture d'écran de la partie visible de la page en allant d'abord dans le mode «Device Toolbar», puis en repérant l'icône de la caméra dans le coin supérieur droit et en activant il. Ou pour une capture d'écran pleine page, vous devez d'abord basculer «Prendre une capture d'écran de la page entière» dans «Paramètres», puis vous trouverez l'icône de la caméra dans la barre d'outils DevTools.

Règles pour les composants (Chrome , Edge, Firefox)

Vous aimeriez peut-être vérifier rapidement la largeur et la hauteur d'une image ou d'un spot publicitaire. Mais plutôt que de prendre une capture d'écran ou d'inspecter l'élément et de copier / coller les valeurs de largeur et hauteur vous pouvez utiliser des règles pour mesurer la taille d'un composant. Les règles sont fournies dans tous les navigateurs modernes, mais Firefox DevTools vous permet également de mesurer une partie de la page . Vous pouvez trouver l'outil de mesure sur le côté droit de DevTools, juste à côté de l'icône «Mode réactif».

Suivi des modifications (Chrome, Edge, Firefox)

Lors du débogage d'un problème particulier, vous avez peut-être commenté certaines lignes de code et ajouté probablement un nouveau code qui semble résoudre le problème pour de bon. Vos modifications doivent maintenant être répliquées dans les fichiers source réels. Pour ce faire, il n'est pas nécessaire de collecter manuellement toutes les modifications que vous avez apportées à tous vos fichiers.

Dans Chrome, activez la commande "Modifications locales" lors de la modification du fichier source. Vous devriez voir un suivi des modifications apparaître dans le panneau ci-dessous. S'il est réduit, retirez-le en le faisant glisser verticalement. Le volet met en évidence les propriétés modifiées et ce qui a exactement changé, vous pouvez donc copier-coller les modifications immédiatement.

Une chose à garder à l'esprit est que c'est probablement une bonne idée de suivre les modifications lors de l'exécution de votre serveur local – sans suppression automatique des sauts de ligne et des espaces car ils apparaîtront comme des modifications ainsi que. Ce problème n'existe pas dans Firefox, où vous pouvez également trouver un volet «Modifications» qui fait la même chose, ainsi qu'un bouton convivial «Copier toutes les modifications».

Remplacements locaux (Chrome, Edge)

Vous avez peut-être déjà été dans cette situation: vous voulez juste expérimenter quelques changements, mais vous pourriez avoir peur de frapper accidentellement «Actualiser» dans le navigateur pour perdre toutes les modifications apportées à la page. Peut-être que vous ne pouvez pas vraiment exécuter le site localement ou peut-être que vous ne voulez tout simplement pas exécuter votre compilation entière pour quelques modifications locales mineures. Dans de tels cas, les «remplacements locaux» de Chrome peuvent être une aubaine.

Commencez par créer un dossier sur votre ordinateur où toutes vos modifications locales seront stockées ( local-overrides sur Desktop semble être un nom et un lieu raisonnables pour ce genre de tâche). Ensuite, dirigez-vous vers l'onglet «Sources» et choisissez «Remplacements» dans le coin supérieur gauche de DevTools (il peut être caché derrière un double chevron). Cliquez maintenant sur "Sélectionner le dossier pour les remplacements" et choisissez votre dossier fraîchement créé – c'est le dossier que Chrome utilisera pour stocker vos modifications locales. Vous devrez cliquer sur «Autoriser» pour accorder à Chrome les autorisations d'enregistrement des fichiers sur votre disque dur.

Vous pouvez maintenant choisir n'importe quel fichier dans le panneau «Sources», cliquer avec le bouton droit n'importe où dans le code et choisir «Enregistrer pour les remplacements» avec le clic droit. C'est un indice pour que Chrome crée un nouveau fichier et stocke tout le contenu du fichier, ainsi que vos modifications, sur votre disque dur. (Vous pouvez d'abord cliquer sur le bouton {} pour rendre le code un peu plus lisible). ( Merci à Trys pour l'indication! )

Une fois que vous avez défini vos remplacements locaux, Chrome intercepte les requêtes réseau et utilise votre code au lieu de la réponse réelle. Il surveillera également les modifications apportées au fichier et injectera automatiquement les changements dans la page tout comme si vous aviez un développement local installé avec le mode veille activé. Tous les fichiers écrasés par des remplacements locaux auront un petit point violet à côté d'eux dans le panneau «Éléments».

La ​​meilleure partie : maintenant vous pouvez ouvrir le fichier dans votre éditeur de texte et y apporter des modifications tout en voyant ces modifications apparaître également dans DevTools – et si vous devez passer à DevTools pour ajouter des points d'arrêt, vous pouvez le faire à partir de DevTools, apporter des modifications au code, et ces modifications seront également visibles dans votre éditeur de texte. Presque magique!

Conseil de pro de Harry Roberts : Les remplacements locaux ne vous permettent pas de conserver ou de suivre des versions ou des variantes, mais vous pouvez joindre une requête string à l'URL et chargez des variantes distinctes de la même page. Extrêmement utile lors de l'édition de pages HTML.

Ah, et si vous avez besoin de désactiver à nouveau les remplacements locaux, cochez simplement «Activer les remplacements locaux» dans le même volet – sinon les styles remplaceront les styles existants encore et encore, ce qui est quelque chose you might not want.

Remote Debugging (Chrome, Safari)

If you need to debug your apps or pages on a mobile phone, you can use a Devtools proxy for iOS devices to debug Chrome on iOS, and also use DevTools to debug Mobile Safari on iOS with Chrome DevTools.

To debug Mobile Safari with Safari Inspectorenable “Web Inspector” in “Settings → Safari → Advanced → Web Inspector” and open the debugger with “Develop” → (Your phone's name). You should have Safari’s DevTools opening up for you.

For Android devices, open the Developer Options on Android and select “Enable USB Debugging”. On your development machine, you can then discover your mobile device by going to chrome://inspect#devices and choosing your “Remote Target”. You can find plenty of details and instructions on “Get Started With Remote Debugging Android Devices”. That’s also where you can find a dedicated DevTools for Node.js debugging.

Pause Script Execution (Chrome, Edge, Firefox)

When testing critical CSS or debugging JavaScript, you might want to hold on to the state of the DOM before a particular script gets executed or a particular style gets applied. That’s what DOM change breakpoints in DevTools are for.

By right-clicking on the three ominous dots next to the element’s name, you could pick “Break on” subtree modifications (node insertions and removals in the DOM tree rooted at the given node), attribute modifications (e.g. when an attribute is added or removed, or an attribute value changes — e.g. with classes) or node removal.

However, you can also use a conditional line-of-code breakpoint when you know the exact region of code that you need to investigate, but you want to pause only when some other condition is true. Plus, not to forget logpoints to output a value in a code snippet without writing console.log over and over again.

Code Snippets (Chrome, Edge)

If you have a couple of code snippets that you use often to track what might have caused the buggy behavior, you can store and access these snippets in the “Snippets” pane. In a way, these JavaScript snippets are similar to bookmarklets, but unlike the latter, you can manage them from the convenience of a dedicated area in DevTools.

Because they are scripts, we can add breakpoints when these scripts are running, or select portion of your code inside “Snippets” and run that particular portion of the code instead of executing the entire snippet.

The “Snippets” pane is located among “Sources”, next to “Local Overrides”. Once you’ve added a snippet, you can run it either by right-clicking and selecting “Run”, or with Cmd/Ctrl + Enter. Of course, each snippet is available from the Command Panel as well.

In general, if you find yourself running a routine task over and over again, there is a good chance that you might want to place it in “Code Snippets” and automate this task with a script. DevTools Snippets includes some useful scripts for cache busting, showing headers and saving objects as .json files from the console, but you could use it to modify the DOM or display any useful information, such as performance marks (which is what we do). Plus, you could also plug in a performance diagnostics CSS to indicate lazy-loaded images, unsized images or synchronous scripts.

Run Custom Automated Tests (Safari)

One of the often forgotten features in Safari DevTools is the option to define and run a series of automated checks. Think of it as a custom-built testing suitewith a series of small tests, which can be fully defined based on the type of audit a developer would like to run. By default, the test suite is focused around accessibility, but you can adjust it as you see fit, e.g. in order to check if there are any sync scripts in the DOM, or if all of the images have a defined width and height attribute, or even if all images are lazy-loaded. (thanks, Nikita!)

Source Maps (Chrome, Edge, Firefox)

When debugging production code, it’s extremely handy to be able to track down the changes to a specific component or module that you use in your code base. To map minified code to source code, we can use source maps. If you generate a source map as a part of your build, you can use source maps while debugging your code in DevTools.

In Chrome, you need to enable source maps for JavaScript and CSS in “Settings”, and then add a folder to “Workspace”. DevTools with then try to infer all mappings automatically and load your source files in addition to your minified ones. You can then read and debug compiled code in its original source. Even better than that: you can still walk through your breakpoints, and all errors, logs and breakpoints will map to the actual code. To build out your source map, Webpack’s Devtool might help.

For Firefox, once the source map is generated, a transformed file has to include a comment that points to the source map. Just make sure that your bundler does the job for you. Once it’s in place, in the source list pane, the original source (.scss or .ts files) will appear, and you can debug it right there.

Clear Service Worker’s Cache And Storage (Chrome, Edge)

When we hit “Hard Refresh” in the browser, the browser will not use anything from the cache when reloading the page. Instead, it will re-fetch all assets from the server, without relying on caching.

If you right-click the “Refresh” button with DevTools open, you’ll find another option: “Empty Cache and Hard Reload”. The difference is that if the page prompts any dynamic fetches via JavaScript, they might still use the cache. The latter option clears them, too, while the former doesn’t.

Both of these options, however, don’t clear cookie or service worker’s cache — which you might want to do in some scenarios. Jump to the Command menu (Cmd + Shift + P) and type/autocomplete “Clear site data”. When this option is activated, the browser will clean all of the data (as the name assumes), including the service worker’s cache as well as the unregistering of the service worker. (Alternatively, you can click “Clear Site Data” in the Application panel.)

And if you want to delete only cache or only cookies quickly, you can right-click on any request in the “Network” panel, and choose “Clean browser cache” from there.

In Firefox, you’ll need to head to the “Privacy & Security” panel and find the “Cookies and Site Data” section there.

Filters In The Network Panel (Chrome, Edge, Firefox)

There seems to be not much to explore in the “Network” panel as it basically just shows the list of browser requests (along with server responses) in chronological order. However, there are plenty of obscure little helpers as well.

First of all, with an overview of requests in front of us, we can choose which columns we’d like to see. Right-click on the header of one of the columns and select the ones that you find useful for the task at hand. We always choose the “Priority” column to see in which priorities assets are being requested, and if we need to adjust that order to deliver critical assets faster (based on JavaScript Resource Loading Priorities in Chrome, Edge).

We can also filter requests to find specific ones that might be causing trouble (thanks for the tip, Harry). At the top of the “Network” panel you’ll find an input field, which accepts not only keywords but also commands for filtering. Here are a few examples of the useful ones:

• is:from-cache shows all resources that were delivered from the cache,
• is:service-worker-initiatedshows only requests prompted by a service worker,
• is:running shows all incomplete or unresponsive requests,
• larger-than:250k shows all resources that are larger than 250 Kb,
• -larger-than:250k shows all resources that aren’t larger than 250 Kb (same size and smaller),
• mixed-content:shows all assets that are loaded over HTTP instead of HTTPS,
• -has-response-header:Cache-Control highlights assets that don’t have any caching headers,
• Obviously we can also search for bad practices like document.write and @import in HTML and CSS, plus we can use regular expressions as well.

All filters can be combined as well, separated by an empty space. You can check a comprehensive list of all filters as well, or just type - in the filters input and get an autocomplete preview of all features (huge thanks to Harry for the tip!).

Check Initiators In The Network Panel (Chrome, Edge)

If you want to quickly check which assets a particular resource has requested, or by which resource an asset was requested, there is a simple way to discover it in DevTools as well. This is especially useful in cases where you might have a couple of third-party scripts that might be calling fourth-party-scripts.

When you are inspecting a request in the “Network” panel, hold Shift while hovering over an element. The pink background color will indicate resources that this element has prompted to download, and the green background color will indicate the initiator that actually prompted the request.

Choose a User Agent (Chrome, Edge, Firefox)

Sometimes you might want to check how the page will render with a different user agent, e.g. to make sure that a Googlebot gets a properly rendered version of the page. By heading to “Network conditions”, you can define the behavior for caching, network throttling and a user agent.

By default, the latter is “automatic” but there are 10 predefined groups, ranging from GoogleBot Desktop and Mobile to Android and UC Browser. You can also define your own user agent if you need to. However, these settings will not remain preserved as you navigate from one tab to another.

In Firefox, you’ll need to head to Firefox’s about:config page and define a general.useragent.override string.

Change Scrolling Behavior In The Performance Panel (Chrome, Edge)

At first glance, the Performance panel might appear quite daunting with its flame chartsplenty of data displayed at once, and quite non-conventional scrolling behavior. By default, regular vertical scrolling acts as zooming into a selected portion of the timeline, but we can change it.

In “Settings”, you can switch “Flamechart mouse wheel action” from “Zoom” to “Scroll” — and voilà, your preferred scrolling will be preserved! But what if you wanted to use both zooming and scrolling though? The key hint there is to hold “Shift” while scrolling to toggle the preferred behavior.

Making Sense Of The Performance Panel (Chrome, Edge)

Remember “Timeline: event initiators” and “Timeline: invalidation tracking” we mentioned in the Experimental settings? These experimental features come in handy in the Performance panel when you are looking for a cause of expensive operations — so-called Long tasks (tasks that take over 50ms to complete). The goal then is to break down Long tasks into shorter tasks, and usually it makes sense to focus on the longest Long tasks first.

Jump to the Performance panel and start profiling with Cmd/Ctrl + Shift + E. After a bit of time needed for refresh and collecting data, those expensive long tasks will show up in the timeline, highlighted with a red rectangle in the right upper corner. Their length indicates how expensive the operation actually is. Tasks have a friendly budget of 50ms to finishwhich is why the first 50ms-portion of the task is displayed in solid grey. Whenever you are beyond that budget, the rest of the task is highlighted with red/grey stripes.

The flame chart is a visualization of what each task consists of. All parts of a task are displayed under the actual tasks, with a yellow background representing scripting. If you click on “Evaluate script” under each of the tasks, you can pull up the “Summary” drawer at the bottom and see which script caused the cost. If you click on the purple bar labeled “Recalculate style”DevTools will show what exactly has triggered styles invalidation.

Probably the most underrated feature in DevTools is indeed the “Summary” drawer which would then also show up which elements were affected by style recalculation (so you can jump to them right away) and what has initiated this task in the first place.

Debugging Janky Animations With Layers (Chrome, Edge, Safari)

You just need a couple of animations, perhaps with a little bit of parallax, a sliding navigation or mischievous z-index manipulation, to run into dropping frames and janky animations. The FPS meter from the performance panel (Chrome) will reveal if you are running frames smoothly, but if it isn’t the case, you can explore rendering issues in the “Layers” tab.

Some of the issues can be easily detected by tracking which of the elements are missing a will-change property, and which ones are using a disproportionate amount of memory. That’s how we spotted a large component that was hidden away off the screen with relative positioning of -1000px off the screen, causing a couple of MB of memory usage. Also, when debugging a canvas issue, keep in mind that Safari has a Canvas Memory Usage debugger.

3D View Z-Index Debugger (Edge)

Another helpful tool to track rendering issues and z-index issues is Edge’s 3D View of the DOM (“Settings” → “More tools” → 3D View). The tool provides an interactive visualization of the DOM and z-index layers. You can even choose to view the DOM colored with the actual background colors of the DOM elements or show only stacking contexts.

It really has never been simpler to see how z-index values are distributed across the page, and why overlays or panels don’t appear as expected when triggered.

Better Accessibility Profiling (Chrome, Edge, Firefox)

Wouldn’t it be great to have one-in-all accessibility tool that would provide details and guidance about everything from tab order to ARIA-attributes and screen reader announcements? To get close to that, we’ve set up a dedicated accessibility profile with useful extensions and bookmarklets mentioned at the beginning of the article. However, DevTools provides some useful features out of the box as well.

In Chrome and Edge, the “Accessibility” panel shows the accessibility tree, used ARIA attributes and computed properties. When using a color picker, you can check and conveniently adjust the colors to accommodate for a AA/AAA-compliant contrast ratio (along with the ability to switch between HEX, RGB, HSL with Shift + Click on swatch — thanks Ana!).

As already mentioned, the “Rendering” panel also allows you to emulate vision deficiencies. Lighthouse audits also include a section with recommendations around the accessibility of the page. Plus, when you inspect an element, accessibility information is appearing in the overview as well.

Firefox has advanced accessibility tooling as well. Additionally to the accessibility tree and contrast checker, Firefox DevTools highlights roles and landmarks, along with accessibility recommendations and checks. For example, you can check for contrast issues on the entire page, check if all links are focusable and include focus styling, and review text labels. Plus, you can toggle tabbing order as well.

Additionally, you can install accessibility-focused extensions such as Accessibility InsightsaXe and a11y.cssalong with a few other accessibility linters and color vision simulators.

Worth Mentioning

Obviously, there are literally hundreds, and perhaps even thousands, of other useful features available in DevTools. Many of them are quite well-known and don’t need much introduction, but are still worth mentioning.

• CSS Grid / Flexbox Inspectors (Firefox, Chrome, Edge)
  If you have any layout issue related to Grid and Flexbox, you’ll probably find a cause of the problem via DevTools. Grid and Flexbox inspectors are very useful as they show grid overlay and the boundaries of containers, as well as hints on everything from flex-basis to grid-gap.

• Live Expressions
  If you’ve been running into habit of typing the same JavaScript expression in the console, you could look into automating it with Live Expressions. The feature, available in Chrome, Edge and Firefox, allows you to type an expression once and then pin it to the top of your console, and the value of the live expression will update automatically.

• Animations Panel
  Firefox has a very handy panel to track issues with animations, including slowing it down and visualizing how an element is changing over time.

• Fonts Panel
  Firefox also has a handy “Fonts” panel that’s worth exploring for any kind of font-related issue. We used it quite a lot when trying to match the fallback font against the web font, for example, as you can refine typographic properties with a slider and see impact in action. It also provides text previews when hovering over a font-family in styles.

• CSS Overview
  If you activate the “CSS Overview” in Chrome’s experimental settings, DevTools will add a tab with a comprehensive report of CSS declarations used on a page. It will also list all colors and fonts used, as well as media queries and unused declarations which you can jump to right away.

And That’s A Wrap!

When we set out to prepare this overview, it was supposed to be quite short, featuring just some of the useful features that DevTools provides. It turned out that there are plenty of features that we didn’t know of before we started writing this article — and we were able to stumble upon them with the kind help of wonderful Smashing readers who contributes their experiences on Twitter. Thank you so much for your kind contributions!

Also, a huge thank-you to all contributors of all DevTools across all browsers — we applaud you for your efforts, and your time and effort to make our development experiences better. It matters.

If we missed something valuableplease reply in the comments. And if you found something useful, we hope you’ll be able to apply these little helpers to your workflow right away, and perhaps send a link to this post to a friend or two — perhaps they’ll find it useful. Ah, and don’t forget: you could also debug DevTools with DevTools — just hit Cmd/Ctrl + Shift + I twice in a row. 😉

Now, happy debugging, everyone!

(yk, il)