Outil de test de vitesse Pingdom : Guide ultime

Aujourd’hui, nous allons voir comment mieux utiliser et comprendre les données de l’outil populaire de test de vitesse des sites web Pingdom. Vous pouvez l’utiliser pour faire une analyse en cascade de votre site WordPress. Cela peut vous aider à diagnostiquer rapidement les problèmes de performance et à ne pas vous tromper de diagnostic.

Souvent, nous voyons des utilisateurs de WordPress qui interprètent mal les données de l’outil de test de vitesse Pingdom, ce qui conduit parfois à configurer un site web dans un état encore pire qu’avant. N’oubliez pas que tous les outils de ce type doivent être utilisés comme des guides. Ils ne sont jamais précis à 100 %. L’important est d’être cohérent et d’utiliser le même outil pour tous vos tests.

Qu’est-ce que l’outil de test de vitesse Pingdom ?

Pingdom est une société basée en Suède (aujourd’hui propriété de SolarWinds) qui offre divers services, tels que la surveillance du temps de fonctionnement, la surveillance de la vitesse des pages, la surveillance des transactions, la surveillance des serveurs et la connaissance des visiteurs (RUM). L’outil gratuit de test de la vitesse des sites web est l’un des services les plus connus de l’entreprise. Il s’agit de l’un des outils de test de performance les plus populaires au sein de la communauté WordPress.

Pourquoi est-il si populaire ? Tout d’abord, c’est probablement l’outil de test de vitesse le plus facile à utiliser ! Tout le monde n’est pas un expert en performance web, donc certains des autres outils alternatifs disponibles peuvent être assez accablants pour l’utilisateur typique de WordPress. Parfois, moins, c’est mieux, comme on dit. Après tout, ce qui vous importe, c’est la rapidité de votre site web et la manière dont vous pouvez l‘accélérer.

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 – États-Unis – Washington D.C.
• Amérique du Nord – États-Unis – San Fransisco
• Pacifique – Australie – Sydney
• Amérique du Sud – Brésil – São Paulo

Remarque : nous avons remarqué qu’il arrive parfois que les sites de test ne soient pas tous disponibles. Cela est probablement dû au fait que le site a été mis hors service pour des raisons de maintenance ou qu’il a été surchargé par un trop grand nombre de personnes essayant d’y effectuer des tests. Si l’emplacement d’un site de test que vous avez utilisé n’est plus là, vérifiez dans une heure ou deux. Il est fort probable qu’il réapparaisse.

L’emplacement de test que vous choisissez est essentiel par rapport à l’emplacement physique de l’hébergement de votre site web. C’est là qu’entre en jeu ce que l’on appelle la latence du réseau. Nous y reviendrons plus en détail ci-dessous.

Analyse en cascade avec l’outil de test de vitesse Pingdom

Une page web comprend différents éléments, tels que HTML, JavaScript, CSS, images et vidéos. Chacun de ces éléments génère des requêtes pour rendre ce que vous voyez sur votre site web. En règle générale, plus le nombre de requêtes est élevé, plus le chargement de votre site web est lent. Ce n’est pas toujours le cas, mais c’est vrai la plupart du temps.

Ci-dessous, nous décomposons chaque section de Pingdom et expliquons plus en détail ce que les informations signifient en ce qui concerne les performances globales de votre site web et comment effectuer une analyse en cascade.

• Résumé Pingdom
• Aperçu des performances
• Codes de réponse
• Taille du contenu et requêtes par type de contenu
• Taille du contenu et requêtes par domaine
• Graphique en cascade
• Configuration du domaine de l’étude de cas

Résumé Pingdom

Lorsque vous exécutez votre site web WordPress avec 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 web. Dans notre exemple, il s’agit d’un site de commerce électronique utilisant Easy Digital Downloads. Il est hébergé sur les serveurs ultra-rapides de Kinsta.

Comme vous pouvez le voir, nous avons effectué notre premier test et obtenu un score de 88/100 sur Pingdom, et le temps de chargement total est de 541 ms. Cela nous permet de connaitre la taille totale de nos ressources combinées et le nombre de requêtes.

Nous avons ensuite effectué un test supplémentaire, et notre temps de chargement total est maintenant de 392 ms avec la même taille de page et le même nombre de requêtes ! De quoi s’agit-il ? 🤔 Vous pourriez le remarquer si vous exécutez plusieurs fois votre site web avec l’outil de test de vitesse Pingdom. Les sites plus importants remarqueront des différences encore plus importantes.

Il y a trois raisons principales pour lesquelles cela se produit : la mise en cache DNS, la mise en cache CDN et la mise en cache WordPress. C’est pourquoi vous devez toujours effectuer des tests à plusieurs reprises. Bien entendu, les appels externes à des ressources et API tierces peuvent également avoir un impact. Découvrez pourquoi plus bas dans notre analyse en cascade.

Vous voulez obtenir un meilleur score Pingdom sur votre site WordPress ? En fonction de votre site et de sa configuration, il n’est pas toujours possible d’obtenir un score parfait de 100/100, en particulier pour ceux qui gèrent des sites de commerce électronique et des pixels de marketing. Mais le simple fait de passer un peu de temps à améliorer votre score est un excellent point de départ. Ce qui compte, c’est la vitesse globale.

Parfois, l’expérience de l’utilisateur peut également l’emporter sur certaines astuces de performance web que vous avez lues sur le web. Vous ne pouvez pas oublier l’expérience utilisateur ! Mais rassurez-vous, nous partagerons plus loin quelques conseils et astuces sur la façon dont nous avons amené le site ci-dessus là où il est, alors continuez à lire.

WinningWP a effectué de manière indépendante des tests de vitesse comparant Kinsta à d’autres fournisseurs d’hébergement de premier plan et a constaté que Kinsta était « beaucoup plus rapide », avec un temps moyen de seulement 394 ms.

Améliorer la performance de vos pages

La section « Performance insights », maintenant « Improve page performance » a été mise à jour en 2018, et ils ont supprimé certains anciens éléments et en ont ajouté de nouveaux. C’est très probablement parce que certaines des suggestions qu’ils signalaient ne sont plus aussi pertinentes qu’avant. En matière d’optimisation des performances web, les choses évoluent constamment. Et cela peut parfois s’avérer gênant si l’on cherche simplement à obtenir le score Pingdom parfait.

Cependant, nous laissons toute cette section dans notre article (certains anciens et nouveaux) parce qu’il est essentiel de comprendre comment ces scores sont calculés. Ceux-ci sont essentiellement basés sur les règles de Google PageSpeed Insight. En général, si vous améliorez ces règles sur votre site, vous devriez réduire vos temps de chargement globaux.

Voici quelques-unes des catégories de la section « Améliorer les performances des pages » :

• Utiliser un réseau de diffusion de contenu (CDN)
• Éviter les erreurs HTTP 404 (Not Found)
• Minimiser les redirections
• Ajouter des en-têtes Expires
• Supprimer les chaines de requête des ressources statiques
• Utiliser des domaines sans cookies
• Paralléliser les téléchargements entre les noms d’hôtes
• Spécifier un validateur de cache
• Spécifier un en-tête Vary : Accept-Encoding

Voyons maintenant quelles sont celles qui sont encore pertinentes aujourd’hui.

Utiliser un réseau de diffusion de contenu (CDN)

L’un des services les plus importants à mettre en place sur votre site WordPress aujourd’hui est un réseau de diffusion de contenu (CDN). Il s’agit d’un réseau de serveurs (également connus sous le nom de POP) situés dans le monde entier. Ils sont conçus pour héberger et livrer des copies du contenu statique (et parfois dynamique) de votre site WordPress, comme des images, des feuilles de style CSS, du JavaScript et des flux vidéo.

Si vous êtes un client de Kinsta, nous incluons un CDN dans nos plans d’hébergement. Quelques clics suffisent pour l’activer. Parmi les avantages d’un CDN, citons l’amélioration des performances (réduction du TTFB et de la latence du réseau), la réduction de la bande passante et des coûts d’hébergement, et même des avantages en termes de référencement.

Important : l’outil Pingdom récemment mis à jour présente actuellement un problème de détection correcte de tout fournisseur de CDN.

Parmi les fournisseurs de CDN tiers que nous recommandons, citons

• KeyCDN (c’est lui qui alimente le CDN de Kinsta)
• Cloudflare
• CDN77

Lors de nos propres tests de vitesse, nous avons constaté qu’un CDN peut réduire le temps de chargement des pages de plus de 50 % dans certains cas !

Éviter l’erreur HTTP 404 (Not Found)

Cette section s’appelait auparavant « éviter les mauvaises requêtes » Et c’est toujours d’actualité ! Cet avertissement est exactement comme son nom l’indique, il s’agit d’une requête qui n’a pas pu être complétée. 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 entraine une erreur 404. Dans Pingdom, cette erreur se traduit par un cercle orange et un statut d’en-tête de réponse 404.

Assurez-vous toujours que chaque requête sur votre site renvoie un statut de réussite. Vous vous assurerez ainsi qu’aucune requête n’est générée pour des actifs qui n’existent plus.

Minimiser les redirections

Il faut toujours faire attention à un trop grand nombre de redirections. Les redirections simples comme une redirection 301, HTTP vers HTTPS, ou www vers non-www (vice versa) sont acceptables. Elles sont d’ailleurs souvent nécessaires dans certaines parties de votre site web. Cependant, chacune d’entre elles a un cout sur les performances de votre site. Et si vous commencez à empiler les redirections les unes sur les autres, il est essentiel de réaliser l’impact qu’elles ont sur les performances de votre site. Cela s’applique aux redirections de pages et de messages, aux redirections d’images, à tout.

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

Quel est l’impact des redirections sur votre site ? Faisons un petit test. Tout d’abord, nous effectuons un test de vitesse sur notre page de contact. Nous obtenons un temps de chargement total de 417 ms, comme vous pouvez le voir ci-dessous.

Nous modifions ensuite légèrement l’URL et effectuons un autre test de vitesse pour voir l’impact des redirections multiples. Comme vous pouvez le constater, le chargement de la même page prend désormais 695 ms. Cela représente une augmentation de 66 %. C’est un comble !

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

Ajouter des en-têtes Expires

Cette suggestion était précédemment appelée « tirer parti de la mise en cache du navigateur ». En termes simples, chaque script sur votre site WordPress doit avoir un en-tête de cache HTTP qui lui est attaché (ou devrait l’être). Cet en-tête détermine la date d’expiration du cache du fichier. Pour résoudre ce problème, assurez-vous que votre hébergeur WordPress dispose des en-têtes cache-control et expires appropriés. Kinsta dispose de ces en-têtes sur tous ses serveurs.

Consultez les étapes pour 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 vous n’avez pas la possibilité d’ajouter des en-têtes de mise en cache lorsque vous chargez des scripts tiers, car vous n’avez aucun contrôle sur leurs serveurs web. Le script Google Analytics et les pixels de marketing, comme ceux de Facebook et de Twitter, sont les principaux responsables de ce problème. Pour résoudre ce problème, vous pouvez héberger votre script Google Analytics localement (bien que cela ne soit pas officiellement pris en charge) à l’aide d’une extension tierce. WP Rocket propose également une option permettant d’héberger localement votre pixel marketing Facebook.

Déplacer des scripts localement peut avoir un impact variable sur les performances de votre site. L’avantage est que vous avez un contrôle total sur le fichier et que vous pouvez le servir à partir de votre CDN. Cela permet également d’éviter une autre requête DNS de la part d’un tiers. Cependant, il est également important de se rappeler que ces fichiers peuvent déjà être mis en cache dans les navigateurs des internautes.

Consultez notre article détaillé sur la façon de corriger l’avertissement de mise en cache du navigateur.

Supprimer les chaines de requête des ressources statiques

Un autre problème courant est celui des chaines de requête. Vos fichiers CSS et JavaScript comportent généralement la version du fichier à la fin de leur URL, par exemple https://domain.com/file.min.css?ver=4.5.3. Certains serveurs et serveurs proxy sont incapables de mettre en cache les chaines de requête. En les supprimant, vous pouvez donc parfois améliorer la mise en cache.

Vous pouvez également ajouter manuellement le code suivant au fichier functions.php de votre thème. Une meilleure alternative serait d’utiliser une extension gratuite comme Code Snippets pour ajouter le code. De cette façon, vous n’aurez pas à modifier votre thème directement.

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 de supprimer immédiatement les chaines de requête sur votre site, il est important de savoir pourquoi elles sont utilisées. Les développeurs de WordPress utilisent généralement le versionnage des fichiers pour contourner les problèmes de mise en cache.

Par exemple, s’ils publient une mise à jour et modifient style.css de ?ver=4.6 à ?ver=4.7, cela sera traité comme une toute nouvelle URL et ne sera pas mis en cache. Si vous supprimez les chaines de requête et mettez à jour une extension, la version mise en cache pourrait continuer à fonctionner. Dans certains cas, cela peut perturber l’apparence de votre site jusqu’à ce que la ressource mise en cache expire ou que le cache soit complètement vidé.

Par ailleurs, certains CDN peuvent mettre en cache les chaines de requête. Le CDN de Kinsta le peut et le fait par défaut. Ainsi, si vous êtes un client Kinsta, les chaines de requête sont déjà mises en cache sur vos ressources.

Consultez notre tutoriel détaillé sur la manière de supprimer les chaines de requête des ressources statiques.

Utiliser des domaines sans cookies

Nous avons publié un article détaillé sur la façon de traiter l’avertissement « serve static content from a cookieless domain » (servir un contenu statique à partir d’un domaine sans cookie). Souvent, vous pouvez ignorer cet avertissement car les nouveaux protocoles tels que HTTP/2 rendent ce point moins important. Une nouvelle connexion est généralement plus couteuse que de tout diffuser sur la même connexion. Toutefois, deux solutions s’offrent à vous : utiliser un fournisseur de CDN qui supprime les cookies ou créer un domaine ou un sous-domaine distinct.

Pour plus d’informations, consultez notre article sur l ‘utilisation des domaines sans cookies.

Compresser les composants avec GZIP

L’avertissement « Compresser les composants avec GZIP » se produit lorsque 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 tels que 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 aux visiteurs. 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 car chaque site Kinsta bénéficie déjà de la compression Brotli, une alternative plus rapide à la compression GZIP. Tout cela grâce à notre intégration unique avec Cloudflare. Cela signifie que votre site hébergé chez Kinsta est plus rapide que la concurrence utilisant GZIP et qu’il se charge rapidement pour les utilisateurs de petits appareils.

Si vous voyez toujours le message « Compresser les composants avec GZIP » après avoir activé GZIP sur votre serveur, il est possible qu’un serveur hébergeant une ressource externe requise par votre site n’ait pas activé la compression GZIP ou Brotli. Si c’est le cas, il n’y a rien que vous puissiez faire de votre côté pour modifier le comportement du serveur.

Paralléliser les téléchargements entre les noms d’hôtes

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 avec un hôte ; en général, il s’agit de six connexions. Cet avertissement apparait généralement 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 d’implémenter ce que l’on appelle le « domain sharding ».

Cependant, supposons que vous utilisiez un hébergeur ou un fournisseur de CDN qui prend en charge HTTP/2. Dans ce cas, vous pouvez ignorer cette limitation car plusieurs ressources peuvent être chargées en parallèle sur une seule connexion. Mais vous pouvez également consulter notre tutoriel sur la façon de résoudre l’avertissement relatif aux téléchargements parallèles sur plusieurs noms d’hôte en mettant en œuvre le domain sharding.

Spécifier un validateur de cache

Cet avertissement fait référence à l’absence d’en-têtes HTTP de mise en cache qui devraient ê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 augmentera la charge de votre serveur. Ces en-têtes comprennent last-modified, ETag, Cache-Control et Expires. Comme pour l’avertissement de mise en cache du navigateur, votre hébergeur WordPress devrait automatiquement ajouter ces en-têtes. Si vous recevez des requêtes de tiers, vous ne pouvez rien faire car vous n’avez pas le contrôle de leurs serveurs web.

Lisez notre article détaillé sur la façon de corriger l’avertissement Specify une cache validator.

Spécifier un en-tête Vary : Accept-Encoding

Nous avons un article détaillé sur la façon de corriger l’avertissement Specify a Vary : Accept-Encoding. 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 des versions compressées du contenu. Cet en-tête est automatiquement ajouté à tous les serveurs de Kinsta.

Codes de réponse Pingdom

La section suivante de l’outil de test de vitesse Pingdom concerne 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 qui vous indique comment les choses se sont déroulées lorsque la demande de consultation de la page a été reçue. Les codes d’état les plus courants sont les suivants :

• 200 : « Tout est OK » Il s’agit du code délivré lorsqu’une page web ou une ressource fonctionne exactement comme prévu.

  

• 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 manière 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 » C’est le message d’erreur le plus courant. Ce code signifie que la ressource demandée n’existe pas et que le serveur ne sait pas si elle existe.

  

Pour en savoir plus sur les différents codes de réponse, consultez notre article détaillé sur les codes d’état HTTP.

Taille du contenu et requêtes par type de contenu

Les sections suivantes concernent la taille du contenu par type de contenu et les requêtes par type de contenu. Chacune de ces sections 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 43 % de la taille totale d’une page web moyenne. C’est également ce que nous constatons le plus souvent. Cependant, comme vous pouvez le voir ci-dessous sur ce site, ce n’est pas toujours le cas.

Pour optimiser vos images, nous vous recommandons vivement de lire notre article détaillé sur l ‘optimisation des images pour le web et sur le WebP. Il existe de nombreux outils et extensions qui permettent de compresser davantage vos images et de s’assurer qu’elles ne constituent pas la majeure partie du chargement de la page de votre site web. Dans notre cas, le site tire parti de l’utilisation d’icônes awesome de grande taille à la place des images. Il s’agit là d’une excellente stratégie qui peut faire une énorme différence. Bien entendu, notre guide sur la vitesse de chargement des pages contient d’autres conseils sur la manière de réduire davantage la taille de votre contenu.

Taille du contenu et requêtes par domaine

La section Taille du contenu et requêtes par domaine est un excellent moyen de voir rapidement quels services et scripts externes se trouvent sur votre site web. Dans notre exemple, vous pouvez voir que toutes nos ressources sont chargées depuis notre CDN. Ensuite, il y a le chargement initial du DOC HTML pour le site web à partir du serveur web, et un appel externe au domaine Google Analytics. En fonction de votre site, vous pouvez avoir d’autres services externes, tels que Facebook, Twitter, Hotjar, SumoMe, AdRoll, New Relic, CrazyEgg, etc.

En règle générale, moins vous faites de requêtes externes, mieux c’est, car chaque service externe introduit de la latence, des retards dans les échanges TLS, des recherches DNS, etc. Assurez-vous de lire notre article approfondi sur l’identification et l’analyse des services externes sur votre site WordPress.

En général, il est préférable de réduire le nombre de requêtes autant que possible et d’héberger les ressources en un seul endroit, par exemple en les déplaçant sur votre serveur web ou sur un CDN. Un exemple serait la police awesome. Au lieu de créer un lien vers le script externe de la police awesome, téléchargez-la et diffusez-la directement.

Diagramme de cascade Pingdom

Enfin, nous avons la section des requêtes de l’outil de test de vitesse Pingdom, qui génère un graphique en cascade de toutes les requêtes individuelles sur votre page web (comme illustré ci-dessous). Vous pouvez ensuite analyser chaque requête pour voir ce qui cause des retards et des problèmes de performance sur votre site. C’est ce que nous voulons dire lorsque nous disons que nous effectuons une analyse de la chute d’eau. Vous trouverez ci-dessous un résumé plus détaillé et/ou une définition de la signification de chaque couleur d’état.

DNS (rose)

Qu’est-ce que le DNS ? Imaginez un annuaire téléphonique. Il existe des serveurs appelés serveurs de noms de domaine qui détiennent les informations relatives à votre site web et à l’adresse IP vers laquelle il doit être acheminé. Lorsque vous exécutez votre site web pour la première fois avec Pingdom, celui-ci effectue une nouvelle recherche et doit interroger les enregistrements DNS pour obtenir les informations relatives à l’IP. Il en résulte un temps de recherche supplémentaire. L’emplacement du serveur DNS a également son importance.

Lorsque vous exécutez votre site web plusieurs fois avec Pingdom, ce dernier met en cache le DNS car il connait déjà les informations IP et ne doit pas effectuer la recherche une nouvelle fois. C’est la raison pour laquelle votre site web apparait plus rapidement après avoir été exécuté plusieurs fois par Pingdom.

Comme vous pouvez le voir dans l’écran ci-dessous, lors du deuxième test que nous avons effectué, le temps de recherche DNS lors du chargement initial du DOC était de 3,6 ms. En règle générale, il tombe à 0 ms, comme il se doit, puisque la requête est déjà mise en cache. Il s’agit là d’un point sur lequel beaucoup de gens se trompent !

Vous pouvez également l’optimiser davantage en utilisant un service DNS premium, qui offre en outre de nombreux avantages supplémentaires. Notre service DNS gratuit Cloudflare est également rapide ! Découvrez l’optimisation automatique de la plateforme de Cloudflare.

Il existe d’autres raisons pour lesquelles votre site web peut apparaitre plus rapide après plusieurs tests. L’une d’entre elles est l’utilisation d’un réseau de diffusion de contenu (CDN). Pour ceux 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 exécutez votre site web pour la première fois avec Pingdom, il se peut que vous deviez récupérer les ressources du CDN. Un cache CDN fonctionne de la même manière qu’un DNS. Une fois que le contenu est mis en cache, il est beaucoup plus rapide lors des chargements consécutifs.

Un autre conseil pour accélérer le DNS est d’utiliser le DNS prefetching. Cela 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. Voyez 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">

Si vous utilisez la version 4.6 ou une version plus récente de WordPress, vous pouvez également utiliser des indices de ressources. Les développeurs peuvent utiliser le filtre wp_resource_hints pour ajouter des domaines et des URL personnalisés pour dns-prefetch, preconnect, prefetch ou prerender.

SSL (violet)

La couleur d’état violette indique que votre navigateur a besoin de temps pour établir une liaison SSL/TLS. Chaque fois que vous exécutez un site web via HTTPS, il y a un certificat SSL et un temps supplémentaire pour le processus d’encryptage (SSL/TLS handshake). 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 pour le chargement initial du document HTML depuis le serveur web et pour nos ressources.

Bien qu’il y ait un léger surcout lié à l’utilisation du protocole HTTPS, il n’est plus crucial aujourd’hui grâce à HTTP/2, un nouveau protocole qui contribue à accélérer le web ! En raison de la prise en charge par les navigateurs, HTTPS est nécessaire pour utiliser HTTP/2. Consultez notre guide ultime sur HTTP/2.

Il est également important de noter que même en 2018, tous les fournisseurs ne prennent pas encore en charge HTTP/2. Cela inclut à la fois le côté hébergement web et le côté CDN. Ainsi, lorsque vous faites le tour des hébergements et des CDN, assurez-vous qu’ils le supportent tous les deux ! Kinsta est fier de prendre en charge HTTP/2 pour tous ses clients WordPress.

À la mi-2018, Pingdom a finalement mis à jour son outil pour utiliser Chrome 60 et plus. Vous pouvez voir le user-agent utilisé dans l’en-tête de la 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 désormais tous les avantages de HTTP/2 lors de l’exécution des tests ! 👏

Connect (Sarcelle)

Le temps de connexion dans Pingdom fait référence à la connexion TCP, ou au temps total nécessaire pour créer une connexion TCP. Vous n’avez pas 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.

Attente (jaune)

Le temps d’attente de Pingdom se réfère au temps du premier octet, également connu sous le nom de TTFB dans certains outils. Le TTFB est une mesure utilisée pour indiquer la réactivité d’un serveur web ou d’une autre ressource réseau. En règle générale, un délai inférieur à 100 ms est acceptable et constitue un bon TTFB. Si vous approchez des 300-400 ms, il se peut que votre serveur soit mal configuré ou qu’il soit temps de passer à une meilleure pile web.

Le moyen le plus simple de réduire votre TTFB? Les deux meilleurs moyens sont une mise en cache efficace de WordPress et un CDN. Effectuons donc quelques tests.

TTFB sans cache WordPress

Nous avons d’abord effectué un test après avoir vidé le cache de notre site WordPress. Cela signifie qu’il faut à nouveau précharger le cache. Notre temps de chargement total était de 541 ms, et le TTFB (temps d’attente) sur notre requête initiale était de 185,2 ms.

TTFB avec cache WordPress

Nous avons ensuite refait le test. Il sert maintenant directement à partir du cache. Comme vous pouvez le voir, notre temps de chargement total est tombé à 392 ms, et le TTFB sur la requête initiale est maintenant de 52,8 ms ! Voilà la différence que fait la mise en cache.

Si vous avez un site web qui accueille des visiteurs dans différentes parties du pays ou du monde, l’autre moyen facile de réduire considérablement votre TTFB est d’utiliser un CDN. Nous avons à nouveau effectué 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 un actif était d’environ 176 ms.

TTFB avec CDN

Nous avons ensuite activé notre CDN et refait le test. Nos temps de chargement totaux sont tombés à 1,21 s, et notre TTFB moyen sur un actif CDN est maintenant de 4,6 ms ! Quelle différence peut faire un CDN !

Une autre chose essentielle à noter est que nous avons choisi l’emplacement « Pacifique – Australie – Sydney » pour effectuer ce test. Pourquoi ? Parce que nous voulions vous montrer l’amélioration réelle qui peut être obtenue. Dans cet exemple, notre site WordPress est hébergé par Kinsta dans un lieu central aux États-Unis. En effectuant le test par rapport à l’Australie, nous pouvons montrer comment la mise en cache du CDN de 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.

Envoyer (Orange) et Recevoir (Vert)

Les états d’envoi et de réception dans Pingdom n’ont pas besoin de beaucoup d’explications. Le temps d’envoi est simplement le temps nécessaire au navigateur web pour envoyer des données au serveur. Le temps de réception est le temps qu’il faut au navigateur pour recevoir des données du serveur. Ces deux temps sont généralement très faibles, voire inexistants, dans vos tests.

En-têtes de réponse HTTP

Vous pouvez également cliquer sur une requête individuelle lors de votre analyse en cascade et voir les en-têtes de réponse HTTP. Vous obtiendrez ainsi des informations précieuses. Dans l’écran ci-dessous, nous pouvons voir instantanément des éléments tels que l’activation de gzip sur le serveur web, le fait que la requête est servie à partir du cache (HIT, qui indiquerait sinon MISS), les en-têtes cache-control, les en-têtes expires, l’agent utilisateur du navigateur, et bien d’autres choses encore.

Étude de cas Configuration du domaine

Si vous êtes arrivé jusqu’ici dans notre article sur l’analyse en cascade, vous allez vous régaler. Il est toujours ennuyeux de voir des gens partager des conseils et des études de cas sans expliquer comment ils y sont parvenus. Voici donc notre configuration exacte pour le domaine d’étude de cas utilisé ci-dessus ! N’hésitez pas à la reproduire.

Architecture

• Le domaine de l’étude de cas est hébergé chez Kinsta aux États-Unis. Kinsta propose actuellement 27 différents centres de données.
• Kinsta utilise HTTP/2, Nginx, MariaDB, qui contribuent aux temps de chargement rapides.
• Le site utilise KeyCDN, qui alimente le CDN de Kinsta. La bande passante CDN gratuite est incluse dans tous les plans d’hébergement.
• Le site n’utilise pas d’extension 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. Jetez un coup d’œil à ces benchmarks PHP. Kinsta vous permet de passer d’une version à l’autre en cliquant sur un bouton.

Plugins et thèmes WordPress

Voici une liste des extensions qui ont un impact sur les performances du site de commerce électronique WordPress.

• L’extension premium Imagify est utilisée pour compresser les images.
• L’extension gratuite Safe SVG est utilisée pour téléverser des images SVG sur le site WordPress.
• Le thème WordPress premium GeneratePress a été utilisé pour construire le site EDD.

Tutoriels recommandés pour une lecture plus approfondie :

• Comment éliminer le JavaScript et le CSS qui bloquent le rendu
• Comment désactiver les emojis sur WordPress
• Comment désactiver les embeds sur 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 fonctionne l’outil de test de vitesse Pingdom et ce que tous les graphiques signifient peut vous aider à prendre une décision plus orientée vers les données lorsqu’il s’agit de performance.

Une analyse de la cascade est cruciale pour savoir comment vos ressources se chargent et comment elles sont impactées par votre hébergeur WordPress, l’emplacement physique, un CDN, etc. Nous espérons que cet article vous a aidé à mieux résoudre les problèmes de vitesse et de performance de votre site.

Vous avez d’autres astuces de Pingdom ? N’hésitez pas à nous en faire part dans les commentaires !