Fiddler Everywhere peut être utilisé pour inspecter et déboguer le trafic Web, mais aussi pour vous aider à optimiser les performances de votre site Web en conjonction avec Chrome DevTools et Lighthouse.
L'amélioration des performances Web est une sorte de cri de ralliement depuis un certain temps déjà . Alors que le monde passe à une vision du Web de plus en plus mobile, l'optimisation des expériences pour une bande passante limitée, des tailles d'écran variables et une puissance de traitement minimale est primordiale.
Il n'est pas non plus surprenant que le trafic Web mobile ait éclipsé le trafic de bureau d'environ quatre ans, et a maintenu une avance constante depuis lors:
Certaines fonctionnalités clés des PWA incluent:
- 🏎️ Speed! Les PWA sont réactifs à toutes les interactions des utilisateurs et généralement "sans tracas" [19659008] 😌 De type autochtone. Les PWA se sentent comme t hough ils appartiennent à votre appareil avec une UX attrayante, pratiquement aussi bon qu'une application native
- 🔌 Fonctionnalité hors ligne. Les PWA fonctionnent aussi bien hors ligne qu'en ligne
Alors que nous marchons collectivement vers cette PWA / responsive design / utopie mobile first sur le web, comment travaillons-nous pour optimiser les sites Web existants? Comment mesurons-nous l'impact de l'utilisation d'actifs JavaScript optimisés, d'images compressées et de requêtes réseau combinées? Entrez dans l'onglet Phare 💡🏠 de nos Chrome DevTools !
Lighthouse nous permet de mesurer les performances, l'accessibilité, les meilleures pratiques (par exemple, texte lisible, balises valides, codes de retour réussis), le statut SEO et la préparation PWA de nos applications Web. En utilisant Lighthouse, nous pouvons rapidement itérer sur les changements pour mesurer leur impact sur les performances.
Voyons comment nous pouvons prendre un site Web existant et optimiser ses performances en quelques étapes simples à l'aide de notre outil de débogage Web préféré, Fiddler Everywhere.
Qu'est-ce que Fiddler Everywhere?
Fiddler Everywhere est un proxy de débogage Web pour n'importe quel navigateur, n'importe quel appareil, sur n'importe quelle plate-forme. C'est un outil utilisé pour enregistrer tout le trafic HTTP / S entre votre ordinateur et le monde, inspecter / modifier / répondre à ce trafic, rédiger des requêtes API et violon avec des données entrantes et sortantes.
Vous pouvez ont entendu parler du Fiddler original (Fiddler Classic) dans le passé en tant qu'outil robuste uniquement Windows pour le débogage Web. Fiddler Everywhere s'appuie sur les fonctionnalités de base de Fiddler Classic, mais les intègre avec un nouvel UX et un shell multiplateforme pour une utilisation sur macOS, Windows et Linux.
Our Victim … I Mean Subject!
La plupart des sites Web publics existants ne sont pas des candidats valides pour les PWA, mais je proposerais que la plupart des soient in besoin d'optimisations des performances. Prenons un site Web contenant beaucoup de texte et d'images comme npr.org par exemple.
![npr.org screenshot "data-displaymode =" Original "title =" npr .org screenshot "/> </p>
<p> En regardant rapidement la source de la page, nous voyons de nombreuses balises distinctes <code><script></code> diverses feuilles de style et de grandes images. [19659003] <em> Voici juste un petit exemple: </em></p>
<pre><code><script type=](https://i0.wp.com/d585tldpucybw.cloudfront.net/sfimages/default-source/blog-images/npr-screenshot.jpg?w=660&ssl=1)
Notre première étape consiste à exécuter un test Lighthouse contre npr.org avec les DevTools de notre navigateur (en se concentrant uniquement sur les Option Performance ):
Si j'ouvre Fiddler et rechargez npr.org, nous pouvons avoir une idée du nombre de requêtes réseau et des types d'actifs renvoyés:
![npr.org traffic inspector "data-displaymode =" Original "title =" npr.org traffic inspector "/> </p>
<p> Et ce n'est qu'environ 1/3 du nombre total de requêtes! 🤯 </p>
<p> Ce sur quoi nous devons nous concentrer maintenant, c'est réduire le nombre et la taille de nos requêtes de fichiers JavaScript et CSS à voir si nous pouvons améliorer notre score Lighthouse. </p>
<h2> Réduction de la taille et de la portée des requêtes JavaScript [19659020] Ma première étape serait de voir si nous pouvons combiner et réduire certains de nos actifs JavaScript. Si je filtre par type de requête et que je limite cela aux fichiers <code> .js </code> et <code> .css </code>nous voyons ce qui suit (et plus encore): </p>
<p> <img decoding=](https://i0.wp.com/d585tldpucybw.cloudfront.net/sfimages/default-source/blog-images/npr-traffic-inspector.png?w=660&ssl=1)
J'ai déjà pris le temps de télécharger les images séparément et de les parcourir l'optimiseur TinyPNG. En ajoutant une autre règle de répondeur automatique Fiddler Everywhere, je peux intercepter toutes les demandes d'image et les remplacer par le fichier local du même nom en acheminant le nom de fichier de la demande vers la réponse. Comment faire?
Créez une seule règle de réponse automatique pour faire correspondre n'importe quelle image dans un répertoire spécifique et renvoyer le fichier local optimisé:
MATCH: REGEX :(? Inx). + / Assets / img / (? ' fnom '[^?] *). *
RETOUR: C: src $ {fname}
☝️ cela nous permet de créer une règle qui gère toutes les requêtes à la fois au lieu d'une requête pour chaque fichier image.
REMARQUE: Si vos images sont dispersées dans différents répertoires, cela sera plus fastidieux à accomplir car vous devrez créer des règles de répondeur automatique distinctes pour chaque répertoire. Ou peut-être êtes-vous un expert en regex et pouvez trouver un moyen d'accomplir cela!
Ok, avec notre JavaScript, notre CSS et nos images optimisés, voyons comment nous nous en sortons avec Lighthouse.
Drumroll Please
Mais attendez, il y a un hic!
Lorsque vous exécutez un test Lighthouse, il télécharge un fichier JavaScript pour exécuter ses tests. Donc, si vous bloquez toutes les requêtes contenant .js ... eh bien ... vous empêcherez également Lighthouse de fonctionner! Pour contourner ce problème, recherchez une requête dans le volet de trafic Fiddler Everywhere où le Host contient devtools . Sur Microsoft Edge et Google Chrome, ce sera probablement une référence au fichier lighthouse_worker_module.js .
Téléchargez ce fichier et enregistrez-le localement. Ensuite, créez une autre règle de répondeur automatique en cliquant avec le bouton droit de la souris sur la requête distante dans le fichier lighthouse_worker_module.js et en choisissant Ajouter une règle . Votre règle doit ressembler à quelque chose comme ceci (mais avec un hôte et une chaîne de caractères différents):
MATCH: EXACT: https: //devtools.azureedge.net/serve_file/@602bb6b61c9016b6b9452adf1dc65b2242f501ae/lighthouse_worker/lighthouse_workers_mighthouse_worker/lighthouse_workers
RETOUR: C: src lighthouse_worker_module.js
Assurez-vous simplement que la priorité de cette règle est au-dessus de la règle qui bloque toutes les requêtes JavaScript!
Nous avons créé quelques optimisations assez simples ici, il est donc temps de tester les résultats pour de vrai. Avec les règles de réponse automatique de Fiddler Everywhere en cours d'exécution, nous pouvons recharger npr.org et exécuter à nouveau le test de performance de Lighthouse.
Et ...? 🥁
Source link