Outil de test de vitesse Pingdom : Guide ultime pour 2024

Aujourd’hui, nous voulons voir la façon de mieux utiliser et comprendre les données du populaire outil de test de vitesse de sites Web Pingdom. Vous pouvez l’utiliser pour faire ce que nous appelons une analyse en cascade (aussi appelée Waterfall) de votre site WordPress. Cela peut vous aider à diagnostiquer rapidement les problèmes de performance et à ne pas mal diagnostiquer un problème.

Souvent, nous voyons des utilisateurs de WordPress interpréter les données incorrectement dans l’outil de test de vitesse Pingdom, ce qui conduit parfois à configurer un site Web dans un état encore pire qu’avant. Rappelez-vous que tous les outils comme celui-ci doivent être utilisés comme guides, ils ne sont jamais précis à 100%. L’important est d’être cohérent et d’utiliser le même outil tout au long de vos tests.

Pingdom

Pingdom est une société basée en Suède (aujourd’hui détenue par SolarWinds) qui offre une variété de services différents, tels que la surveillance du temps de disponibilité, la surveillance de la vitesse des pages, la surveillance des transactions, la surveillance des serveurs et l’analyse des visiteurs (RUM). Probablement l’une des choses pour lesquelles ils sont les plus connus est leur outil gratuit de test de vitesse de site Web. C’est l’un des outils de test de performances les plus populaires dans la communauté WordPress.

Pourquoi est-il si populaire ? Eh bien, pour commencer, c’est probablement l’outil de test de vitesse le plus facile à utiliser ! Tout le monde n’est pas un expert des performances Web, et donc pour l’utilisateur WordPress typique, certains des autres outils alternatifs disponibles peuvent être assez écrasants.  Après tout, vous ne vous souciez que de deux choses : à quelle vitesse charge votre site Web et comment pouvez-vous le rendre plus rapide.

Pingdom vous permet actuellement de tester la vitesse de n’importe quel site Web à partir de 7 emplacements différents (5 continents) stratégiquement placés autour du globe :

• Asie – Japon – Tokyo
• Europe – Allemagne – Francfort
• Europe – Royaume-Uni – Londres
• Amérique du Nord – USA – Washington D.C.
• Amérique du Nord – USA – San Fransisco
• Pacifique – Australie – Sydney
• Amérique du Sud – Brésil – São Paulo

Remarque : Nous avons remarqué qu’il arrive parfois que tous les lieux de test ne soient pas disponibles. C’est probablement parce qu’il a été mis hors service pour maintenance ou parce qu’il a été surchargé par trop de personnes essayant d’effectuer des tests dessus. Si l’emplacement d’un site d’essai que vous avez utilisé n’est plus là, revenez dans une heure ou deux. Il réapparaîtra très probablement.

Le lieu de test que vous choisissez est en fait très important car il est lié à l’emplacement physique de l’endroit où votre site Web est réellement hébergé. C’est là qu’une petite chose appelée latence du réseau entre en jeu. Mais nous y reviendrons plus en détail ci-dessous.

Analyse waterfall avec l’outil de test de vitesse Pingdom

Une page Web se compose de différentes ressources, telles que HTML, JavaScript, CSS, images et vidéos. Chacune d’entre elles génère des requêtes pour afficher ce que vous voyez sur votre site web. Généralement, plus vous avez de demandes, plus votre site Web se chargera lentement. Ce n’est pas toujours le cas, mais c’est vrai la plupart du temps.

Ci-dessous, nous allons diviser chaque section de Pingdom et expliquer plus en détail ce que l’information signifie par rapport à la performance globale de votre site web et comment faire une analyse de cascade.

• Résumé de Pingdom
• Aperçu des performances Pingdom
• Codes de réponse
• Taille du contenu et demandes par type de contenu
• Taille du contenu et demandes par domaine
• Tableau en cascade (Waterfall)
• Étude de cas de configuration de domaine

Résumé de Pingdom

Lorsque vous testez votre site Web WordPress via Pingdom, il génère une note de performance, un temps de chargement total, la taille totale de la page, et le nombre de requêtes que vous avez sur votre site. Dans notre exemple, nous utilisons perfmatters.io, un site de eCommerce utilisant Easy Digital Downloads. Il est hébergé sur les serveurs rapides de Kinsta.

Comme vous pouvez le voir, nous avons fait notre premier test et nous avons obtenu un score de 88/100 sur Pingdom et le temps total de chargement est de 541 ms. Il nous permet de connaître la taille totale de nos actifs combinés et le nombre de demandes.

Nous avons ensuite effectué un test supplémentaire et maintenant notre temps de chargement total est de 392 ms avec la même taille de page et le même nombre de requêtes ! Qu’est-ce que c’est que tout ça ? 🤔 Vous le remarquerez peut-être si vous utilisez l’outil de test de vitesse Pingdom plusieurs fois sur votre site Web. Les sites plus grands remarqueront des différences encore plus grandes.

Il y a trois raisons principales à cela : La mise en cache des DNS, le CDN et WordPress. C’est pourquoi vous devriez toujours effectuer des tests plusieurs fois. Bien entendu, les appels externes vers des ressources tierces et des APIs peuvent également avoir un impact. Découvrez pourquoi ci-dessous dans notre analyse waterfall.

Vous voulez obtenir un meilleur score Pingdom sur votre site WordPress ? Selon votre site et votre configuration, il n’est pas toujours possible d’obtenir un score parfait de 100/100, mais le simple fait de passer un peu de temps à améliorer votre score est un bon point de départ.

Et parfois, l’expérience de l’utilisateur peut éclipser certaines des astuces de performance Web que vous lisez sur le Web. Vous ne pouvez pas oublier l’expérience utilisateur ! Mais rassurez-vous, nous partagerons avec vous quelques trucs et astuces ci-dessous sur la façon dont nous avons obtenu le site ci-dessus à l’endroit où il est, alors continuez à lire !

Aperçu des performances Pingdom

Dans la section Performances, « Améliorer les performances des pages » a été mise à jour en 2018 et ils ont supprimé quelques anciens éléments et en ont ajouté de nouveaux. C’est très probablement parce que certaines des suggestions qu’ils ont rapportées ne sont plus aussi pertinentes qu’avant. Lorsqu’il s’agit d’optimiser les performances du Web, les choses changent constamment. Et cela peut être parfois gênant si les gens essaient simplement de courir après le score parfait de Pingdom.

Cependant, nous laissons cette section complète dans notre article parce qu’il est important de comprendre comment ces scores sont calculés. Ceux-ci sont essentiellement tous basés sur les règles de Google PageSpeed Insight. En général, si vous les améliorez sur votre site, vous devriez constater une diminution de vos temps de chargement globaux.

Voici quelques-unes des catégories qui constituaient auparavant la section sur les améliorations de performance :

• Use a Content Delivery Network (CDN)
• Avoid HTTP 404 (Not Found) error
• Minimize Redirects
• Add Expires Headers
• Remove Query Strings From Static Resources
• Use Cookie-Free Domains
• Parallelize Downloads Across Hostnames
• Specify a Cache Validator
• Specify a Vary: Accept-Encoding header

Examinons maintenant quelques-unes de ces questions et voyons lesquelles sont encore pertinentes aujourd’hui.

Use a Content Delivery Network (CDN)

Un des services les plus importants à implémenter sur notre site WordPress aujourd’hui est un Réseau de Difusion de Contenu (CDN). These are a network of servers (also known as POPs) located around the globe. They are designed to host and deliver copies of your WordPress site’s static (and sometimes dynamic) content such as images, CSS, JavaScript, and video streams.

Il s’agit d’un réseau de serveurs (également connus sous le nom de POPs) situés dans le monde entier. Ils sont conçus pour héberger et fournir des copies du contenu statique (et parfois dynamique) de votre site WordPress, comme des images, du CSS, du JavaScript et des flux vidéo.

Si vous êtes un client Kinsta, nous incluons un CDN sur tous nos plans d’hébergement. Son activation se fait en quelques clics. Parmi les avantages d’un CDN, mentionnons l’augmentation des performances (réduction du TTFB et de la latence réseau), la réduction des coûts de bande passante et d’hébergement, et même des avantages SEO.

Les clients de Kinsta peuvent également profiter d’un coup de pouce rapide et facile à l’optimisation globale du site en minifiant votre code à l’aide de la fonction de minification du code intégrée au tableau de bord MyKinsta. Cela permet aux clients d’activer la minification automatique de CSS et JavaScript d’un simple clic, accélérant ainsi leurs sites sans aucun effort manuel.

Important : L’outil Pingdom récemment mis à jour a actuellement un bug qui détecte correctement tout fournisseur de CDN avec précision.

Voici quelques fournisseurs CDN tiers que nous recommandons :

• KeyCDN (CMest lui qui propulse le CDN Kinsta)
• Cloudflare
• StackPath
• CDN77

Dans nos tests de vitesse CDN, nous avons vu que le CDN peut diminuer le temps de chargement d’une page jusqu’à 50% dans certains cas !

Éviter l’erreur HTTP 404 (not found)

Cette section s’appelait précédemment « Avoid Bad Requests » et c’est toujours pertinent ! Cet avertissement est exactement comme il paraît, c’est une demande qui n’a pas pu être complétée avec succès. Cela se produit généralement lorsque vous créez manuellement un lien vers une ressource ou une image qui a été supprimée depuis, ce qui entraîne une erreur 404. Ceci apparaît sous la forme d’un cercle orange dans Pingdom, avec un 404 sur l’état de l’en-tête de réponse.

Assurez-vous toujours que chaque requête sur votre site revient avec un statut de succès. Cela garantira qu’il n’y a pas de requêtes générées vers des ressources qui n’existent plus.

Minimize Redirects

Too many redirects sont toujours quelque chose à quoi il faut faire attention. Des redirections simples comme une simple redirection 301, HTTP vers HTTPS, ou www vers non-www (vice versa) sont acceptables. Et bien souvent ces dernières sont nécessaires dans certaines parties de votre site Web. Cependant, chacune a un coût sur la performance de votre site. Et si vous commencez à empiler les redirections les unes sur les autres, il est important de vous rendre compte de leur impact sur les performances de votre site. Cela s’applique aux redirections de pages et d’articles, aux redirections d’images, à tout.

Une redirection apparaît sous la forme d’un cercle bleu dans Pingdom, avec un 301 ou 302 sur l’état de l’en-tête de réponse.

Dans quelle mesure les redirections ont-elles un impact sur votre site ? Faisons un petit test. Tout d’abord, nous effectuons un test de vitesse sur notre page Contactez-nous :https://perfmatters.io/contact/. Comme vous pouvez le voir ci-dessous, nous obtenons un temps de chargement total de 417 ms.

Nous modifions ensuite légèrement l’URL et effectuons un autre test de vitesse pour voir l’impact des redirections multiples. https://perfmatters.io/contact/ . Comme vous pouvez le voir, il faut maintenant 695 ms pour charger la même page. C’est une augmentation de 66%. Aïe !

Consultez notre article détaillé sur les redirections WordPress et les meilleures pratiques pour des performances plus rapides.

Add Expires Headers

Un avertissement très courant auquel les gens sont confrontés est Leverage Browser Caching. Pour l’exprimer en termes simples, chaque script de votre site WordPress doit être accompagné d’un en-tête de cache HTTP (ou devrait l’être). Ceci détermine quand le cache du fichier expire. Pour résoudre ce problème, assurez-vous que votre hébergeur WordPress possède les en-têtes cache-control appropriés et qu’il possède la configuration pour expire . Kinsta a ces en-têtes en place sur tous ses serveurs. Consultez les étapes permettant d’ajouter manuellement des en-têtes de mise en cache à votre serveur et lisez notre guide sur l’ajout d’en-têtes d’expiration.

L’autre problème est que lorsque vous chargez des scripts tiers, vous n’avez pas accès pour ajouter les en-têtes de mise en cache, car vous n’avez aucun contrôle sur leurs serveurs Web. Les coupables les plus courants sont le script Google Analytics et les pixels marketing, comme Facebook et Twitter. Pour résoudre ce problème, vous pouvez héberger votre script Google Analytics localement (bien que cela ne soit pas officiellement supporté) avec un plugin comme Perfmatters. WP Rocket a maintenant une option pour héberger votre pixel de marketing Facebook localement.

Déplacer des scripts localement peut varier en termes d’impact sur les performances de votre site. Le seul avantage est que vous avez alors un contrôle total sur le fichier et que vous pouvez le servir à partir de votre propre CDN. Ceci supprime également une autre requête DNS tierce. Cependant, il est également important de se rappeler que ces fichiers peuvent déjà être mis en cache dans les navigateurs des gens.

Consultez notre article détaillé sur la façon de corriger l’avertissement Leverage Browser Caching.

Remove Query Strings From Static Resources

Un autre problème courant est le traitement des chaînes de requête. Vos fichiers CSS et JavaScript ont généralement la version du fichier à la fin de leur URL, comme https://domain.com/file.min.css?ver=4.5.3.  Certains serveurs et serveurs proxy sont incapables de mettre en cache les chaînes de requête (Query Strings). Ainsi, en les supprimant, vous pouvez parfois améliorer votre mise en cache.

Vous pouvez utiliser un plugin premium comme Perfmatters qui possède une option pour supprimer les chaînes de requêtes en un clic.

Ou vous pouvez ajouter manuellement le code suivant au fichier functions.php de votre thème. Une meilleure alternative serait d’utiliser un plugin gratuit comme Code Snippets pour ajouter le code. De cette façon, vous n’avez pas besoin d’éditer directement votre thème.

function remove_query_strings() {
if(!is_admin()) {
add_filter('script_loader_src', 'remove_query_strings_split', 15);
add_filter('style_loader_src', 'remove_query_strings_split', 15);
}
}
function remove_query_strings_split($src){
$output = preg_split("/(&ver|\?ver)/", $src);
return $output[0];
}
add_action('init', 'remove_query_strings')

Cependant, avant d’effacer immédiatement les chaînes de requête sur votre site, il est important de savoir pourquoi les chaînes de requête sont utilisées. Le versioning sur fichiers est généralement utilisé par les développeurs WordPress pour contourner les problèmes de cache.

Par exemple, s’ils sortent une mise à jour et changent le fichier style.css de ?ver=4.6 à ?ver=4.7, il sera traité comme une URL complètement nouvelle et ne sera pas mis en cache. Si vous supprimez les chaînes de requête et mettez à jour un plugin, la version mise en cache pourrait continuer à être servie. Dans certains cas, cela pourrait casser l’apparence de votre site jusqu’à ce que la ressource en cache expire ou que le cache soit complètement vidé.

De plus, certains CDNs peuvent mettre en cache des chaînes de requête. Le CDN Kinsta peut le faire et le fait par défaut. Ainsi, si vous êtes un client Kinsta, les chaînes de requête sont déjà mises en cache sur vos ressources.

Consultez notre tutoriel détaillé sur la façon de supprimer les chaînes de requête des ressources statiques.

Serve Static Content From a Cookieless Domain

Nous avons un article détaillé sur la façon de traiter l’avertissement sur le contenu statique d’un serveur servi à partir d’un domaine sans cookie. Souvent vous pouvez ignorer cet avertissement car les nouveaux protocoles tels que HTTP/2 rendent cela moins important. Le coût d’une nouvelle connexion est généralement plus élevé que celui de la diffusion en continu sur la même connexion. Cependant, deux façons de résoudre ce problème sont d’utiliser un fournisseur CDN qui supprime les cookies ou de créer un domaine et/ou sous-domaine séparé.

Compresser les composants avec GZIP

L’avertissement « Compresser les composants avec GZIP » se produit quand Pingdom détecte une ressource qui n’a pas été compressée avec GZIP. GZIP est une méthode de compression utilisée pour réduire la taille des fichiers texte comme les documents HTML et les fichiers CSS/JS. La compression GZIP est activée sur le serveur, et compresse les pages web et les ressources avant de les envoyer à un visiteur. Nos tests ont montré que l’activation de la compression GZIP réduisait la taille du fichier d’une requête de plus de 78%.

Chez Kinsta, vous n’aurez pas à vous soucier d’activer GZIP manuellement car il est déjà activé par défaut sur tous nos serveurs. Si vous remarquez que votre hébergeur n’a pas activé GZIP, nous vous recommandons de contacter son équipe de support pour l’activer immédiatement car cela peut avoir un impact énorme sur la vitesse de votre page. Si vous voyez encore la mention « Compresser les composants avec GZIP » après avoir activé GZIP sur votre serveur, il est possible qu’un serveur hébergeant un élément externe requis par votre site n’ait pas activé GZIP. Si c’est le cas, vous ne pouvez rien faire de votre côté pour modifier le comportement du serveur.

Parallelize Downloads Across Hostnames

L’avertissement « Parallelize Downloads Across Hostnames » résulte d’une limitation de HTTP/1.1 et du fait que les navigateurs Web sont limités au nombre de connexions simultanées qu’ils peuvent établir à un hôte ; ce qui est généralement de 6 connexions. Cet avertissement est généralement affiché sur les sites Web qui reçoivent un grand nombre de requêtes. Dans le passé, la seule façon de contourner cette limitation était de mettre en œuvre ce qu’ils appellent le sharding de domaine. Toutefois, si vous utilisez un hébergeur Web ou un fournisseur CDN qui prend en charge HTTP/2, vous pouvez l’ignorer en toute sécurité car plusieurs ressources peuvent désormais être chargées en parallèle sur une seule connexion. Mais vous pouvez également consulter notre tutoriel sur la façon de corriger l’avertissement Parallelize Downloads Across Hostnames en implémentant le sharding de domaine.

Specify a Cache Validator

Cet avertissement fait référence aux en-têtes de cache HTTP manquants qui doivent être inclus dans chaque réponse du serveur d’origine, car ils valident et définissent la longueur du cache. Si les en-têtes ne sont pas trouvés, une nouvelle requête pour la ressource sera générée à chaque fois, ce qui augmente la charge sur votre serveur. Ces en-têtes incluent la last-modified, ETag, Cache-Control, et Expires. Tout comme pour l’avertissement leverage browser caching, ces en-têtes doivent être ajoutés automatiquement par votre hébergeur WordPress. Si vous avez des requêtes de tiers sur lesquelles vous voyez cela, il n’y a rien que vous puissiez faire car vous n’avez pas de contrôle sur leurs serveurs web.

Lisez notre article détaillé sur la façon de corriger l’avertissement de Specify a Cache Validator.

Specify a Vary: Accept-Encoding header

Nous avons un article détaillé sur la façon de corriger l’avertissement Specify a Vary: Accept-Encoding Header. Il s’agit d’un en-tête HTTP qui doit être inclus dans chaque réponse du serveur d’origine, car il indique au navigateur si le client peut ou non gérer les versions compressées du contenu. Ceci est automatiquement ajouté sur tous les serveurs de Kinsta.

Codes de réponse Pingdom

La section suivante dans l’outil de test de vitesse Pingdom est les codes de réponse. Les codes de réponse, également appelés codes d’état HTTP, sont comme une courte note du serveur Web qui est collée en haut d’une page Web. Il s’agit d’un message du serveur Web vous indiquant comment les choses se sont passées lorsque la demande de consultation de la page a été reçue. Certains sont communs :

• 200 : « Tout va bien. » C’est le code qui est délivré lorsqu’une page Web ou une ressource agit exactement comme on s’y attend.

  

• 301 : « La ressource demandée a été déplacée de façon permanente. » Ce code est délivré lorsqu’une page Web ou une ressource a été remplacée de façon permanente par une ressource différente. Il est utilisé pour la redirection permanente d’URL.

  

• 404 : « La ressource demandée n’a pas été trouvée. » Le message d’erreur le plus courant de tous. Ce code signifie que la ressource demandée n’existe pas et que le serveur ne sait pas s’il a déjà existé.

  

Vous pouvez en svoir plus sur les différents codes de réponse dans notre article détaillé sur les codes de statut HTTP.

Taille du contenu et demandes par type de contenu

Les sections suivantes sont la taille du contenu par type de contenu et les demandes par type de contenu. Chacune d’entre elle est utile pour voir rapidement ce qui prend le plus de ressources sur votre page web. Selon HTTP Archive, les images représentent généralement 64% de la taille totale d’une page web moyenne. Nous voyons aussi que c’est généralement le cas. Cependant, comme vous pouvez le voir ci-dessous sur ce site, ce n’est pas toujours le cas. Au cas où vous vous demanderiez quel est le type de contenu « Autre » ci-dessous, c’est généré par les polices Google web Font et les polices Font Awesome. Les polices Web sont regroupées dans la catégorie Autres.

Pour optimiser vos images, nous vous recommandons vivement de lire notre article détaillé sur l’optimisation des images pour le web et sur WebP. Il existe de nombreux outils et extensions pour compresser davantage vos images et s’assurer qu’elles ne représentent pas la majeure partie de la charge de pages de votre site Web. Et dans notre cas ci-dessus, le site perfmatters.io profite de l’utilisation de grosses icônes impressionnantes à la place des images. Cela peut être une excellente stratégie qui fait une énorme différence. Et bien sûr, nous avons quelques conseils supplémentaires dans notre guide de vitesse de page sur la façon de réduire davantage la taille de votre contenu.

Taille du contenu et demandes par domain

La taille du contenu et les demandes par domaine est un bon moyen de voir rapidement quels services et scripts externes sont sur votre site web. Dans notre exemple, vous pouvez voir que toutes nos ressources sont chargées à partir de notre CDN. Ensuite, il y a le chargement HTML DOC initial pour le site Web à partir du serveur Web et un appel externe au domaine Google Analytics. En fonction de votre site, vous pouvez avoir beaucoup plus de services externes, tels que Facebook, Twitter, Hotjar, SumoMe, AdRoll, New Relic, CrazyEgg, etc.

En général, moins il y a de demandes externes, mieux c’est, parce que chaque service externe introduit sa propre latence, les délais de TLS, les vérifications DNS, etc. Assurez-vous de lire notre article détaillé sur la façon d’identifier et d’analyser les services externes sur votre site WordPress.

En général, il est préférable de réduire autant que possible le nombre de requêtes et d’héberger les ressources à un seul endroit, par exemple en les déplaçant vers votre serveur Web ou CDN. Un exemple serait la police de caractères Font Awesome, au lieu de la lier au script externe, téléchargez-la, et servez-la directement.

Tableau en cascade de Pingdom

Et enfin, nous avons la section de Pingdom qui génère un tableau en cascade de toutes les requêtes individuelles sur votre page web (comme indiqué ci-dessous). Vous pouvez ensuite analyser chaque requête pour voir ce qui cause des délais et des problèmes de performance sur votre site. C’est ce que nous voulons dire quand nous disons que nous faisons une analyse en cascade. Vous trouverez ci-dessous un résumé plus détaillé et/ou une définition de ce que signifie chaque couleur de statut.

DNS (Rose)

Qu’est-ce que le DNS ? Eh bien, pensez-y comme un annuaire téléphonique. Il existe des serveurs appelés Serveurs de noms de domaine qui détiennent les informations sur votre site Web et vers quelle adresse IP il doit être acheminé. Lorsque vous testez votre site Web à travers Pingdom, il effectue une nouvelle recherche, et il doit interroger les enregistrements DNS pour obtenir les informations IP. Il en résulte un temps de consultation supplémentaire.

Lorsque vous testez votre site web à travers Pingdom plus d’une fois, il cache le DNS parce qu’il connaît déjà les informations IP et n’a pas besoin d’effectuer la recherche à nouveau. C’est l’une des raisons pour lesquelles votre site web apparaît plus rapidement après l’avoir parcouru plusieurs fois dans Pingdom.

Comme vous pouvez le voir dans l’écran ci-dessous, sur le 2ème test que nous avons exécuté, le temps de recherche DNS sur la charge DOC initiale est de 0 ms. C’est un domaine que beaucoup de gens interprètent mal !

Vous pouvez également l’optimiser davantage en utilisant un service DNS premium, qui s’accompagne de nombreux avantages supplémentaires. Le DNS gratuit de Cloudflare est également rapide ! Consultez l’optimisation automatique de la plateforme de Cloudflare.

Il y a aussi d’autres raisons pour lesquelles votre site Web pourrait apparaître plus rapidement après plusieurs tests. L’une d’entre elles est de savoir si vous utilisez un réseau de diffusion de contenu (CDN). Pour ceux d’entre vous qui ne connaissent pas le CDN, il s’agit d’un réseau de serveurs mondiaux qui mettent en cache votre contenu (JS, CSS, Images, etc.) dans des endroits plus proches du visiteur. Lorsque vous testez votre site web à travers Pingdom, il se peut qu’il doive récupérer les ressources toutes fraîches du CDN. Un cache CDN fonctionne un peu comme un DNS, une fois qu’il est mis en cache, il est alors beaucoup plus rapide sur des tests consécutifs.

Un autre conseil pour accélérer le DNS est d’utiliser le DNS Prefetch. Ceci permet au navigateur d’effectuer des recherches DNS sur une page en arrière-plan. Vous pouvez le faire en ajoutant quelques lignes de code à l’en-tête de votre site WordPress. Voir quelques exemples ci-dessous.

<!-- Prefetch DNS for external assets -->
 <link rel="dns-prefetch" href="//fonts.googleapis.com">
 <link rel="dns-prefetch" href="//www.google-analytics.com"> 
 <link rel="dns-prefetch" href="//cdn.domain.com">

Ou si vous utilisez WordPress version 4.6 ou une version plus récente, vous voudrez peut-être utiliser des conseils sur les ressources. Les développeurs peuvent utiliser le filtre wp_resource_hints pour ajouter des domaines et URLs personnalisés pour dns-prefetch, preconnect, prefetch ou prerender.

SSL (Violet)

La couleur d’état violet représente le temps que prend votre navigateur pour effectuer un handshake SSL/TLS. Chaque fois que vous exécutez un site Web sur HTTPS, cela signifie qu’il y a un certificat SSL impliqué et du temps supplémentaire en raison du processus de cryptage (handshake SSL/TLS). Sur notre domaine d’exemple, nous avons un certificat à la fois sur notre serveur web chez Kinsta et sur notre CDN, KeyCDN. Il y a donc un temps de négociation SSL à la fois sur le chargement initial du HTML à partir du serveur Web et sur nos ressources.

Bien qu’il y ait une légère surcharge pour faire tourner HTTPS, elle est maintenant très négligeable grâce à HTTP/2, qui est un nouveau protocole permettant d’accélérer le web ! En raison de la prise en charge du navigateur, HTTPS est nécessaire pour utiliser HTTP/2. Consultez notre guide ultime pour HTTP/2.

Il est également important de noter que tous les fournisseurs ne supportent pas encore HTTP/2. Cela inclut à la fois du côté de l’hébergement Web et du côté CDN. Donc, lorsque vous magasinez pour l’hébergement et les CDN, assurez-vous que les deux le supportent ! Kinsta est fier de supporter HTTP/2 pour tous ses clients WordPress.

Depuis le milieu de l’année 2018, Pingdom a enfin mis à niveau son outil pour utiliser Chrome 60 et plus. Vous pouvez voir le user-agent utilisé dans l’en-tête de requête. Auparavant, ils utilisaient Chrome 39, et Chrome n’a pas pris en charge HTTP/2 avant la version 49. Nous sommes donc heureux de dire que l’outil Pingdom affiche maintenant tous les avantages de HTTP/2 quand il effectue des tests ! 👏

Connect (Teal)

Le temps de connexion dans Pingdom fait référence à la connexion TCP, ou le temps total requis pour créer une connexion TCP. Vous n’avez pas vraiment besoin de comprendre comment cela fonctionne, mais il s’agit simplement d’une méthode de communication entre l’hôte/client et le serveur qui doit avoir lieu.

Wait (Jaune)

Le temps d’attente dans Pingdom fait référence au temps de premier octet, aussi connu sous le nom de TTFB (Time To First Byte) dans certains outils. Le TTFB est une mesure utilisée comme indication de la réactivité d’un serveur Web ou d’une autre ressource réseau. En général, tout ce qui est inférieur à 100 ms est acceptable. Si vous vous approchez de de 300-400 ms, il se peut que vous ayez quelque chose de mal configuré sur votre serveur ou qu’il soit temps de passer à une meilleure configuration web.

La façon la plus simple de diminuer votre TTFB ? Les deux meilleurs moyens sont une mise en cache efficace de WordPress et un CDN. Lançons donc quelques tests.

 TTFB sans cache hébergeur WordPress

Nous avons d’abord effectué un test avec notre CDN désactivé et comme vous pouvez le constater, notre temps de chargement total était de 1,45 s et notre TTFB moyen sur une ressource était d’environ 136 ms.

TTFB avec cache hébergeur WordPress

Nous avons ensuite recommencé le test. Il est servi maintenant directement à partir du cache. Comme vous pouvez le constater, nos temps de chargement totaux sont tombés à 392 ms et le TTFB sur la demande initiale est maintenant de 52,8 ms ! C’est la différence que fait la mise en cache.

Si vous avez un site Web qui sert les visiteurs dans différentes régions du pays ou dans le monde entier, l’autre façon facile de réduire considérablement votre TTFB est d’utiliser un CDN. Nous avons de nouveau fait quelques tests pour montrer la différence.

TTFB sans CDN

Nous avons d’abord effectué un test avec notre CDN désactivé et comme vous pouvez le voir, notre temps de chargement total était de 1,93 s et notre TTFB moyen sur une ressource était d’environ 176 ms.

TTFB avec CDN

Nous avons ensuite activé notre CDN et effectué le test à nouveau. Comme vous pouvez le constater, nos temps de chargement totaux sont tombés à 1,21 ms et notre TTFB moyen sur une ressource CDN est maintenant de 4,6 ms ! Quelle différence un CDN peut faire.

Une autre chose importante à noter est que nous avons choisi le site « Pacific – Australia – Sydney » pour effectuer ce test. Pourquoi ? Parce que nous voulions vous montrer les améliorations réelles qui peuvent être apportées. Notre site WordPress dans cet exemple est hébergé par Kinsta sur Google Cloud et situé dans un endroit central aux Etats-Unis. En effectuant le test en Australie, nous sommes en mesure de montrer comment la mise en cache du CDN Kinsta augmente la vitesse et réduit le TTFB.

Et bien sûr, avoir un bon hébergeur WordPress avec une architecture bien pensée est également crucial pour réduire votre TTFB.

Send (Orange) et Receive (Vert)

Les statuts d’envoi et de réception dans Pingdom n’ont pas vraiment besoin d’une explication. Le temps d’envoi est simplement le temps qu’il faut au navigateur Web pour envoyer des données au serveur. Et le temps de réception est le temps qu’il faut au navigateur Web pour recevoir les données du serveur. Les deux seront généralement très faibles ou inexistants dans vos tests.

HTTP Response Headers

Vous pouvez également cliquer sur une requête individuelle tout en faisant votre analyse en cascade et voir les en-têtes de réponse HTTP. Cela permet d’obtenir des informations précieuses. Dans l’écran ci-dessous nous pouvons voir instantanément des choses telles que gzip est activé sur le serveur web, il est servi à partir du cache (HIT, sinon nous verrions MISS), les en-têtes cache-control, expires, le user-agent du navigateur et plus encore.

Étude de cas de configuration de domain

Si vous êtes arrivés aussi loin dans notre article d’analyse en cascade, vous êtes en train de vous régaler. C’est toujours ennuyeux de voir des gens partager des conseils et des études de cas, mais pas comment ils en sont arrivés là. Voici donc ci-dessous notre configuration exacte pour l’étude de cas du domaine utilisé ci-dessus ! N’hésitez pas à la reproduire.

Architecture

• Le domaine d’étude de cas (perfmatters.io) est hébergé chez Kinsta sur la plateforme Google Cloud aux Etats-Unis (Council Bluffs, Iowa, USA (us-central1). Kinsta offre actuellement un choix de 37 centres de données différents. Le réseau premium de GCP est inclus avec tous les plans pour une latence réseau rapide comme l’éclair.
• Kinsta utilise HTTP/2, Nginx, MariaDB, qui contribuent tous aux temps de chargement rapides.
• Le site utilise KeyCDN, qui alimente le CDN Kinsta. La bande passante CDN gratuite est incluse dans tous les plans d’hébergement.
• Le site n’utilise aucun plugin de mise en cache. Kinsta met tout en cache au niveau du serveur, ce qui simplifie grandement les choses !
• Le site utilise PHP 7.3. Les nouvelles versions de PHP ont toujours montré de grandes améliorations de performance. Consultez ces benchmarks PHP. Kinsta vous permet de basculer entre les deux en appuyant sur un bouton.

Plugins et Thèmes WordPress

Voici une liste des plugins utilisés qui ont un impact sur les performances sur le site eCommerce WordPress.

• Le plugin Premium Perfmatters, développé par un membre de l’équipe de Kinsta. Ceci élimine les requêtes HTTP inutiles telles que les embeds, emojis, et dispose également d’un gestionnaire de scripts pour activer/désactiver le chargement de certains scripts en fonction des pages, articles etc.
• Le plugin premium Imagify est utilisé pour compresser les images.
• Le plugin SVG Safe SVG gratuit est utilisé pour télécharger des images SVG sur le site WordPress.
• Le thème Premium GeneratePress WordPress a été utilisé pour construire le site EDD.

Tutoriels recommandés pour une lecture plus approfondie :

• Comment éliminer le JavaScript bloquant le rendu et le CSS
• Comment désactiver les Emojis dans WordPress
• Comment désactiver les Embeds dans WordPress
• Identifier et analyser les services externes sur votre site WordPress
• Comment obtenir un score de 100/100 dans Google PageSpeed Insights avec WordPress
• Comment diagnostiquer une utilisation élevée d’Admin-Ajax sur votre site WordPress ?

Résumé

Comme vous pouvez le voir, savoir comment l’outil de test de vitesse Pingdom fonctionne un peu mieux et ce que tous les graphiques signifient peut vous aider à prendre une décision plus fondée sur les données quand il s’agit de performances. Une analyse des chutes d’eau (waterfall), comme nous l’appelons, est cruciale pour savoir comment vos resources individuelles se chargent et comment elles sont affectées par votre hébergeur WordPress, votre emplacement physique, un CDN, etc. Vous avez d’autres bonnes astuces sur Pingdom ?

Si vous souhaitez voir des articles plus approfondis comme celui ci-dessus, veuillez-nous le faire savoir ci-dessous dans les commentaires !