Share
Mes deux précédents articles étaient centrés sur les outils de débogage, il est donc normal que je continue avec ce thème. Lors du débogage du code frontal, vous avez tendance à passer beaucoup de temps à examiner la manière dont CSS et JavaScript affectent le rendu de votre page. La manière dont les requêtes réseau affectent votre site est également importante. Dans de nombreux cas, nous travaillons localement et oublions que la taille de la page, la latence, ainsi que le chargement et le blocage des scripts peuvent grandement affecter la manière dont un utilisateur utilise votre site. Il est donc essentiel de disposer d'un bon ensemble d'outils pour inspecter le trafic réseau afin de compléter votre ensemble d'outils de débogage..
Heureusement, tous les principaux navigateurs modernes fournissent des outils de débogage qui vous permettent d'inspecter le trafic réseau, et des outils tiers tels que Fiddler et Charles vous permettent non seulement de voir les requêtes réseau, mais également d'offrir des fonctionnalités étendues pour interagir avec votre site..
Nous allons explorer les deux types d'outils.
Comme je l'ai mentionné, tous les principaux navigateurs ont des outils de débogage intégrés. Ceux-ci inclus:
Chaque ensemble possède ses propres fonctionnalités, mais il est également possible de collecter le trafic réseau. Si nous regardons les images suivantes, vous pouvez voir que, même si les interfaces utilisateur peuvent varier, les données collectées et affichées sont très similaires:
Le résultat final est une liste des requêtes réseau du navigateur impliquées dans le téléchargement des actifs ou des données de nos pages. L'outil de réseau est capable d'intercepter ces demandes pour vous montrer des données importantes telles que:
Fiddler prendra la demande de votre URI et le remplacera par un fichier local.
Ainsi, si nous examinons les résultats de Firebug, nous pouvons voir que la demande a retiré la page principale et ses fichiers CSS et JavaScript associés, y compris les actifs de AWS d'Amazon. En raison de contraintes d'image, je ne peux pas vous montrer tout ce qu'il a chargé, mais des fichiers image et Flash swf ont également été renvoyés..
Grâce à ces informations, je peux maintenant accéder à des requêtes spécifiques pour déterminer si je reçois les données appropriées ou pourquoi je pourrais avoir une requête de longue durée. Supposons que je regarde la demande du fichier JavaScript de Webtrend. Le téléchargement a pris 1,2 seconde et je veux voir comment la demande est traitée. Je peux développer la demande et déterminer si elle est compressée (c'est le cas):
et si ça a été minifié:
Dans ce cas, le fichier n'a pas été minifié et je peux contacter le développeur pour déterminer s'il est judicieux de le faire. Certes, il s’agit d’un fichier 2K, mais chaque octet compte et cette information me permet de mieux optimiser mon site..
La latence du réseau peut être mortelle, en particulier pour les applications d'une seule page dont la capacité dépend d'API externes ou de plusieurs fichiers de script. La plupart des navigateurs essaient de charger des ressources de manière asynchrone quand ils le peuvent, mais certains, comme les fichiers JavaScript, peuvent provoquer des événements bloquants. Il est important de pouvoir les identifier afin d'optimiser au maximum le chargement des ressources. Si nous regardons cette image, vous pouvez voir que le fichier a pris 1,4 seconde pour se charger:
En survolant les échéances, nous obtenons une boîte de dialogue nous indiquant la progression de la demande:
Une partie de cela était parce qu'il était bloqué de chargement pendant 760 ms. Si cela s'avérait être un problème récurrent, vous pouvez envisager d'utiliser un chargeur de script tel que RequireJS pour mieux gérer le chargement de script et les dépendances..
Les applications dynamiques étant si omniprésentes, il est essentiel de pouvoir inspecter les appels XHR. Auparavant, vous rencontriez une tonne de requêtes réseau et essayer de les filtrer pour trouver vos appels XHR n'était pas efficace. De ce fait, la plupart des outils vous permettent de choisir les types de demandes à afficher. Ici, je filtre par demandes XHR afin de pouvoir évaluer la demande et la réponse:
En explorant la demande, je peux évaluer des détails importants sur la demande, tels que les en-têtes et le statut, la méthode de la demande, les cookies et, plus important encore, la réponse qui a été renvoyée:
HTML a été renvoyé dans ce cas, mais la réponse pourrait être n'importe quoi, y compris du texte, JSON ou XML. La bonne chose est que je suis capable de l'inspecter complètement au cas où j'aurais des problèmes.
Les cookies sont extrêmement utiles et, comme nous les utilisons beaucoup, avoir un moyen facile de contrôler leurs valeurs facilite la vie. Les outils de développement facilitent cela en vous montrant quels sont les cookies qui ont été envoyés et reçus:
Si vous avez déjà effectué un développement côté serveur sans outils côté client, vous saurez pourquoi c'est si génial.
Globalement, l’avantage de cette fonctionnalité réside dans le fait qu’elle est dotée des fonctionnalités indispensables à votre navigateur, ce qui la rend extrêmement pratique pour afficher le débogueur en incrustation et vérifier les résultats. Parfois, cependant, vous avez besoin d'un peu plus de puissance.
Les applications de proxy HTTP telles que Fiddler et le proxy de débogage de Charles Web sont les grands frères des renifleurs de trafic réseau basés sur un navigateur. Ils peuvent non seulement intercepter les requêtes réseau du navigateur, mais également d'autres applications de votre ordinateur, ce qui les rend beaucoup plus polyvalentes pour le débogage. Ils ont également tendance à offrir des fonctionnalités plus riches telles que:
J'utilise énormément le Fiddler (gratuit), basé sur Windows et incroyablement riche en fonctionnalités. Il est également très utilisé dans Microsoft en raison de son ensemble de fonctionnalités robuste. Le développeur de Fiddler, Eric Lawrence, travaillait auparavant chez Microsoft et maintient toujours l'application.
Si vous regardez l'interface utilisateur, vous verrez des similitudes dans la sortie avec ce que nous avons vu dans les outils du navigateur. Toutes les demandes du réseau apparaissent avec des informations clés sur les demandes.
Et en explorant une requête, je peux voir beaucoup de détails à ce sujet, y compris la source minifiée de la bibliothèque jQuery:
Une grande partie de cette information peut être récupérée via les outils du navigateur, mais que se passe-t-il lorsque vous voulez savoir si une bibliothèque spécifique fait exploser votre site? Vous pouvez certainement échanger des bibliothèques et résoudre des problèmes. Une meilleure solution consisterait à créer un répondeur automatique Fiddler qui intercepte votre demande et remplace la bibliothèque de production par celle de votre choix. Réfléchissez y un peu. Fiddler prendra la demande de votre URI et le remplacera par un fichier local. Regardons ça.
Tout d'abord, je dois identifier l'URI que je veux remplacer. Dans ce cas, je constate que le thème de mon blog exécute jQuery v1.2.6. C'est fou, mais avant de le laisser tomber et de semer le chaos sur mon site, j'aimerais savoir si jQuery v1.8.3 fonctionne comme prévu.
Je clique sur l'entrée pour jQuery v1.2.6. Dans la colonne de droite de Fiddler, je sélectionne l'onglet "Répondeur automatique" et coche la case "Activer les réponses automatiques". Pour lancer le répondeur, il suffit de faire glisser l’URI dans l’éditeur de règles. Vous remarquerez que cela commence la règle en comparant l'URI. Si cela correspond, il répondra par un événement de votre choix.
Puisque je veux tester jQuery 1.8.3, je veux que la règle permute la version de production avec une copie locale de jQuery que j'ai sur mon ordinateur..
Je sauvegarde la règle et charge de nouveau ma page. Le résultat final est que, bien que l'URI puisse sembler identique, l'inspection des résultats vérifie que jQuery v1.8.3 a bien été injecté, ce qui me permet de le tester à la volée sans apporter de modification au site:
Du point de vue du débogage, je ne saurais trop souligner à quel point cela est utile, en particulier lorsque vous essayez de supprimer un bogue dans les anciennes versions d’un framework ou d’une bibliothèque..
Mon bon ami Jonathan Sampson a réalisé une superbe vidéo sur l'utilisation de cette fonctionnalité..
>La latence du réseau peut être mortelle, en particulier pour les applications d'une seule page.
Fiddler bénéficie d'un écosystème complémentaire étendu qui étend ses fonctionnalités via l'interface iFiddlerExtension. Il y a des add-ons qui permettent:
En soi, Fiddler a une tonne de fonctionnalités - trop nombreuses pour être décrites dans ce post. C'est pourquoi un livre de 330 pages explique comment en tirer le meilleur parti. C'est seulement 10 $ et vous aidera à apprendre les tenants et les aboutissants de cet outil formidable..
Si vous utilisez OSX ou Linux, la meilleure option est le proxy de débogage Charles Web. C'est une application formidable et bien prise en charge, et même si elle est commerciale, elle en vaut la peine. J'ai cherché de bonnes solutions axées sur le développement Web, et Charles s'est vraiment distingué.
L’interface est similaire à celle de Fiddler, mais elle offre deux manières différentes de voir le trafic réseau:
Le style est entièrement à vous. J'ai tendance à pencher vers la vue structurée, car elle se sent un peu plus organisée, mais c'est un peu plus difficile de trouver où se trouve un URI spécifique..
Comme Fiddler, Charles offre également une capacité de répondeur automatique. Cela s'appelle "Map Local…", et vous y accédez en cliquant avec le bouton droit de la souris sur un URI spécifique. Cela vous permet de choisir un fichier local avec lequel travailler..
Lorsque je rechargerai la page, jQuery v1.2.6 sera remplacé par la copie locale de jQuery v1.9 qui se trouvait sur mon ordinateur..
Une autre fonctionnalité intéressante de Charles est sa capacité à limiter les demandes de votre réseau pour simuler des vitesses de bande passante spécifiques. Je me souviens de l'époque des modems 56k et de leurs vitesses fulgurantes. L'utilisation de cette option ramène de bons souvenirs (euh, à droite):
Charles peut également fonctionner sous Windows car il offre une interface utilisateur complète multiplateforme..
J'utilise tous ces outils tout le temps parce que je teste sur tous les principaux navigateurs. Avoir cette capacité facilite vraiment le dépannage. Naturellement, le choix d'utiliser un renifleur basé sur un navigateur ou un proxy basé sur une application physique dépend entièrement de vos besoins en matière de débogage..
S'il vous suffit d'inspecter une partie du trafic et de vérifier les résultats, un renifleur basé sur un navigateur vous conviendra sans doute parfaitement..
D'un autre côté, si vous avez besoin d'un contrôle granulaire de la réponse des URI ou si vous voulez avoir la possibilité de créer des scripts de test personnalisés, alors un outil comme Fiddler ou Charles est l'endroit où vous devez aller. Ce qui est bien, c’est que nous avons des choix solides pour nous aider à le faire, d’autant plus que la complexité de nos projets augmente..
Accentsconagua