Il existe de nombreux outils en ligne pour mesurer la performance d’un site web. Pingdom Tools fait partie de ces outils incontournables, qui propose un scan sur l’état de santé de votre site WordPress. Pour checker la performance de votre site web et notamment sa vitesse, voici l’url : Pingdom Tools
Sur cette page web, il faut renseigner l’url de votre site ainsi que la localité du serveur de test. Dans le menu “Test from”, vous avez le choix entre plusieurs localités (Dallas, Melbourne, New York, San José et Stockholm). Pour une qualité de scan optimal, je vous invite à choisir comme serveur de test : Stockholm.
Vous trouverez par la suite un rapide récapitulatif de votre scan :
Dans ce sommaire, on peut voir :
- Performance grade : c’est la note globale de votre site WordPress. Cette note est située entre A et F et chiffrée entre 0 et 100
- Load time : temps de chargement complet de la page testée
- Faster than : c’est une valeur informative en pourcentage de la vitesse de votre site, comparé aux sites testés sur pingdom tools
- Page size : poids de la page testée
- Requests : nombre de requêtes nécessaires pour la page
- Tested from : localité du serveur de test
En scrollant, vous trouverez ensuite un rapport plus détaillé de votre site web :
Dans ce tableau, vous pouvez voir une note en lettre (A à F) et en chiffre (0 à 100) correspondant à une suggestion technique. Pour chaque suggestion vous pouvez voir une description détaillée en cliquant sur la flèche :
- Remove query strings from static resources : les “query strings” sont des urls contenant ce genre de caractères : “&” et “?”. Les feuilles de styles css ainsi que les scripts js peuvent parfois générer ce genre d’url. Voici un exemple d’une “query string”
/wp-includes/css/dashicons.min.css?ver=4.4.2
ces urls peuvent nuire aux performances de votre site web. Comme bien souvent dans le web, plusieurs solutions existent pour résoudre cette contrainte.
La première solution est d’ajouter dans votre functions.php, le code suivant :
Ce bout de code supprime les “query strings” des feuilles de styles et des scripts js associées à votre site web. Par exemple, Chez WPServeur, un mu-plugin est alloué à la suppression des “query strings” :) !
La deuxième solution est d’utiliser un plugin de cache. Certains plugins de cache possèdent l’option pour supprimer les “query strings”. Le plugin W3 total cache propose cette option
La troisième solution est d’opter pour un plugin spécifique pour supprimer cette contrainte technique. Dans le repository on peut trouver quelques plugins pour résoudre cette problématique. Cependant, quelques extensions ne sont pas compatibles avec la dernière version de WordPress. Un seul plugin possède une version compatible avec WordPress 4.7.1 : Remove Query Strings
- Leverage browser caching : le leverage browser caching vous donne des indications pour exploiter la mise en cache navigateur. Un plugin de cache peut ajouter cette fonctionnalité ainsi qu’un bon réglage serveur
- Serve static content from a cookieless domain : pingdom tool vous donne un aperçu des ressources statiques ne proposons pas de cookies
- Avoid bad requests : pour cette suggestion, pingdom tool indique que le réglage de votre serveur bloque les requêtes malicieuses.
- Minimize redirects : les redirections sont indispensables afin de diriger l’internaute vers un nouveau contenu en toute transparence. Cependant un trop grand nombre de redirections peu nuire aux performances. Pingdom tool vérifie les redirections présentes sur votre site
- Minimize request size : pour gagner en performance, il est possible de réduire au maximum la taille des cookies et des headers afin que la requête HTTP soit transmise en une seule fois
- Specify a cache validator : les validateurs de cache sont importants car ils déterminent si votre demande doit être envoyée ou non au serveur ou alors directement récupérée à partir de votre cache navigateur. Ces validateurs de cache sont des réglages serveurs
- Specify a Vary : Accept-encoding header : cet autre réglage serveur permet d’accepter les compressions gzip, deflate transmis au client
Par la suite, vous avez le code HTTP retourné par le serveur. Pour le scan, ce code est 200. Cela signifie que la requête est traitée avec succès. Il existe de nombreux code HTTP donnant des informations précises sur le traitement de la requête. Un article de Wikipédia, liste tout les codes de statut disponible : code HTTP
Ensuite vous avez à votre disposition des informations sur la taille de votre contenu par type :
Ces données sont intéressantes. En un clin d’œil vous pouvez voir le type de contenu volumineux sur votre site web. Ces valeurs vous donne des pistes futures de travail :). Pour ce site web, on peut remarquer que les images représentent 75% du poids de la page web scannée. Pour afficher ces images, 17 requêtes sont nécessaires. Instructifs non ?
Le même genre de donnée est disponible mais cette fois ci par domaine :
Ces datas mettent en avant le poids de votre contenu par domaine. Pour faire vivre un site web, plusieurs domaines peuvent rentrer en jeu. Pour chaque domaine, vous avez le pourçentage d’importance dans le site ainsi que le poids assigné à ce domaine. Vous avez également le même tableau mais cette fois-ci avec les requêtes nécessaires pour chaque domaine.
- La donnée n°1 correspond au nom de domaine principal du site web
- La donnée n°2 correspond au CDN bootstrap permettant l’affichage de Font Awesome
- La donnée n°3 correspond à google analytics, outil statistique de google
- La donnée n°4 correspond au CDN pour l’utilisation de jQuery
- La donnée n°5 correspond au font de google
Le dernier tableau de votre scan, est un graphique mettant en avant le temps de chargement pour chaque url présente dans votre site web :
Plusieurs choses sont disponibles dans ce tableau très complet. Tout d’abord, vous pouvez filtrer les recherches en choisissant parmi les valeurs suivantes :
- Load order : classement par ordre des chargements
- File size : classement par le poids
- File type : classement par le type de ressource
- URL : classement par urls
- Load time : classement par les ressources les plus consommatrices de données
Un champ de recherche personnalisé est également mis à votre disposition.
Ce graphique montre le temps de chargement pour chaque ressource utilisée pour ce site web. Pingdom tools, est capable de ressortir les temps de chargement pour les paramètres suivants (voir chiffre 1 sur l’image) :
- DNS : temps de chargement pour que le navigateur recherche les informations DNS du nom de domaine principal
- SSL : temps de chargement pour que le navigateur exécute le certificat SSL du site si il est présent
- Send : temps de chargement de l’envoi de donnée au serveur par le navigateur web
- Wait : temps d’attente des données avant le retour serveur
- Receive : temps de réponse du serveur au navigateur web
- Connect : temps de connexion au serveur au navigateur web
Vous pouvez voir le temps de chargement pour chaque data proposée par pingdom tools, en survolant avec la souris le graph. La flèche présente sur la même ligne (voir chiffre 2 sur l’image) permet d’ausculter plus précisément la réponse du serveur inscrite dans le header.
Par exemple pour le nom de domaine principal pour ce site web, voici les informations qu’on peut trouver :
Le site est présent chez WPServeur, il bénéficie donc du cache varnish natif ainsi que d’un serveur NGINX.
Avec Pingdom Tools, vous pouvez réellement scruter les entrailles et les temps de chargement de votre site web avec beaucoup de précision. Très pratique pour trouver des axes d’améliorations sur son site web.
Des solutions alternatives à Pingdom tools existent. Voici une liste de ces testeurs de performance :
- GTmetrix
- GeekFlare
- Dareboost
- PageSpeed Tools
- Testmysite with google (pour tester votre site en version mobile)
Bons tests à tous ;) !
@Dewy Mercerais,
Bonjour, j’ai testé la “version” code, effectivement le temps de réponse à été divisé par 100…..mais avec une page blanche et un code 500….pas terrible…
C’est peut-être un peu radical comme façon de faire….
Aurais-je du adapter ce code, et si oui de quel façon ?
(bon après restauration de mon fichier “functions.php”, tout est rentré dans l’ordre…)
Merci pour l’article!
Depuis peu wp rocket propose un réglage supplémentaire afin de supprimer les query string justement, très pratique!
Bonjour,
bon mon commentaire est noté comme “pertinent” !
Ce que , personnellement, je trouverais pertinent…..c’est une réponse…
Blague à part, c’est vrai…j’aimerais que vous m’éclairiez sur le problème : pourquoi une page blanche et un code “500”quand j’utilise ce code dans mon fichier “functions.php” ?
@greg Merci pour l’info :) !
@broussaille Pour trouver la cause de votre erreur 500 ou autres erreurs vous pouvez voir avec vos logs afin de déterminer la source de votre problème. Voici un article sur WPFormation qui donne la marche à suivre pour utiliser les logs dans un site WordPress : https://wpformation.com/incompatibilite-plugin-theme-wordpress/. Avec le plugin WP log viewer, toutes les erreurs seront affichées dans votre back office :) !
mais vous avez pratiquement trouvé la solution. En restaurant votre fichier functions.php, tout rentre dans l’ordre. Il doit avoir une erreur PHP, dans ce fichier, qui retourne une erreur fatale
Il est vrai que les rapports de Pingdom sont assez détaillés. Ce qui est malgré tout une bonne chose. Et savoir les lire est donc important. Forcément.
Maintenant, avec un bon plugin de cache, comme WP Rocket sur WordPress, je pense que l’usage d’outils comme Pingdom est moins primordial qu’à une époque. Du moins pour un éditeur de sites traditionnel. Pingdom ne sert alors qu’à s’assurer qu’il y a bien un gain avec le plugin ou les paramètres de son site.
D’ailleurs, concernant WP-Rocket, je n’avais pas vu ce réglage supplémentaire pour supprimer les query string. Pratique :-)