次の方法で共有


Internet Explorer 9 Les outils de développement en détails - Partie 5 : Performance et analyse des échanges réseaux

Ce billet fait partie d'une série sur les Developer Tools inclus avec Internet Explorer (et ce depuis la version 8) visant à vous aider à améliorer vos sites Web grâce à des outils d'examen de contenu, à diagnostiquer des problèmes, à améliorer les performances, et bien plus encore:

Si vous ne connaissez pas les outils de développement (encore appelés F12 Tools ou encore Developer Tools), je vous recommande de commencer par lire le billet d'introduction.

Performance et analyse des échanges réseaux avec IE9

Jusqu’à présent, nous nous sommes focalisés sur l’expérience côté client, mias il est important de savoir comment votre application exploite les ressources réseaux.

Réduire la taille de téléchargement, trouver le contenu manquant ou redirigé, l'amélioration de l'utilisation du cache, et bien plus encore peuvent améliorer les performances (perçues et réelles) et de réduire vos factures de bande passante.

 

L'onglet Réseau

L'onglet Réseau, nouveau dans Internet Explorer 9, offre un moyen simple de capturer et d’analyser le trafic réseau et les requêtes de cache. Vous pouvez obtenir rapidement un rapport sur les demandes et les réponses, y compris les entêtes, le timing et bien d’autres détails.

«Attendez, est-ce Fiddler sous IE?"

Fiddler Session at MIX11 Non, mais ...

Fiddler est un proxy web de débogage développé par Eric Laurent (qui se trouve être également un PM de l'équipe Internet Explorer.) Alors que vous trouverez des similitudes avec Fiddler dans certains cas, ils sont très différents sous d’autres aspects.

Eric a donné une session sur Fiddler au MIX11 , et a passé du temps (vers 12:30 dans la vidéo) à décrire les principales différences avec les outils de développement F12. L'enregistrement de la session et les slides sont disponibles gratuitement.

Vous pouvez également en entendre plus sur la participation d’Eric au 116ème épisode du «Code de Herding" podcast .

Création d'une session de capture

Pour commencer, lancez les outils de développement F12 (Outils –> "Outils de développement F12" ou tout simplement appuyez sur la touche F12) et cliquez sur l'onglet Réseau. Cliquez sur "Démarrer la capture" et naviguez vers une page (dans ce cas, la page d’accueil IETestDrive) :

Network capture session

Vue résumée

Par défaut, le trafic capturé est représenté en vue résumée, avec les champs suivants:

  • URL
  • Méthode – la méthode HTTP (GET, POST, etc)
  • Résultat – le code retour de la réponse HTTP (200, 301, 304, etc) Il existe de nombreux codes, comprenant les redirections et les erreurs. Par exemple, recherchez des erreur 404, indiquant que l'URL est erronée ou le contenu non disponible.
  • Type - le type de contenu
  • Reçu(s) - Taille des données reçues
  • Ecoulé - Durée de la requête
  • Initiateur - Cause de la demande (voir Initiateurs de Requêtes ci-dessous)
  • Minutage - Graphique du timing requête/réponse (voir ci-dessous Timings de Requêtes)

Cliquez sur n'importe quelle entête de champ pour le trier, et faites un clic droit pour les options telles que l’affichage des données en octets ou les temps en millisecondes :

Summary view options

Double-cliquez ou sélectionnez un élément et cliquez sur "Atteindre la vue détaillée" pour plus de détails.

Vue détaillée

Detailed view

Il y a sept catégories de détails pour chaque demande:

Detailed view categories

  • En-têtes de demande
  • Corps de demande - Le contenu (le corps) de la demande, s’il existe.
  • En-têtes de réponse
  • Corps de réponse - le contenu (le corps) de la réponse. Présenté sous forme de texte (s’il s’agit de script, css, etc) ou graphiquement si possible (de type image)
  • Cookies - Les cookies envoyés ou reçus pour la demande
  • Initiateur - Ce qui a poussé la demande. Voir Initiateurs de requête ci-dessous.
  • Minutage - répartition détaillée du timing. Voir Minutage de requête ci-dessous.

Vous pouvez parcourir les éléments avec les boutons Précédent Previous button (CTRL + ,) et Suivant Next button (CTRL + .) , et appuyez sur "Retour à la vue résumée" pour revenir à la vue initiale.

Minutage de requête

Le minutage de requête peut sembler un peu complexe au premier abord, mais il assez simple une fois quelques notions maitrisées.

Commençons avec une requête simple d’une image de la home page IETestDrive (après effacement du cache - voir plus loin), montrant les détails du minutage pour le fichier GraySwooshWatermark.png :

Timings tab

Zoom sur le côté gauche :

Timings detail

Le cycle requête/réponse est composé de sept composantes :

  • Attente - Temps depuis le début de la navigation sur la page jusqu’au moment où la requête a commencé.
  • Début – Le temps depuis la création de la requête jusqu’au début de son envoi.
  • Demande – Le temps depuis de début de l’envoie de la requête jusqu’au début de la réception de la réponse. Aussi connu comme le temps de premier octet.
  • Réponse – Le temps depuis le temps du premier octet jusqu’à l'achèvement de la réception de la réponse.
  • Ecart – Délai entre l'achèvement de la réception de la réponse et l’évènement page load.
  • DOMContentLoaded – Timing de l'évènement DOMContentLoaded.
  • Load (event) – Timing de l'évènement page load.

Cliquez dans la liste ou sur le schéma pour mettre en évidence chaque composant de minutage.

  • Astuce: Si vous oubliez, les descriptions ci-dessus sont présentés dans les outils de développement F12 lorsque vous cliquez sur chaque.
DOMContentLoaded vs. Page Load

Pourquoi les évènements DOMContentLoaded et page Load sont différent? DOMContentLoaded se déclenche lorsque la page et les scripts sont chargés. Cela peut se produire avant que les autres demandes (par exemple les images) sont terminées, à ce moment là l'évènement page Load est levé.

La différence entre ceux-ci peut être importantes, surtout lors du téléchargement de grands illustrations, publicités ou autres contenus, de sorte qu'il peut être utile de lier les scripts de la page à l'évènement DOMContentLoaded plutôt qu’au page Load.

Pour une bonne démonstration de ceci en situation, lancez le DOMContentLoaded exemple du site IETestDrive :

DOMContentLoaded example

Lancez-le deux fois pour voir l'impact que la mise en cache du navigateur a sur le delta entre les évènements.

Analyser le trafic en cours

Jusqu'ici, nous nous sommes focalisés sur le profilage d'utilisation du réseau liée au chargement d’une page initiale, mais les outils de développement F12 peuvent également suivre les demandes en cours, telles que les demandes de contenu supplémentaire et les appels basées sur Ajax.

Pour voir cela en situation nous allons exécuter le Texas Hold'em exemple à partir du site IETestDrive .

Exécutez l'exemple et sur l'onglet Réseau, cliquez sur "Démarrer la capture". Ensuite, passez la souris sur le bouton "START", mais ne cliquez pas encore:

Texas Hold'em example

Vous verrez qu’une demande pour une image (buttonGeneric_Hover.png) a été faite au moment où le curseur survolait ​​le bouton:

Image request

Initiateurs de requête

Pourquoi IE9 a attendu pour télécharger cette image? Pour avoir plus d’informations, double-cliquez (ou survolez pour obtenir une infobulle) sur la zone Initiateur. Ci-dessous une capture montrant la valeur "background-image" :

Image request Initiator details

L'initiateur nous indique ce qui a incité IE9 à faire la requête. Dans ce cas, le CSS précise un fond alternatif au moment du survol du bouton, mais IE défère le téléchargement de l'image jusqu'à ce que l'évènement hover soit exécuté. (Comme indiqué dans la partie 2 , vous pouvez sélectionner le bouton et afficher l'onglet Styles CSS pour voir la règle de survol input.actionButton:hover.)

Maintenant cliquez sur le bouton "START" et vous verrez trois requêtes de plus :

Additional requests

Les requêtes ont été pour le background d'un autre élément, et les deux premières cartes jouées. Cliquez sur "Atteindre la vue détaillée" ou double-cliquez sur des requêtes des carte, puis choisissez l’onglet "Corps de réponse" :

Response body for a playing card

A nouveau, pour voir pourquoi la demande a été faite, cliquez sur l’onglet "Initiateur" :

Card image request initiator

Nous voyons cette fois-ci que le JavaScript changé l'attribut src de l'élément img (dans ce cas de «Hearts_Queen.png»), ce qui a abouti à une requête de téléchargement de l'image.

Du HTML au CSS et aux scripts, il y a beaucoup d'initiateurs demande possible. Voici quelques exemples courants :

  • background-image
  • click
  • @font-face
  • <frame>
  • frame navigate
  • <img>
  • @import
  • innerHtml
  • <input type=“image”>
  • navigate
  • Refresh
  • <script>
  • XmlHttpRequest

Prendre le temps de comprendre les initiateurs vous donnera un outil supplémentaire pour améliorer les performances des pages et du réseau. Pour plus de détails, voir “Understanding Download-Initiator” dans ce  Fiddler blog post .

 

La mise en cache du navigateur

Après un certain nombre de mains au Texas Hold'em , vous remarquerez peut-être des requêtes de certains éléments ne sont pas faites ou donnent un résultat 304. C'est parce qu'ils ont déjà été téléchargés pour jouer d'autres mains et sont déjà disponibles localement.

Redémarrez l'application (rafraichissement IE9) et vous pouvez voir quelques 304. Par exemple:

304 results

Notez la grande différence dans le champ reçu entre les images en cache (304) et les téléchargées (200). Dans cet exemple, 11.65KB pour l'image entière, contre seuleument 162 octets pour une 304 – résultat Not Modified.

Pour voir ce à un niveau supérieur, voici une première demande à l'exemple CSS3 Media Queries example :

Initial page load

La deuxième demande est très différente:

Second page request

Non seulement la page est prête plus rapidement, mais la plupart des demandes ont été servis par le cache du navigateur (en témoignent les 304, les petits segments bleues visibles sous Minutage.)

  • Astuce: Utilisez les outils de développements F12 pour vous assurer que votre serveur web envoie des en-têtes de cache correctement configuré au niveau des expirations.
  • Astuce: Pour améliorer le cache, assurez-vous des noms de fichier référencés et de la case utilisée. L’exemple surveillance du réseau montre l'effet de l’usage de mauvaise case.

Pour effacer le cache et donc forcer l’usage du réseau, cliquez sur le bouton "Effacer le cache navigateur"  Clear browser cache button (CTRL + R).

Le champ Minutage montre le timing des requêtes les plus tardives par rapport à la requête d'origine (y compris les temps d'attente d’action sur un bouton comme dans le Texas Hold'em , par exemple). Ceci se passe jusqu'à ce que vous démarrez une nouvelle session ou cliquez sur le bouton "Effacer" Clear button qui efface les résultats et les timings pour les demandes ultérieures.

Sauvegarde des captures réseau

Comme nous l'avons vu avec le profilage JavaScript, vous pouvez également enregistrer les détails de profilage réseau dans un fichier externe. Appuyez sur le bouton "Exporter le trafic capturé" Export captured traffic button pour enregistrer les résultats de la capture :

image

Les données Réseau peuvent être sauvegardés au format CSV (Comma Separated Values) ou XML en utilisant le format HTTP Archive, décrit dans ce blog IE .

  • Astuce: Comme mentionné dans le blog IE, vous pouvez importer ces fichiers XML dans Fiddler . .

Conclusion

J'espère sincèrement que vous avez trouvé cette série utile. Si vous avez des commentaires ou des idées pour d'autres scénarios à couvrir, s'il vous plaît laissez un commentaire ici.

Merci, et amusez vous bien avec les outils de développement F12!

 

Ce billet est une adaptation du post de Chris Bowen (Principal Developer Evangelist for Microsoft) : Internet Explorer 9 Developer Tools Deep Dive – Part 5: Network Performance and Debugging