Lighthouse: optimiser la vitesse du site Web

Sofia Emelianova
Sofia Emelianova

Objectif du tutoriel

Ce tutoriel vous explique comment utiliser les outils pour les développeurs Chrome afin d'accélérer le chargement de vos sites Web.

Lisez la suite ou visionnez la version vidéo de ce tutoriel:

Conditions préalables

Vous devez avoir une expérience de base du développement Web, semblable à ce qui est enseigné dans ce cours d'introduction au développement Web.

Vous n'avez pas besoin de savoir quoi que ce soit sur les performances de chargement.

Introduction

Voici Tony. Tony est très connu dans la société féline. Il a créé un site Web pour permettre à ses fans de découvrir quels sont ses plats préférés. Ses fans adorent le site, mais Tony ne cesse de se plaindre que le site se charge lentement. Tony vous a demandé de l'aider à accélérer le site.

Tony le chat

Étape 1: Effectuez un audit du site

Lorsque vous cherchez à améliorer les performances de chargement d'un site, commencez toujours par un audit. L'audit remplit deux fonctions importantes:

  • Elle crée une référence à partir de laquelle vous pouvez mesurer les modifications ultérieures.
  • Vous y trouverez des conseils pratiques sur les modifications qui auront le plus d'impact.

Configurer

Tout d'abord, vous devez configurer un nouvel environnement de travail pour le site Web de Tony afin de pouvoir y apporter des modifications ultérieurement:

  1. Remixer le projet du site Web sur Glitch Votre nouveau projet s'ouvre dans un onglet. Cet onglet sera appelé onglet de l'éditeur.

    La source d'origine et l'onglet "Éditeur" après avoir cliqué sur "Remixer".

    Le nom du projet passe de tony à un nom généré aléatoirement. Vous disposez désormais de votre propre copie modifiable du code. Par la suite, vous modifierez ce code.

  2. En bas de l'onglet de l'éditeur, cliquez sur Aperçu > Prévisualiser dans une nouvelle fenêtre. La démonstration s'ouvre dans un nouvel onglet. Cet onglet sera appelé onglet de démonstration. Le chargement du site peut prendre un certain temps.

    Onglet "Demo" (Démonstration)

  3. Ouvrez les outils de développement en même temps que la démonstration.

    Les outils de développement et la démonstration.

Établir une référence

La référence est l'enregistrement des performances du site avant toute amélioration des performances.

  1. Ouvrez le panneau Lighthouse. Il est peut-être masqué derrière Autres panneaux.

    Panneau Lighthouse

  2. Faites correspondre les paramètres de configuration de votre rapport Lighthouse avec ceux de la capture d'écran. Voici une explication des différentes options:

    • check_box Vider l'espace de stockage. Si vous cochez cette case, l'espace de stockage associé à la page sera effacé avant chaque audit. Laissez ce paramètre activé si vous souhaitez contrôler l'expérience des nouveaux visiteurs sur votre site. Désactivez ce paramètre si vous souhaitez bénéficier d'une expérience de visite répétée.
    • check_box Activer l'échantillonnage JS Cette option est désactivée par défaut. Lorsqu'elle est activée, elle ajoute des piles d'appels JavaScript détaillées à la trace des performances, mais peut ralentir la génération de rapports. La trace est disponible sous more_vert dans le menu "Outils" > Afficher la trace non limitée après la génération du rapport Lighthouse. Trace des performances sans échantillonnage JS (à gauche) et avec (à droite)
    • Limitation simulée (par défaut) . Cette option simule les conditions de navigation habituelles sur un appareil mobile. On parle de "simulation " (simulé), car Lighthouse n'est pas limité pendant le processus d'audit. Il extrapole simplement le temps nécessaire pour que la page se charge dans des conditions mobiles. En revanche, le paramètre Limitation des outils de développement (avancé) limite l'utilisation du processeur et du réseau, en contrepartie d'un processus d'audit plus long.
    • Mode > Navigation (par défaut). Ce mode analyse le chargement d'une seule page, et c'est ce dont nous avons besoin dans ce tutoriel. Pour en savoir plus, consultez la section Les trois modes.
    • Appareil > Mobile. L'option "Mobile" modifie la chaîne du user-agent et simule une fenêtre d'affichage mobile. L'option "Ordinateur" désactive quasiment les modifications pour mobile.
    • Catégories > check_box Performances. Une seule catégorie activée permet à Lighthouse de générer un rapport uniquement avec l'ensemble d'audits correspondant. Vous pouvez laisser les autres catégories activées si vous souhaitez voir les types de recommandations qu'elles proposent. La désactivation des catégories non pertinentes accélère légèrement le processus d'audit.
  3. Cliquez sur Analyser le chargement de la page. Au bout de 10 à 30 secondes, le panneau Lighthouse affiche un rapport sur les performances du site.

    Un rapport Lighthouse sur les performances du site

Gérer les erreurs des rapports

Si vous rencontrez une erreur dans votre rapport Lighthouse, essayez d'exécuter l'onglet de démonstration à partir d'une fenêtre de navigation privée sans aucun autre onglet ouvert. Cela garantit que Chrome est entièrement opérationnel. Les extensions Chrome, en particulier, peuvent interférer avec le processus d'audit.

Un rapport contenant une erreur.

Comprendre votre rapport

Le chiffre indiqué en haut de votre rapport correspond au score de performance global du site. Par la suite, ce nombre devrait augmenter à mesure que vous modifierez le code. Un score élevé signifie de meilleures performances.

Score de performance globale.

Métriques

Faites défiler la page jusqu'à la section Métriques, puis cliquez sur Développer la vue. Pour consulter la documentation sur une métrique, cliquez sur En savoir plus.

La section des métriques.

Cette section fournit des mesures quantitatives des performances du site. Chaque métrique fournit des insights sur un aspect différent des performances. Par exemple, First Contentful Paint vous indique quand le contenu est affiché pour la première fois à l'écran, ce qui constitue une étape importante dans la perception du chargement de la page par l'utilisateur, tandis que Time To Interactive indique le moment où la page semble suffisamment prête pour gérer les interactions des utilisateurs.

Captures d'écran

Vous trouverez ensuite une série de captures d'écran qui vous montrent à quoi ressemblait la page lors de son chargement.

Captures d'écran illustrant l'apparence de la page lors du chargement

Opportunités

Vient ensuite la section Opportunités, qui fournit des conseils spécifiques sur la façon d'améliorer les performances de chargement de cette page spécifique.

Section "Opportunités"

Cliquez sur une opportunité pour en savoir plus à son sujet.

En savoir plus sur la compression de texte.

Cliquez sur En savoir plus pour découvrir pourquoi une opportunité est importante et obtenir des recommandations spécifiques sur la façon de la corriger.

Diagnostic

La section Diagnostic fournit plus d'informations sur les facteurs qui contribuent au temps de chargement de la page.

Section "Diagnostic".

Audits réussis

La section Audits réussis indique ce que fait le site correctement. Cliquez pour développer la section.

Section "Audits réussis"

Étape 2: Tester

La section Opportunités de votre rapport Lighthouse vous explique comment améliorer les performances de la page. Dans cette section, vous allez implémenter les modifications recommandées pour le codebase, en auditant le site après chaque modification afin de mesurer son impact sur sa vitesse.

Activer la compression de texte

Votre rapport indique que l'activation de la compression de texte est l'une des meilleures opportunités d'améliorer les performances de la page.

La compression de texte consiste à réduire, ou à compresser, la taille d'un fichier texte avant de l'envoyer sur le réseau. Un peu comme vous pourriez compresser un dossier avant de l'envoyer par e-mail pour réduire sa taille.

Avant d'activer la compression, voici quelques méthodes pour vérifier manuellement si les ressources de texte sont compressées.

Ouvrez le panneau Réseau, puis cochez Paramètres > Utiliser des lignes de requête volumineuses.

Colonne "Taille" du panneau "Network" (Réseau) affichant des lignes de requête volumineuses.

Chaque cellule Size (Taille) affiche deux valeurs. La valeur supérieure correspond à la taille de la ressource téléchargée. La valeur inférieure correspond à la taille de la ressource non compressée. Si les deux valeurs sont identiques, la ressource n'est pas compressée lorsqu'elle est envoyée sur le réseau. Dans cet exemple, les valeurs supérieure et inférieure de bundle.js sont toutes deux 1.4 MB.

Vous pouvez également vérifier la compression en inspectant les en-têtes HTTP d'une ressource:

  1. Cliquez sur bundle.js et ouvrez l'onglet Headers (En-têtes).

    Onglet "En-têtes"

  2. Recherchez un en-tête content-encoding dans la section En-têtes de réponse. Vous ne devriez pas en voir, ce qui signifie que bundle.js n'a pas été compressé. Lorsqu'une ressource est compressée, cet en-tête est généralement défini sur gzip, deflate ou br. Pour en savoir plus sur ces valeurs, consultez les directives.

Assez avec les explications. Il est temps d'apporter des modifications ! Activez la compression de texte en ajoutant quelques lignes de code:

  1. Dans l'onglet de l'éditeur, ouvrez server.js et ajoutez les deux lignes suivantes (en surbrillance) :

    ...
    const fs = require('fs');
    const compression = require('compression');
    
    app.use(compression());
    app.use(express.static('build'));
    ...
    
  2. Veillez à ajouter app.use(compression()) avant app.use(express.static('build')).

    Modification du fichier server.js

  3. Attendez que Glitch déploie la nouvelle version du site. Un emoji joyeux en bas à gauche indique que le déploiement a réussi.

Utilisez les workflows que vous avez appris précédemment pour vérifier manuellement que la compression fonctionne:

  1. Revenez à l'onglet de démonstration et actualisez la page.

    La colonne Size (Taille) doit maintenant afficher deux valeurs différentes pour les ressources de texte telles que bundle.js. La valeur supérieure de 269 KB pour bundle.js correspond à la taille du fichier envoyé sur le réseau, et la valeur inférieure de 1.4 MB est la taille du fichier non compressé.

    La colonne Taille affiche désormais deux valeurs différentes pour les ressources de texte.

  2. La section En-têtes de réponse pour bundle.js doit désormais inclure un en-tête content-encoding: gzip.

    La section "En-têtes de réponse" contient désormais un en-tête d'encodage du contenu.

Exécutez à nouveau le rapport Lighthouse sur la page pour mesurer l'impact de la compression de texte sur les performances de chargement de la page:

  1. Ouvrez le panneau Lighthouse, puis cliquez sur Ajouter Perform an audit (Effectuer un audit) dans la barre d'action en haut de l'écran.

    Bouton "Effectuer un audit".

  2. Laissez les paramètres inchangés et cliquez sur Analyser le chargement de la page.

    Un rapport Lighthouse après avoir activé la compression de texte

Excellent ! On dirait une progression. Votre score de performances globales aurait dû augmenter, ce qui signifie que le site s'accélère.

Compression de texte dans le monde réel

La plupart des serveurs disposent de correctifs simples comme celui-ci pour permettre la compression ! Faites simplement une recherche sur la façon de configurer le serveur que vous utilisez pour compresser du texte.

Redimensionner les images

D'après votre nouveau rapport, le dimensionnement correct des images constitue une autre opportunité majeure.

Le redimensionnement des images permet d'accélérer le temps de chargement en réduisant la taille des fichiers d'image. Si un utilisateur consulte vos images sur un écran d'appareil mobile de 500 pixels de large, il est inutile d'envoyer une image de 1 500 pixels de large. Idéalement, vous devriez envoyer une image de 500 pixels de largeur au maximum.

  1. Dans votre rapport, cliquez sur Taille appropriée des images pour voir les images à redimensionner. Il semble que les quatre images sont plus grandes que nécessaire.

    Détails sur l 'opportunité permettant d'ajuster la taille des images

  2. De retour dans l'onglet de l'éditeur, ouvrez src/model.js.

  3. Remplacez const dir = 'big' par const dir = 'small'. Ce répertoire contient des copies des mêmes images qui ont été redimensionnées.

  4. Effectuez un nouvel audit de la page pour voir comment cette modification affecte les performances de chargement.

    Rapport Lighthouse après le redimensionnement des images

Il semble que cette modification n'affecte que légèrement le score global de performances. Toutefois, le score n'indique pas clairement la quantité de données réseau que vous économisez pour vos utilisateurs. La taille totale des anciennes photos était d'environ 6,1 Mo, contre seulement 633 Ko maintenant. Vous pouvez le vérifier dans la barre d'état en bas du panneau Network (Réseau).

Quantité de données transférées avant et après le redimensionnement des images.

Redimensionnement d'images dans le monde réel

Pour une petite application, un redimensionnement ponctuel de ce type peut suffire. Mais pour une grande application, cela n'est évidemment pas évolutif. Voici quelques stratégies pour gérer les images dans les applications volumineuses:

  • Redimensionnez les images pendant le processus de compilation.
  • Créez plusieurs tailles de chaque image pendant le processus de compilation, puis utilisez srcset dans votre code. Au moment de l'exécution, le navigateur se charge de choisir la taille la plus adaptée à l'appareil sur lequel il s'exécute. Consultez la section Images de taille relative.
  • Utilisez un CDN image qui vous permet de redimensionner dynamiquement une image lorsque vous la demandez.
  • Au minimum, optimisez chaque image. Cela permet souvent de réaliser d'importantes économies. L'optimisation consiste à exécuter une image à l'aide d'un programme spécial qui réduit la taille du fichier image. Pour plus de conseils, consultez la section Optimisation des images essentielles.

Éliminer les ressources bloquant l'affichage

D'après votre dernier rapport, la plus grande opportunité à saisir est désormais d'éliminer les ressources bloquant l'affichage.

Une ressource bloquant l'affichage est un fichier JavaScript ou CSS externe que le navigateur doit télécharger, analyser et exécuter avant de pouvoir afficher la page. L'objectif est d'exécuter uniquement le code CSS et JavaScript de base nécessaire pour afficher correctement la page.

La première tâche consiste à trouver le code qui n'a pas besoin d'être exécuté au chargement de la page.

  1. Cliquez sur Éliminer les ressources qui bloquent l'affichage pour afficher les ressources qui bloquent : lodash.js et jquery.js.

    En savoir plus sur l 'opportunité de réduction des ressources qui bloquent l'affichage.

  2. Selon votre système d'exploitation, appuyez sur la touche suivante pour ouvrir le menu de commandes:

    • Sur Mac, Commande+Maj+P
    • Sous Windows, Linux ou ChromeOS, appuyez sur Ctrl+Maj+P.
  3. Commencez à saisir Coverage, puis sélectionnez Afficher la couverture.

    Ouverture du menu de commandes dans le panneau Lighthouse.

    L'onglet Couverture s'ouvre dans le panneau.

    Onglet "Couverture"

  4. Cliquez sur Actualisez la page. Actualiser. L'onglet Couverture fournit un aperçu de la portion de code exécutée dans bundle.js, jquery.js et lodash.js pendant le chargement de la page.

    Le rapport de couverture

    Cette capture d'écran indique qu'environ 74% et 30% des fichiers jQuery et Lodash ne sont pas utilisés, respectivement.

  5. Cliquez sur la ligne jquery.js. Les outils de développement ouvrent le fichier dans le panneau Sources. Une ligne de code a été exécutée si elle est accompagnée d'une barre verte. Une barre rouge à côté d'une ligne de code indique qu'elle n'a pas été exécutée et qu'elle n'est certainement pas nécessaire au chargement de la page.

    Affichage du fichier jQuery dans le panneau "Sources".

  6. Faites défiler un peu le code jQuery. Certaines des lignes qui sont « exécutées » ne sont en fait que des commentaires. L'exécution de ce code via un outil de réduction de taille qui supprime les commentaires est un autre moyen de réduire la taille de ce fichier.

Pour résumer, lorsque vous travaillez avec votre propre code, l'onglet Couverture peut vous aider à analyser votre code ligne par ligne et à n'envoyer que le code nécessaire au chargement de la page.

Les fichiers jquery.js et lodash.js sont-ils même nécessaires pour charger la page ? L'onglet Request Blocking (Blocage des requêtes) peut vous montrer ce qui se passe lorsque des ressources ne sont pas disponibles.

  1. Cliquez sur l'onglet Réseau, puis rouvrez le menu de commandes.
  2. Commencez à saisir blocking, puis sélectionnez Show Request Blocking (Afficher le blocage des requêtes). L'onglet Request Blocking (Blocage des requêtes) s'ouvre.

    Onglet "Request Blocking" (Blocage des requêtes)

  3. Cliquez sur Ajouter Ajouter un format, saisissez /libs/* dans la zone de texte, puis appuyez sur Entrée pour confirmer.

    Ajout d'un format pour bloquer toute requête envoyée au répertoire "libs".

  4. Actualisez la page. Les requêtes jQuery et Lodash apparaissent en rouge, ce qui signifie qu'elles ont été bloquées. La page se charge toujours et est interactive. Il semble donc que ces ressources ne soient pas nécessaires.

    Le panneau "Network" (Réseau) indique que les requêtes ont été bloquées.

  5. Cliquez sur Supprimer. Supprimer tous les formats pour supprimer le format bloquant /libs/*.

En général, l'onglet Request Blocking (Blocage des requêtes) est utile pour simuler le comportement de votre page lorsqu'une ressource donnée n'est pas disponible.

À présent, supprimez les références à ces fichiers du code et effectuez un nouvel audit de la page:

  1. De retour dans l'onglet de l'éditeur, ouvrez template.html.
  2. Supprimez les tags <script> correspondants:

    <head>
        ...
        <meta name="viewport" content="width=device-width, initial-scale=1">
        <script src="/libs/lodash.js"></script>
        <script src="/libs/jquery.js"></script>
        <title>Tony's Favorite Foods</title>
    </head>
    
  3. Attendez que le site soit recréé et redéployé.

  4. Effectuez un nouvel audit de la page à partir du panneau Lighthouse. Votre score global aurait dû de nouveau s'améliorer.

    Un rapport Lighthouse après avoir supprimé les ressources qui bloquent l&#39;affichage

Optimiser le chemin d'affichage essentiel dans le monde réel

Le chemin de rendu critique fait référence au code dont vous avez besoin pour charger une page. En règle générale, vous pouvez accélérer le chargement d'une page en n'envoyant que le code critique pendant le chargement de la page, puis en effectuant tout le chargement différé.

  • Il est peu probable que vous trouviez des scripts que vous pourrez supprimer complètement. Toutefois, vous constaterez souvent que de nombreux scripts n'ont pas besoin d'être demandés lors du chargement de la page, et peuvent l'être de manière asynchrone. Consultez la section Utiliser des paramètres asynchrones ou différés.
  • Si vous utilisez un framework, vérifiez s'il est en mode production. Ce mode peut utiliser une fonctionnalité telle que le tree secousses afin d'éliminer le code inutile qui bloque le rendu critique.

Moins de tâches sur le thread principal

Votre dernier rapport indique des économies potentielles mineures dans la section Opportunities (Opportunités), mais si vous faites défiler la page jusqu'à la section Diagnostics, il semble que le plus grand goulot d'étranglement est une trop grande activité du thread principal.

Le thread principal est l'endroit où le navigateur effectue la plupart des tâches nécessaires à l'affichage d'une page, telles que l'analyse et l'exécution de code HTML, CSS et JavaScript.

L'objectif est d'utiliser le panneau Performance pour analyser les tâches effectuées par le thread principal pendant le chargement de la page, et trouver des moyens de différer ou de supprimer les tâches inutiles.

  1. Ouvrez Performances > Paramètres. Paramètres de capture, puis définissez Réseau sur 3G lente et Processeur sur Ralentissement 6x.

    Paramètres la limitation du processeur et du réseau dans le panneau &quot;Performances&quot;

    Les appareils mobiles présentent généralement plus de contraintes matérielles que les ordinateurs portables ou de bureau. Avec ces paramètres, la page se charge comme si vous utilisiez un appareil moins puissant.

  2. Cliquez sur Actualisez la page. Actualiser. Les outils de développement actualisent la page, puis génèrent une visualisation de tout ce qu'il y avait à faire pour charger la page. Cette visualisation sera appelée trace.

    Trace du panneau &quot;Performances&quot; du chargement de la page.

La trace affiche l'activité de manière chronologique, de gauche à droite. Les graphiques FPS, CPU et NET en haut de la page présentent le nombre d'images par seconde, l'activité du processeur et l'activité réseau.

Section &quot;Présentation&quot; de la trace

Le mur jaune qui apparaît dans la section Présentation signifie que le processeur était complètement occupé à écrire des scripts. Cela indique que vous pouvez accélérer le chargement des pages en utilisant moins de JavaScript.

Examinez la trace pour trouver des moyens d'effectuer moins de tâches JavaScript:

  1. Cliquez sur la section Délais pour la développer.

    Section &quot;Délais&quot;

    Il existe de nombreuses mesures de temps utilisateur dans React. Il semble que l'application de Tony utilise le mode de développement de React. En passant en mode production dans React, vous améliorerez sans doute facilement les performances.

  2. Cliquez de nouveau sur Durées pour réduire cette section.

  3. Parcourez la section Main (Principal). Cette section présente un journal chronologique de l'activité du thread principal, de gauche à droite. L'axe des y (de haut en bas) indique la raison pour laquelle des événements se sont produits.

    Section &quot;Principale&quot;.

    Dans cet exemple, l'événement Evaluate Script a entraîné l'exécution de la fonction (anonymous), ce qui a entraîné l'exécution de __webpack__require__, l'exécution de ./src/index.jsx, etc.

  4. Faites défiler la page jusqu'en bas de la section Main (Principal). Lorsque vous utilisez un framework, la majeure partie de l'activité supérieure est causée par le framework, ce qui est généralement hors de votre contrôle. L'activité générée par votre application s'affiche généralement en bas de l'écran.

    L&#39;activité mineBitcoin.

    Dans cette application, il semble qu'une fonction appelée App génère de nombreux appels à une fonction mineBitcoin. On dirait que Tony utilise les appareils de ses fans pour miner de la cryptomonnaie...

  5. Ouvrez l'onglet Ascendant en bas. Cet onglet détaille les activités qui ont pris le plus de temps. Si vous ne voyez rien dans la section Ascendant, cliquez sur le libellé de la section Principale.

    L&#39;onglet Ascendant.

    La section Ascendant affiche uniquement les informations sur l'activité ou le groupe d'activités que vous avez sélectionné. Par exemple, si vous cliquez sur l'une des activités mineBitcoin, la section Bottom-Up n'affiche que les informations concernant cette activité.

    La colonne Temps propre indique combien de temps a été passé directement dans chaque activité. Dans ce cas, environ 82% du temps du thread principal a été consacré à la fonction mineBitcoin.

Il est temps de déterminer si l'utilisation du mode production et la réduction de l'activité JavaScript accélère le chargement de la page. Commencez par le mode production:

  1. Dans l'onglet de l'éditeur, ouvrez webpack.config.js.
  2. Remplacez "mode":"development" par "mode":"production".
  3. Attendez que la nouvelle compilation soit déployée.
  4. Effectuez un nouvel audit de la page.

    Un rapport Lighthouse après avoir configuré webpack pour utiliser le mode production

Réduisez l'activité JavaScript en supprimant l'appel à mineBitcoin:

  1. Dans l'onglet de l'éditeur, ouvrez src/App.jsx.
  2. Mettez en commentaire l'appel à this.mineBitcoin(1500) dans constructor.
  3. Attendez que la nouvelle compilation soit déployée.
  4. Effectuez un nouvel audit de la page.

Un rapport Lighthouse après avoir supprimé les tâches JavaScript inutiles

Comme toujours, il reste des choses à faire, par exemple en réduisant les métriques Largest Contentful Paint et Cumulative Layout Shift.

Moins de travail des threads principaux dans le monde réel

En général, le panneau Performances est le moyen le plus courant d'identifier l'activité de votre site lors de son chargement et de trouver des moyens de supprimer toute activité inutile.

Si vous préférez une approche qui ressemble davantage à console.log(), l'API User Timing vous permet de baliser arbitrairement certaines phases du cycle de vie de votre application, afin de suivre la durée de chacune d'elles.

Résumé

  • Lorsque vous envisagez d'optimiser les performances de chargement d'un site, commencez toujours par un audit. L'audit établit une base de référence et vous donne des conseils sur la façon de l'améliorer.
  • Effectuez une modification à la fois et effectuez un audit de la page après chaque modification afin de voir comment cette modification isolée affecte les performances.

Étapes suivantes

Effectuez des audits sur votre propre site ! Si vous avez besoin d'aide pour interpréter votre rapport ou pour trouver des moyens d'améliorer les performances de chargement, consultez l'ensemble des ressources disponibles pour obtenir de l'aide auprès de la communauté des outils de développement:

  • Signalez des bugs sur ce document dans le dépôt developer.chrome.com.
  • Signalez les bugs dans les outils de développement sur Chromium Bugs.
  • Discutez des fonctionnalités et des modifications apportées à la liste de diffusion. Veuillez ne pas utiliser cette liste de diffusion pour les questions d'assistance. Utilisez plutôt Stack Overflow.
  • Obtenez une aide générale sur l'utilisation des outils de développement sur Stack Overflow. Pour envoyer des demandes de bugs, utilisez toujours l'outil Bugs Chromium.
  • Envoyez-nous un tweet à @ChromeDevTools.