Pingdom, YSlow et GTmetrix –

Optimiser les sites web pour la vitesse est un métier, et chaque métier nécessite des outils. Les outils d'optimisation de sites Web les plus utilisés sont GTmetrix YSlow et Pingdom Tools .

GTmetrix est un outil assez avancé qui offre beaucoup à son niveau libre , mais il offre également niveaux supérieurs . Si vous vous inscrivez, vous pouvez comparer plusieurs sites Web, plusieurs versions du même site Web, testé sous différentes conditions et enregistrer des tests pour les consulter plus tard.

YSlow est toujours pertinent, bien que ses meilleurs jours soient ceux où Firebug a régné suprême parmi les inspecteurs de navigateur. Il offre une application Chrome et d'autres implémentations – comme des extensions pour Safari et Opera, un bookmarklet, une extension pour PhantomJS, etc.

Pour les utilisateurs avancés, L'intégration de PhantomJS signifie que l'on peut, par exemple, automatiser les tests de nombreux sites Web – des centaines ou des milliers – et exporter les résultats dans la base de données.

YSlow's Ruleset Matrix

Pingdom Tools est un service SaaS qui offre un suivi et des rapports sur la performance des sites Web et qui a renforcé sa position sur le marché au cours des dernières années. Il offre également un contrôle de santé DNS et un test de vitesse de site Web sur son niveau libre, comparable à GTMetrix et YSlow.

Pour les besoins de cet article, nous avons acheté un nom de domaine approprié – ttfb.review – et installé Drupal avec du contenu de démonstration dessus. Nous avons également installé WordPress le wp.ttfb.review et les installations de démo de Yii et Symfony sur leurs sous-domaines respectifs.

Nous avons utilisé le démarrage par défaut de WordPress installation. Pour Drupal, nous avons utilisé les extensions Devel et Realistic Dummy Content pour générer du contenu de démonstration. Pour Symfony, nous avons utilisé l'application de démonstration Symfony et pour Yii, nous avons utilisé le modèle d'application de base .

De cette façon, nous pourrons comparer ces installations côte à côte. , et signalez les choses qui méritent l'attention.

Veuillez noter qu'il s'agit d'installations de niveau développement, utilisées uniquement à des fins de démonstration. Ils ne sont pas optimisés pour fonctionner en production, donc nos résultats sont susceptibles d'être inférieurs

GTmetrix

Après la connexion (l'inscription est gratuite), nous avons testé les quatre sites de démonstration et comparé les résultats. side-by:

On peut voir que notre installation de Drupal s'est chargée le plus rapidement, alors que l'installation de Yii a pris dix secondes à charger. Cependant, il ne serait pas judicieux de l'utiliser pour tout type de comparaison de technologies, car ce ne sont pas des sites Web prêts pour la production, et les systèmes qui nécessitent plus de connaissances et de travail devraient être en "debug" (ou développement). ) mode. L'autre chose à garder à l'esprit est que pour obtenir des résultats concluants, il est conseillé de répéter les tests à plusieurs reprises. Le système de virtualisation de notre serveur de test est OpenVZ, pour lequel l'allocation des ressources peut être incohérente

On peut voir les statistiques pertinentes:

• nombre total de demandes
• total de la page
• total du chargement

On pourrait dire que ce sont là les principales mesures auxquelles nous devrions prêter attention, la plus importante étant le temps de chargement. Toutes les autres mesures que nous voyons sont des indications utiles pour améliorer notre temps de chargement.

Shaun Anderson de l'agence Hobo SEO du Royaume-Uni a publié un article sur la corrélation entre la vitesse du site et les conversions / Google classement – avec des résultats intéressants.

La chose à garder à l'esprit est que le temps compte le plus.

Cette comparaison peut être vue en ligne sur GTmetrix afin que les lecteurs puissent l'analyser élément par élément.

Le premier ensemble de résultats se trouve dans l'onglet PageSpeed, où nous On peut voir que la seule chose dont se plaint cet algorithme avec notre installation Yii (la plus lente de notre test) est la minification JS (ou, plutôt, l'absence de celle-ci). Drupal est le meilleur, bien qu'il ait la plupart des drapeaux rouges. Si nous prenons la taille de la page en considération, Symfony est le meilleur, avec un poids de page de seulement 507 Ko.

Nous pouvons voir à partir de cet exemple que de simples notes de test ne nous disent pas tout.

onglet, nous voyons des scores plus réalistes:

Mais il est toujours difficile d'attribuer la différence de temps de chargement à l'un de ces éléments. C'est pourquoi nous avons l'onglet Waterfall : il nous montre où est le retard. Comparaison des cascades, faute d'écran immobilier, ne peut que comparer deux résultats côte à côte, donc nous allons comparer les installations Drupal et Yii (meilleur et pire temps de chargement) sur cette page de résultats : [19659003]

Cela nous donne finalement une idée qu'aucun des outils précédents ne nous donnait. Les neuf secondes passées par Yii sont dépensées sur la première requête (principale) pour le HTML du site – pas pour les ressources statiques. Si nous survolons la longue ligne violette du diagramme de Yii, GTmetrix nous expliquera l'anatomie exacte de cette réponse de neuf secondes:

Ici nous pouvons détecter où se situe le problème – dans la phase "Attente", dans la phase de génération de la page, ou pour utiliser un terme plus familier, TTFB Time To First Byte . Cela signifie que le problème réside purement sur notre côté Nginx ou PHP. Les choses que nous pouvons faire à ce sujet sont multiples, et ont beaucoup à voir avec l'application exacte à laquelle nous traitons. Nous devrions vérifier où se situe le problème sur notre backend.

Il peut s'agir d'une application gourmande en ressources, de requêtes de base de données inefficaces, de contraintes de RAM serveur logiciel, etc. Un outil qui peut être utile ici pour surveiller les processus serveur Monit ainsi que des outils et procédures spécifiques à l'application pour diagnostiquer et améliorer le temps de chargement. Deux choses qui amélioreront presque toujours TTFB sont: plus de ressources serveur, et des solutions de mise en cache comme Varnish . Si les ressources statiques étaient le principal coupable, nous devrions accorder plus d'attention aux avertissements sur les onglets PageSpeed ​​ et YSlow gzipping, minification, et peut-être déployer notre site sur un CDN comme Cloudflare .

Une des raisons de la différence entre Drupal et Yii pourrait être le fait que Drupal est livré avec des "batteries incluses", plus prêtes pour la production, alors que Yii est prêt pour de longues

Nous pouvons voir que l'installation de Drupal vient, par défaut, avec certaines solutions de cache activées:

Après avoir bricolé un peu avec Drupal, et jouant avec son modules intégrés et options de configuration comme BigPipe et la mise en cache, nous pourrions réduire le temps de chargement d'une demi-seconde:

Nous voir la comparaison sur GTmetrix .

Sur GTmetrix, nous pouvons comp sont nos tests de la page d'accueil:

Nous pouvons simplement ajouter différents suffixes d'URL de rapport pour les voir côte à côte:

Pour l'onglet Video nous devons activer l'option d'enregistrement vidéo dans nos options Advanced :

(Au fait, nous pouvons voir que dans les tests suivants, le réchauffement du cache de Drupal a réduit le temps de chargement de notre site web de 200 milisecondes.)

Nous avons maintenant une vidéo disponible dans l'onglet Vidéo des résultats:

De cette façon, nous pouvons parfois obtenir visuellement des indices sur les problèmes de chargement ou les goulots d'étranglement. Le système propose également de générer une bande de film de chargement de page.

Dans les tests simples, il y a aussi un onglet Timings qui sépare les phases de chargement et nous donne le temps et l'explication de chaque phase, comme le Time Au premier octet que nous avons mentionné plus tôt:

(Ceci est le ttfb.review de la charge d'une seconde de Drupal.)

L'onglet Historique sur les rapports d'une seule page sont pour les pages surveillées, ou plusieurs tests dans le temps, où nous pouvons voir nos progrès:

Pour les comparaisons, nous avons les graphiques tab:

D'autres paramètres peuvent être trouvés dans la barre latérale hors-canvas:

En répétant les tests, Au cours de l'écriture de cet article, nous avons vu le temps de chargement de l'application Yii tomber à 1,2 secondes, et Symfony à 1,6 secondes. 9659003] Avec Symfony, un coup d'œil sur l'onglet History montre que TTFB est resté le même, et l'amélioration de 400 millisecondes est probablement due à la différence de chargement des ressources statiques:

Mais les deux graphiques suivants montrent qu'il n'y avait rien à revendiquer pour l'amélioration de la vitesse, à l'exception du meilleur débit du réseau:

Avec Yii, l'amélioration est plus radical dans les trois métriques, TTFB, onload et temps complètement chargé:

Ici, les améliorations sont accidentelles et dues soit à la surcharge du serveur ou au débit du réseau, mais aussi nous effectuons des changements sur notre site Web, et nous améliorons à travers ces différentes métriques, nous serons en mesure de suivre nos progrès dans l'onglet Histoire .

GTmetrix a beaucoup plus d'options, et cela dépasse le cadre d'un article. Par exemple, même sur le plan gratuit, nous pouvons tester avec des navigateurs mobiles ou de bureau, et nous pouvons simuler la vitesse du réseau du visiteur – ADSL, 3G, etc.

Nous pouvons également tester le site depuis différents endroits du globe :

Cela peut être utile lorsque nous attendons des visiteurs de plus d'une région, ou lorsque nous mesurons l'impact de l'implémentation d'un CDN dans notre pile. La latence du réseau peut faire quelques secondes de différence dans le temps de chargement d'un endroit sur le globe à l'autre.

YSlow

YSlow, avec son ensemble de règles, vient du travail des développeurs de Yahoo . Il est devenu un outil de performance web important principalement comme un add-on Firebug, mais cela a été rendu obsolète avec Firefox Quantum.

Il est toujours disponible en tant que bookmarklet une extension Safari un outil de ligne de commande ou une application Chrome :

Nous pouvons sélectionner un ensemble de règles à appliquer, définir la rigueur des critères, puis obtenir des résultats sous Grade avec des notes par items, de A à F, avec des explications et des liens pour chaque item / dimension. [19659003Dansl'onglet Grade nous pouvons filtrer nos résultats. Par exemple, avec notre application Yii, en filtrant les résultats à ceux qui appartiennent au Server nous voyons ceci:

Ceci nous donne un aperçu rapide des choses que nous pouvons améliorer en ajustant nos paramètres de serveur – gzipping le contenu, définissant les en-têtes Expires, déployant le site Web sur un CDN, etc.

Chacune des recommandations / notes YSlow nous donne une brève explication, et un lien vers En savoir plus sur le sujet

L'onglet Composants donne un aperçu de toutes les ressources ou URL chargées pendant le chargement de la page, y compris la page elle-même, JS, CSS, images, leurs tailles, compressées tailles, cookies, en-têtes envoyés

Dans le cas de notre application démo Yii, par exemple, nous pouvons voir dans notre onglet Composants que nous ne compressons pas correctement notre JS (la taille est la même comme non compressé), ni la définition des en-têtes Expires – ce qui devrait être fait dans une application de production:

Plus sur les critères et les règles peuvent être trouvés ici .

L'onglet Statistiques a un excellent aperçu de tous les éléments que composent la page, le pourcentage dans le poids total de la page, et la vue d'ensemble de la même chose avec un cache de navigateur amorcé . C'est quelque chose que nous pouvons manipuler avec l'en-tête Expires . GTmetrix a un article sur l'entête Expires . Cette dimension de performance affecte les visiteurs répétés – ceux qui, en raison de notre instruction Expires envoyée au navigateur de notre visiteur, ont les ressources statiques conservées dans le cache du navigateur pour des visites répétées pendant un certain laps de temps.

Sur le site YSlow , il y a un guide plus détaillé sur chacun des 23 critères qu'il utilise pour classer les sites Web testés, avec d'autres conseils pour l'optimisation.

Pingdom offre un ensemble complet d'outils, à la fois pour le contrôle de santé DNS et pour les tests de pleine page.

Après avoir fait le test et obtenu un bref aperçu, plus bas sur la page du rapport nous avons des recommandations détaillées sur l'amélioration de notre temps de chargement:

Nous pouvons voir ici les recommandations concernant les en-têtes Expires dont nous avons parlé plus haut, entre autres choses

, nous pouvons inspecter nos réponses HTTP, et si nous avons des redirections problématiques, ou des réponses invalides (dans le cas où certaines des ressources ne se sont pas chargées):

Dans le cas d'un autre site de production nous avions testé – un site très lourd en ressources avec beaucoup de ressources statiques – les résultats ressemblaient à ceci:

Retour à notre installation de test Drupal sur http: // ttfb. avis, Pingdom nous donne – plus bas sur la page des résultats – une répartition du contenu par type, poids et pourcentage:

Dans le cas du site web très riche en ressources, nous testé (nous n'avons pas laissé l'URL visible, car c'est un mauvais exemple de site web en cours de production), nous pouvons voir les parties problématiques: une vidéo massive, Google Maps, un widget de discussion par un fournisseur externe :

Retour à l'accueil r Site Drupal, Pingdom nous permet de disséquer toute la charge de la page, demande par requête, nous permettant de voir quelles requêtes / réponses constituent le plus de notre temps de chargement:

Ensuite, par couleurs, nous pouvons décomposer les phases de chaque demande / réponse et localiser les goulots d'étranglement, soit en supprimant les ressources les plus coûteuses, soit en les compressant, en réduisant le JS et le CSS, ou en les déployant sur un CDN.

Nous pouvons également les combiner si possible pour réduire le nombre de requêtes, ou implémenter le protocole HTTP / 2 qui permet un chargement plus asynchrone et non bloquant des ressources.

Dans le cas de notre site web Drupal, puisque nous avons mis en place les paramètres DNS du domaine à partir de zéro, lorsque nous avons commencé à écrire cet article, nous avons défini le A record de notre domaine. TTL – Temps de vie ou enregistrement de domaine temps de mise en cache – à 1 minute, en essayant d'accélérer le déploiement de notre domaine. Pour réduire le ping, la partie DNS de la première requête, nous augmenterions le temps de TTL une fois que le domaine est configuré au maximum. De cette façon, le paramètre de domaine serait mis en cache et il n'y aurait pas besoin de recherche DNS approfondie du domaine.

Chacune de ces requêtes possède un bouton déroulant sur la droite, et en cliquant dessus, nous obtenons un aperçu des en-têtes de chaque requête et réponse :

Ici, nous pouvons déboguer si une requête est mise en cache sur le serveur, si le contenu est mis en cache, etc.

Avec un site web déployé sur Cloudflare, par exemple , nous pouvons voir à partir des entêtes d'une ressource que cf-cache était HIT – ce qui signifie que la ressource est mise en cache, nous pouvons voir qu'elle est gzippée, les en-têtes expires sont définis, ainsi que le cache En-têtes de commande:

Sur un site Web déployé par Cloudflare, on peut voir sur notre carte Pingdom en cascade, les téléchargements de ressources sont plus parallèles, asynchrones et non bloquants. Cela peut également être réalisé en configurant notre serveur pour utiliser le protocole HTTP / 2:

(Il n'y a pas d'attente pour qu'un cycle de requête / réponse se termine pour le suivant begin.)

Une amélioration peut être obtenue avec des ressources de préchargement .

Avec Pingdom, comme avec GTmetrix, nous pouvons choisir l'emplacement à partir duquel tester. Nous avons essayé de tester notre installation de démonstration Yii, http://yii.ttfb.review, en Suède (les précédents tests GTmetrix ont été effectués à Vancouver, Canada), et la différence est évidente. Notre site Web a maintenant pris 445 millisecondes à charger:

Dans ce cas, nous voyons aussi que la latence du DNS prend peut-être plus que ce qu'elle devrait. Nous devrions réduire le paramètre TTL DNS, et les parties bleues sur les ressources statiques sont la phase "Connect" donc nous pouvons supposer que HTTP / 2 avec ses améliorations keepalive serait en mesure de tirer parti d'une seule connexion pour pousser toutes ces ressources, sans la surcharge d'établir une nouvelle connexion TCP pour chaque ressource :

Le chemin le plus simple ici serait probablement, encore une fois, un La latence du DNS est encore plus visible lorsque nous testons en Californie:

Nous pouvons supposer que résoudre le problème DNS et servir les ressources statiques plus efficacement réduire le temps de chargement d'un tiers.

Pingdom offre des solutions de surveillance premium similaires à GTmetrix. Il peut surveiller le temps de fonctionnement, envoyer des alertes, surveiller les temps de chargement moyens, etc.

Fichiers HAR

GTmetrix et Pingdom nous permettent d'exporter des fichiers HAR. HAR – ou Fichiers au format HTTP Archive – sont des fichiers d'archive au format JSON pour la journalisation de l'interaction d'un navigateur Web avec un site . Nous sommes attachant un fichier HAR de notre test GTmetrix de l'installation de test WordPress (qui a beaucoup de problèmes à déboguer, soit dit en passant).

Ce fichier est un standard

Ce fichier peut être importé en Har Analyzer de Google :

Cela peut ensuite être analysé plus en détail, partagé, etc.

D'autres outils qui méritent d'être mentionnés sont Temps de chargement de la page pour Chrome qui fonctionne comme un widget de navigateur soigné avec de courtes statistiques de chargement:

[19659003] Ensuite, il y a le test de vitesse web Dotcom Tools :

Il propose 24 emplacements de tests, puis des graphiques détaillés en cascade pour chacun.

Il y a aussi PageSpeedGrader :

Amis Les aperçus PageSpeed ​​de gle sont un autre outil que nous pouvons utiliser pour obtenir des idées et des recommandations sur les améliorations possibles et les meilleures pratiques, à la fois pour les visiteurs mobiles et de bureau:

New Relic DataDog et d'autres outils liés au serveur comme Monit – outils avancés, mais un peu plus envahissant en ce qui concerne l'infrastructure du serveur.

Tonino est un développeur web et informatique consultant qui a plongé à travers le code open-source pendant plus d'une décennie. Il est aussi un passionné de crypto, un fan de Linux et un libertaire modéré.