Beaucoup d’articles sur l’optimisation se concentrent sur la façon dont vous pouvez accélérer votre site WordPress, comme l’optimisation de vos images ou le déplacement vers un hébergeur plus rapide. Bien que tous ces éléments soient importants, nous voulons aujourd’hui discuter avec vous de l’impact des performances d’un tiers et de la façon dont elles affectent votre site WordPress. Fondamentalement, tout ce que vous appelez de l’extérieur à partir de votre site a des conséquences sur le temps de chargement. Ce qui aggrave encore ce problème, c’est que certains d’entre eux ne sont lents que de façon intermittente, ce qui rend l’identification de la question encore plus difficile. Aujourd’hui, nous allons explorer des moyens d’identifier et d’analyser les services tiers et les problèmes de performance.

Que sont les services externes tiers ?

Un service externe tiers pourrait être considéré comme tout ce qui communique avec votre site WordPress depuis l’extérieur de votre propre serveur. Voici quelques exemples courants que nous rencontrons régulièrement :

  • Plateformes de réseaux sociaux comme Twitter, Facebook et Instagram (widgets ou pixels de conversion)
  • Réseaux publicitaires tiers comme Google Adsense, Media.net, BuySellAds, Amazon Associates, etc.
  • Analyse de sites comme Google Analytics, Crazy Egg, Hotjar
  • Outils de test A/B tels qu’Optimizely, VWO, Unbounce
  • Systèmes de commentaires WordPress tels que Disqus, Jetpack, commentaires Facebook
  • Outils de sauvegarde et de sécurité tels que VaultPress, Sucuri, CodeGuard
  • Outils de partage social tels que SumoMe, HelloBar
  • Réseaux CDN comme KeyCDN, Amazon CloudFront, CDN77, et StackPath
  • Javascript hébergé en externe

Comment les services externes causent des problèmes

Les services externes posent généralement deux problèmes. L’un est dû au volume, l’autre à l’attente jusqu’au chargement.

  • Si vous avez beaucoup de services externes, vous devez tous les charger et attendre qu’ils vous fournissent des informations à chaque chargement de page. Plus vous avez d’appels, plus vous attendez, plus la charge sur votre propre serveur est élevée et plus vous avez de chances de tomber sur le deuxième problème.
  • Dans certains cas, le chargement de la page attendra que le transfert de données entre votre site et le service externe soit terminé. Si le service est appelé dans l’en-tête et qu’il y a une interruption de service, votre page refusera simplement de se charger.

Bien sûr, il y a des choses qui peuvent être faites pour accélérer les choses, comme charger des scripts de manière asynchrone, mais nous reviendrons dessus plus tard. Dans la plupart des cas, le volume est l’un des problèmes les plus importants que vous aurez à résoudre lorsque vous déboguerez des problèmes de performance de tiers.

Identification des services externes

L’identification de ces services n’est pas trop difficile. L’un des moyens les plus simples est d’ouvrir un outil de test de vitesse de site, que ce soit Pingdom, GTmetrix, WebPageTest, ou Chrome Devtools, et d’exécuter votre site à travers lui. Vous devriez voir une liste des ressources qui ont été chargées. Survolez une ressource et si elle ne contient pas votre nom de domaine au début, il s’agit d’un service externe ou d’une ressource externe que vous appelez.

Ci-dessous, vous pouvez voir que la version minifiée de jQuery a été chargée à partir d’une source externe (https://ajax.googleapis.com).

Service externe – JavaScript

Si vous ne savez pas à quoi sert le service externe, vous pouvez toujours essayer de naviguer vers le domaine principal ou de rechercher son nom dans Google, le développeur ou la société associée devrait apparaître. C’est un bon moyen de déterminer si le service est légitime. Comme vous pouvez le voir ci-dessous, la recherche du fichier jQuery aboutit à des sociétés bien connues telles que jQuery et Google qui décrivent héberger ce fichier. Donc vous êtes probablement en sécurité.

Script jQuery externe

Script jQuery externe

Analyse des problèmes de performances continues des tierces parties

Si votre site est toujours lent, vous devrez trouver ce qui le ralentit. Si votre site a des problèmes intermittents, c’est un peu plus difficile. Commençons par la lenteur continue. Nous supposons ici que votre site est lent à cause des services externes. Bien que de nombreux problèmes de vitesse puissent être causés par des services externes, il existe un grand nombre d’autres problèmes, ce qui peut ne pas résoudre vos problèmes.

Si votre site #WordPress est toujours lent 🐌, vous devriez comprendre pourquoi, n'est-ce pas ? Cliquez pour Tweet

Tout d’abord, vous devez déterminer s’il y a un service qui prend beaucoup de temps à charger et comment cela affecte la performance de votre site. Nous avons donc mis en place un site de test, hébergé sur Kinsta, qui contient les éléments suivants :

  • 2 annonces Google AdSense
  • Une boîte Facebook Like
  • Un widget Instagram
  • Des commentaires Disqus
  • Un Pixel de suivi de conversion Facebook
  • Google Analytics
Site de test WordPress

Site de test WordPress

Cela nous permettra de supprimer chaque service un par un et de vous montrer à quel point chacun d’eux affecte la charge globale de votre site. Nous partagerons également quelques stratégies pour trouver d’autres façons de les charger. Vous pouvez ensuite appliquer les mêmes stratégies à votre propre site WordPress. Nous avons fait tourner le site d’essai dans Pingdom et l’une des premières choses que vous pouvez voir est la « taille du contenu par domaine » et les « requêtes par domaine ». Si vous recevez des requêtes qui ne viennent pas de votre nom de domaine, il s’agit très probablement de services externes ou d’actifs externes. C’est un bon point de départ. Comme vous pouvez le voir ci-dessous static.xx.fbcdn.net a 37 requêtes, ce qui n’est pas bon !

Service externes Pingdom

Service externes Pingdom – ( test de vitesse )

Le temps de chargement du site était également de 1,94 secondes, ce qui n’est vraiment pas bon car comme vous pouvez le voir ci-dessus, le site de test n’a aucun contenu dessus. Il s’agit d’un test à plus petite échelle pour vous aider à mieux analyser les performances de tiers. Plus le site WordPress est grand, plus les problèmes deviennent importants. Mais fondamentalement, la plupart des problèmes peuvent être résolus de la même manière.

S’attaquer à Google AdSense

La toute première chose que nous voulons aborder est Google Adsense. Typiquement, lorsque vous effectuez un test de vitesse, vous pouvez survoler chaque barre pour voir combien de temps a pris chaque partie du processus de chargement. Vous devriez rechercher des barres extra-longues (par rapport aux autres) et des endroits où les barres ne commencent à se charger qu’une fois qu’une barre particulière est terminée – ce sont vos goulots d’étranglement. Une fois que vous avez trouvé un élément spécifique qui prend trop de temps ou qui empêche le chargement d’autres ressources, vous devez comprendre pourquoi il est là et d’où il vient.

Cela peut être un peu difficile, l’appel au service peut être codé dans votre thème, ou il peut venir d’une extension. Toutefois, comme nous l’avons mentionné précédemment, il y a aussi la question du volume. Si nous jetons un coup d’oeil aux demandes ci-dessous de pagead2.googlesyndication.com et tpc.googlesyndication.com, nous pouvons voir que les barres sont assez courtes, ce qui signifie qu’elles ne causent pas tant de déélai. Certaines d’entre elles ont cependant un temps de réception plus long (barre verte), c’est-à-dire le temps qu’il faut au navigateur pour recevoir les données du serveur. Le gros problème, c’est quand on additionne toutes les requêtes.

Nous aimons appeler Google AdSense un service tiers variable. C’est parce que chaque fois qu’une page est chargée, un nombre différent de requêtes et de ressources sont chargées. Il est donc très difficile de déterminer ce qui cause les problèmes de performance, car il sera différent chaque fois que vous effectuerez un test de vitesse. Ci-dessous, vous trouverez un extrait de quelques-unes des requêtes de tierces parties générées par les publicités. Ils génèrent également des redirections, qui ont leurs propres délais.

Requêtes externes Google AdSense

Requêtes externes Google AdSense

Vous pourriez penser que c’est fou que seulement deux publicités génèrent autant de demandes, mais c’est ainsi qu’elles fonctionnent.

Option 1 – Chargement asynchrone

Votre première option est de vous assurer qu’ils se chargent de façon asynchrone.  L’attribut asynchrone indique au navigateur de commencer à télécharger la ressource immédiatement sans ralentir l’analyse HTML. Une fois que la ressource est disponible, l’analyse HTML est mise en pause pour que la ressource puisse être chargée. Le code nouvellement généré par Google AdSense aura cet attribut par défaut, mais si vous avez un code qui date encore de quelques années, nous vous recommandons de le vérifier.

<script async src="//pagead2.googlesyndication.com/pagead/js/adsbygoogle.js"></script>
<!-- nogluten-top-right-page-300x250 -->
<ins class="adsbygoogle" style="display: block;" data-ad-client="ca-pub-xxxxxxxxxxx" data-ad-slot="9805695044" data-ad-format="auto"></ins>
<script>
(adsbygoogle = window.adsbygoogle || []).push({});
</script>

N’oubliez pas de lire notre autre article sur l’élimination du blocage de rendu JavaScript et CSS. Cela peut vous aider à mieux comprendre comment les scripts se chargent et fonctionnent sur votre site WordPress.

Option 2 – Les supprimer

Votre autre option est de supprimer complètement Google AdSense. Évidemment, pour certains sites qui dépendent des revenus publicitaires tiers, ce n’est pas une option. Mais nous avons vu des sites de commerce électronique lancer une publicité AdSense sur leur site, en essayant simplement de faire de l’argent rapidement. Vous devriez être au courant des problèmes de performance que cela pose. Si vous vendez des produits ou des services, une seule annonce Google AdSense pourrait faire plus de mal que de bien et nuire à votre principale source de revenus. Pour les blogueurs, vous pouvez également consulter les annonces d’affiliation vs AdSense. Souvent avec les annonces d’affiliation, vous pouvez les charger à partir de votre CDN et il n’y aura qu’une seule requête.

Dans cet exemple, nous allons supprimer les annonces pour vous montrer comment deux petites annonces peuvent affecter la performance globale de votre site WordPress. Nous avons donc fait un autre test de vitesse après les avoir retiré et comme vous pouvez le constater, nos temps de chargement sont passés de 1,94 secondes à 909 ms ! Nos requêtes sont passées de 185 à 138, et notre taille globale de page a été réduite de 2 Mo à 1,7 Mo.

C’est juste ! Deux petites annonces ont ajouté environ une seconde à notre temps de chargement total. C’est pourquoi, à moins que votre modèle de revenu ne s’articule autour de publicités de tiers, ne les mettez pas sur votre site WordPress. Si vous avez un problème avec un réseau publicitaire et que vous avez une extension qui gère le réseau publicitaire pour vous, il y a de fortes chances que la désactivation de cette extension éliminera le problème. Si c’est codé dans le thème, vous devrez modifier vos fichiers de thème. Nous vous recommandons de faire les deux choses suivantes si vous êtes un développeur (si vous n’en êtes pas un, vous pouvez en apprendre plus sur la façon de trouver un bon développeur WordPress).

S’attaquer à la boîte Facebook Like

La prochaine chose à regarder est la boîte Facebook qui cause toutes ces requêtes statiques.xx.fbcdn.net et scontent.xx.fbcdn.net. Nous pouvons voir que les barres sont assez courtes, ce qui signifie qu’elles ne causent pas beaucoup de retard. Cependant, une fois que vous les additionnez tous ensemble, et c’est là que le problème se pose. Encore une fois, il s’agit d’un problème de volume.

Requêtes de widgets Facebook

Requêtes de widgets Facebook

Nous recommandons à tous les propriétaires de sites de ne pas s’approcher de la boîte Facebook Like ! Non seulement elle génère beaucoup de requêtes en JavaScript externe, mais elle charge aussi beaucoup d’images. Voici trois recommandations pour mieux gérer cette situation.

Option 1 – Chargement asynchrone

Pour utiliser la boîte Facebook Like, vous ou un développeur aurait dû ajouter le code suivant à l’en-tête de votre site WordPress. Il y a aussi quelques widgets WordPress qui ajoutent aussi la boîte.

<script>(function(d, s, id) {
 var js, fjs = d.getElementsByTagName(s)[0];
 if (d.getElementById(id)) return;
 js = d.createElement(s); js.id = id;
 js.src = "//connect.facebook.net/en_US/sdk.js#xfbml=1&version=v2.9&appId=1697897870426976";
 fjs.parentNode.insertBefore(js, fjs);
}(document, 'script', 'facebook-jssdk'));</script>

Le problème avec le code ci-dessus est qu’il ne se charge pas de manière asynchrone.  L’attribut asynchrone indique au navigateur de commencer à télécharger la ressource immédiatement sans ralentir l’analyse HTML. Une fois que la ressource est disponible, l’analyse HTML est mise en pause pour que la ressource puisse être chargée. Nous ne savons pas pourquoi Facebook n’a pas ajouté cet attribut au script, mais vous pouvez voir la version modifiée ci-dessous qui le chargera de manière asynchrone.

<script>(function(d, s, id) {
 var js, fjs = d.getElementsByTagName(s)[0];
 if (d.getElementById(id)) return;
 js = d.createElement(s); js.id = id;
 js.async=true; js.src = "//connect.facebook.net/en_US/sdk.js#xfbml=1&version=v2.9&appId=1697897870426976";
 fjs.parentNode.insertBefore(js, fjs);
}(document, 'script', 'facebook-jssdk'));</script>

Vous ne remarquerez probablement pas beaucoup de différence dans les temps de chargement si vous le vérifiez dans Pingdom, mais vos visiteurs le remarqueront certainement, car cela affecte la manière/quand les scripts et les ressources sont chargés.

Option 2 – Utilisez plutôt une bannière d’image

La prochaine recommandation est de remplacer la boîte Facebook par une bannière qui renvoie simplement à votre page Facebook. Cela réduirait instantanément le nombre de requêtes de plus de 40 à 1 et vous n’auriez plus de dépendances externes. Vous pouvez devenir très créatif de cette façon et c’est un bon équilibre entre design et performance.

Option 3 – S’en débarrasser

Enfin, la dernière option serait de s’en débarrasser complètement. C’est exactement ce que nous avons fait sur notre site d’essai et, comme vous pouvez le voir ci-dessous, nos temps de charge sont passés de 909 ms à 786 ms. Cela a réduit le poids total des pages de 1,7 Mo à 1,0 Mo et le nombre total de requêtes de 138 à 78. Une chose à vraiment souligner ici est la réduction du poids de la page. La boîte Facebook Like a ajouté 700 Ko ! C’est plutôt mauvais.

Après avoir supprimé la boîte Facebook Like

Après avoir supprimé la boîte Facebook Like ( test de vitesse )

S’attaquer au widget d’Instagram

La prochaine chose à regarder est le Widget Instagram. Dans notre exemple, nous utilisons l’extension gratuite Instagram Feed. L’extension n’est en fait pas le problème, mais c’est plutôt les requêtes de scontent.cdninstagram.com qui sont générées. Nous pouvons voir que les barres sont assez courtes, ce qui signifie qu’elles ne causent pas beaucoup de délai. Cependant, une fois que vous les additionnez toutes ensemble, c’est là que le problème se pose. Encore une fois, il s’agit d’un problème de volume. Vous pouvez probablement voir une tendance se dégager ici. De nombreux problèmes de performance de tiers sur les sites WordPress ne sont pas dus à des délais dans le traitement de requêtes uniques, mais plutôt à ceux qui ne se soucient pas des performances au départ.

Requêtes externes d'Instagram

Requêtes externes d’Instagram

Nous recommandons également de ne pas utiliser le widget Instagram, sauf si vous en avez vraiment besoin, car il génère beaucoup de requêtes. Voici quelques recommandations pour mieux gérer cette situation.

Option 1 – Utilisez plutôt une bannière d’image

Tout comme pour la boîte Facebook Like, à moins que vous n’ayez vraiment besoin d’un widget dynamique Instagram, créez une bannière à la place qui renvoie à votre page Instagram. Cela réduirait instantanément le nombre de demandes de plus de 20 à 1 et vous n’auriez plus de dépendances externes. Vous pouvez devenir très créatif de cette façon et c’est un bon équilibre entre design et performance.

Option 2 – S’en débarrasser

Et bien sûr, vous pouvez vous en débarrasser complètement. C’est exactement ce que nous avons fait sur notre site d’essai et, comme vous pouvez le voir ci-dessous, nos temps de chargement sont passés de 786 ms à 690 ms. Cela a réduit le poids total des pages de 1,0 Mo à 814,3 Ko et le nombre total de demandes de 78 à 57.

Après avoir supprimé le widget Instagram

Après avoir supprimé le widget Instagram ( test de vitesse)

S’attaquer aux commentaires de Disqus

La prochaine chose à regarder est les commentaires Disqus. Dans notre exemple, nous utilisons l’extension gratuite Disqus Comment System. Le gros problème avec Disqus est qu’il génère beaucoup de requêtes, en plus d’avoir à charger le gravatar pour chaque personne qui commente. Nous avons abordé en détail ce sujet dans nos articles sur la façon d’accélérer les commentaires WordPress. Si vous êtes un grand site commercial, vous pourriez également avoir à payer pour supprimer des Disqus ads, et si vous ne le faites pas, cela se traduirait par encore plus de requêtes générées sur votre site. Vous pouvez voir ci-dessous un petit extrait de quelques unes des requêtes qu’il génère.

Requêtes externes Disqus

Requêtes externes Disqus

Voici quelques recommandations au sujet des commentaires.

Option 1 – Chargement paresseux des commentaires Disqus

Le chargement paresseux (Lazy Load) est le processus qui consiste à ne pas charger les ressources et les scripts tant que la personne n’a pas fait défiler la page. Ainsi, le chargement de la première page est plus rapide. Vous pouvez facilement charger paresseusement les commentaires Disqus en utilisant l’extension gratuite Disqus Conditional Load de Joel James. Nous l’utilisons d’ailleurs sur le blog de Kinsta. Nous avons installé l’extension sur notre site de test et comme vous pouvez le voir ci-dessous, elle a fait passer nos temps de chargement de 690 ms à 603 ms. Cela a réduit le poids total de la page de 814 Ko à 366,1 Ko et le nombre total de requêtes de 57 à 24. Une chose à souligner est la réduction massive du poids des pages !

Après le chargement paresseux de Disquus

Après le chargement paresseux de Disquus (test de vitesse)

Option 2 – Charment paresseux des commentaires natifs de WordPress

Votre autre meilleure option serait de charger paresseusement les commentaires natifs de WordPress. Joel James, le même développeur de l’extension lazy load Disqus a aussi une extension gratuite appelée Lazy Load for Comments. Elle fonctionne d’une manière très similaire à celle qui précède. Nous avons installé l’extension sur notre site de test et comme vous pouvez le voir ci-dessous, elle a permis de réduire d’à peu près autant le temps de chargement.

Après le chargement paresseux des commentaires natifs de WordPress

Après le chargement paresseux des commentaires natifs de WordPress ( test de vitesse)

S’attaquer au pixel de suivi de conversion Facebook

Enfin, nous jetterons un coup d’œil au pixel de suivi de conversion Facebook. Évidemment, la plupart des gens l’utilisent pour recueillir des données sur les personnes qui visitent leur site ou pour suivre les conversions lorsqu’ils diffusent des publicités Facebook. Il n’est donc pas toujours possible de supprimer cette option, et il n’y a vraiment rien que vous puissiez faire pour en améliorer les performances. Comme vous pouvez le voir ci-dessous, il est responsable de la génération de 5 requêtes HTTP différentes, et malheureusement, elles ne sont pas les plus rapides.

Requêtes externes du suivi de conversion Facebook

Requêtes externes du suivi de conversion Facebook

Nous allons simplement supprimer ceci pour vous montrer à quel point cela affecte les performances de votre site. Après l’avoir retiré de notre site, il a fait passer nos temps de chargement de 611 ms à 429 ms. Cela a réduit le poids total des pages de 367,5 Ko à 343,2 Ko et le nombre total de requêtes de 27 à 22.

Après avoir retiré le pixel FB

Après avoir retiré le pixel FB ( test de vitesse)

Les exemples ci-dessus ne sont que quelques-uns des milliers de services externes que vous pourriez avoir sur votre site WordPress. Il est important d’examiner chacun d’eux et de déterminer à quel point ils affectent les performances de votre site. Comme vous pouvez le constater, une seule pomme pourrie peut causer d’énormes problèmes !

Les services externes peuvent aider la performance

Bien que la plupart des services externes nuisent à la performance de votre site, il y a ceux qui peuvent également l’aider. Un CDN, tel que KeyCDN ou Cloudflare peut accélérer considérablement votre site avec un minimum de travail d’installation. Consultez notre tutoriel pour savoir comment installer KeyCDN et comment installer Cloudflare. Dans l’exemple ci-dessous, nous avons ajouté KeyCDN à notre site de test. Comme vous pouvez le voir, cela a réduit notre temps de chargement de 100 ms supplémentaires.

Après CDN

Après CDN ( test de vitesse )

Optimisations supplémentaires

Nous avons ensuite fait quelques optimisations supplémentaires sur le site WordPress pour obtenir un score de 100 et un temps de chargement de 270 ms. Ces optimisations comprenaient :

  • S’assurer que tout est chargé par le fournisseur de CDN. Cela signifiait héberger les polices Google localement et aboutit à une seule requête HTTP/2.
  • Suppression des ressources supplémentaires qui génèrent des requêtes HTTP inutiles telles que emojis, embeds, jQuery migrate, etc. Nous avons utilisé l’extension perfmatters.

Voici des tutoriels plus approfondis pour certaines des optimisations :

Après optimisations

Après optimisations ( test de vitesse )

Comme vous pouvez le voir, nous sommes passés de 1,94 seconde à 270 ms de temps de chargement ! Bien sûr, vous pourriez avoir besoin de certains services externes, comme toutes les entreprises. Mais il est important de ne pas oublier d’analyser chacun d’eux. Si vous constatez des temps de chargement énormes, contactez le développeur ou l’entreprise responsable et soulevez le problème.

Prévention de l’arrêt de chargement

Le plus gros problème est quand un script empêche le chargement alors qu’il a fini de se charger lui-même. Si un script comme celui-ci est inclus dans l’en-tête, il peut garder votre site vierge indéfiniment. Pour cette raison, tout ce qui n’est pas absolument nécessaire dans l’en-tête doit être placé dans le pied de page. Cela permettra à votre site de se charger complètement avant même que le script problématique ne commence à se charger. Si vous utilisez la fonction wp_enqueue_script() (vous devriez), vous pouvez utiliser le cinquième paramètre pour indiquer qu’il doit être chargé dans le pied de page.

Si vous remarquez qu’une extension charge sans raison une ressource dans l’en-tête, vous pouvez utiliser wp_dequeue_script() pour la supprimer du pied de page et ensuite utiliser wp_enqueue_script() pour l’enregistrer de la même manière, mais dans le pied de page.

Utilisation de Google Tag Manager

Une autre façon d’aider à résoudre les problèmes de performance des tiers est d’utiliser un outil gratuit comme Google Tag Manager. Cela vous permet de gérer tous vos scripts et balises en un seul endroit. L’avantage de faire ceci est qu’ils se chargeront de manière asynchrone, la gestion devient plus facile, et vous pouvez mettre en place des déclencheurs sur lesquels les scripts de pages se chargent.

Déclencheurs Google Tag Manager

Déclencheurs Google Tag Manager

Cependant, il y a aussi quelques inconvénients à cela :

Google Tag Manager ne réduit pas le nombre de balises sur votre site ou application, mais il simplifie leur gestion. Pour les sites, Google Tag Manager s’exécute de manière asynchrone et peut être configuré pour ne lancer les balises que lorsqu’elles sont nécessaires, ce qui permet à vos pages de se charger plus rapidement. (source)

Si vous utilisez Google Tag Manager, vous aurez également une autre requête HTTP et une recherche DNS sur googletagmanager.com, même si elle est très négligeable.

requête googletagmanager.com

requête googletagmanager.com

Nous vous recommandons de consulter Google Tag Manager pour les grands sites non optimisés qui ont beaucoup de services tiers et d’intégrations. Pour les petits sites avec des développeurs, vous ne verrez probablement pas beaucoup d’amélioration des performances en utilisant GTM.

Analyse des problèmes de performances intermittentes des tierces parties

La façon dont vous résolvez les problèmes intermittents est la même que la façon dont vous résolvez les problèmes continus, mais identifier le coupable est plus difficile. La mise en œuvre des solutions ci-dessus pourrait déjà aider, mais cela serait quand même bien de savoir ce qui cause le problème. Un outil que nous aimons utiliser pour cela est New Relic, et en fait, si vous êtes un utilisateur de Kinsta, nous pouvons surveiller cela sur votre site ou vous laisser utiliser votre propre clé de licence New Relic. Ci-dessous, vous pouvez voir un exemple de réseaux publicitaires de tierces parties et de temps de chargement importants qui leur sont associés sur une certaine période de temps.

Monitoring New Relic

Monitoring New Relic – réseau publicitaire externe

Ironiquement, New Relic peut aussi causer des problèmes de performance. Dans ce cas, nous vous recommandons de l’utiliser pour le dépannage et la surveillance sporadiquement, et pas pour une utilisation continue. Vous pouvez également utiliser un outil comme GTMetrix pour programmer des contrôles horaires de vitesse sur votre site. Après quelques jours, vous pouvez vérifier et voir les résultats dans un joli petit graphique :

Contrôles horaires de vitesse GTmetrix

Contrôles horaires de vitesse GTmetrix

Ceci vous indique quand votre site a été plus lent que la moyenne. Nous cliquons d’abord sur le point culminant à l’extrême droite pour entrer dans le rapport créé à ce moment-là. Nous visualisions ensuite la cascade pour voir quelle ressource était à l’origine du problème. N’oubliez pas de consulter notre article détaillé sur la façon d’utiliser GTmetrix pour diagnostiquer les problèmes sur votre site.

Diagramme de cascade GTmetrix

Diagramme de cascade GTmetrix

Il y a là un actif qui semble bloquer les autres, regardez la barre verte près du milieu. Il s’avère que ça vient de Google Recaptcha. 632ms peut sembler un clin d’œil, mais en réalité, c’est beaucoup. Une page devrait vraiment se charger en 2 secondes. Plus d’un tiers de ce temps est absorbé par ce seul actif. L’actif doit être chargé plus tard ou abandonné au profit d’autres méthodes de vérification.

Résumé

Comme vous pouvez le constater, juste quelques services externes peuvent avoir un impact énorme. Les performances des tiers ne doivent pas être ignorées et vont de pair avec les optimisations sur site et en back-office. Heureusement, il y a beaucoup à faire, surtout si vous faites appel à un développeur. Abandonner des services, les modifier pour les charger de différentes manières comme asynchrone, fournir la même chose d’une autre manière telle qu’une bannière, tout cela peut faire beaucoup pour rendre votre site beaucoup plus rapide !

100
Partages