Vous vous demandez pourquoi votre site Web se charge lentement ?

Vous craignez que la vitesse de votre site Web n’ait un impact sur le référencement ?

Vous espérez améliorer votre classement SERP actuel ?

Si vous êtes ici, il y a de fortes chances que vous espériez apprendre à accélérer votre site Web.

Et nous avons de bonnes nouvelles : accélérer le chargement de votre site Web profite non seulement à vos utilisateurs, mais peut également vous aider à obtenir plus de trafic organique de Google.

Vous pouvez contribuer à améliorer la visibilité de votre site Web dans les recherches en :

• Utiliser un outil de test de vitesse de site Web qui surveille la vitesse de votre site Web en temps réel.
• Apporter des changements à fort impact.

Voyons donc comment vous pouvez vérifier si les performances de votre site Web sont suffisamment bonnes pour impressionner Google, ainsi que ce que vous pouvez faire pour le rendre plus rapide.

Pourquoi la vitesse du site est-elle importante pour le référencement ?

En 2021, Google a déployé la mise à jour de l’expérience de la page, qui a confirmé une information clé sur le référencement – la vitesse du site Web est un facteur de classement.

Cela signifie que le moteur de recherche de Google préfère les sites Web qui se chargent rapidement et en douceur pour vos visiteurs.

Il y a plus de chances que Google affiche des sites Web plus rapides avant des sites Web plus lents sur les pages de résultats des moteurs de recherche (SERP).

Quels facteurs Google examine-t-il pour la vitesse du site ?

Il y a tellement de facteurs qui affectent la vitesse du site Web, mais Google vous a facilité la découverte.

Avant la mise à jour de l’algorithme d’expérience de page, Google a créé un ensemble de trois mesures appelées Core Web Vitals, et il utilise ces mesures pour déterminer la vitesse et la convivialité de votre site Web.

Ces trois mesures clés peuvent vous aider à naviguer sur les pages et les parties de votre site Web qui affectent la vitesse du site et l’expérience utilisateur. Cela permet d’identifier facilement ce qui fait baisser le classement de votre site Web.

Les principaux éléments vitaux Web de Google

Afin de vous assurer que votre site Web est bien classé, vous devez vous assurer que vous faites attention à :

• La plus grande peinture de contenu (LCP): À quelle vitesse le contenu s’affiche-t-il ?
• Premier délai d’entrée (FID): À quelle vitesse la page réagit-elle à l’interaction de l’utilisateur ?
• Décalage de mise en page cumulé (CLS): La mise en page est-elle stable ou le contenu se déplace-t-il après le chargement ?

Lorsque vous saisissez votre site Web dans Google Search Console ou dans un outil de surveillance Core Web Vitals, vous obtenez un score et les pages concernées, ainsi qu’une notation verte, jaune ou rouge.

Si votre site Web comporte des marqueurs rouges ou jaunes, il est temps d’utiliser un outil de test de vitesse de site Web pour découvrir ce que vous devez corriger sur votre site.

Quels outils pouvez-vous utiliser pour tester la vitesse du site ?

Des outils de test de vitesse de site dédiés peuvent fournir de nombreuses données et recommandations de haute qualité sur la façon d’améliorer la vitesse de votre site.

Ces types d’outils sont créés spécifiquement pour les tests de vitesse et peuvent vous fournir toutes les informations dont vous avez besoin pour augmenter les temps de chargement de votre site.

Essayez ces outils de test de vitesse de site Web dédiés:

• Test de vitesse du site Web DebugBear.
• WebPageTest.
• GTmetrix.

Nous utiliserons l’outil de test gratuit DebugBear dans cet article, mais vous pouvez également utiliser une alternative comme WebPageTest ou GTmetrix.

En plus des outils ci-dessus, il existe également des outils d’analyse qui peuvent vous aider à comprendre la vitesse du site local et la vitesse du site de test en laboratoire.

Tester la vitesse du site localement sur votre ordinateur

Chrome DevTools peut fournir de nombreuses données détaillées sur le chargement de votre site Web.

Cependant, le test sur votre propre ordinateur rend le résultat du test fortement dépendant de votre environnement local. Il peut également être difficile d’effacer manuellement tous les caches pertinents pour correspondre à l’expérience d’un utilisateur novice.

Outil de vitesse du site de Google

PageSpeed ​​Insights est idéal pour obtenir un aperçu rapide de la vitesse de votre site.

Vous obtenez à la fois des données utilisateur réelles et des suggestions sur la façon d’accélérer votre site Web sur la base d’un test de laboratoire. Cependant, comme il utilise une limitation simulée, les données de laboratoire ne sont pas toujours exactes.

Testez votre site gratuitement avec DebugBear, maintenant →

Comment tester un site Web avec DebugBear

Tester la vitesse de votre site avec DebugBear ne prend que quelques secondes.

Pour exécuter un test de performances Web :

1. Visite: Accédez à debugbear.com/test.
2. Test: Saisissez l’URL de votre site Web.
3. Examen: Visualisez vos résultats ; voir les métriques et les données de débogage approfondies que vous pouvez utiliser pour comprendre les métriques et apporter des modifications.

Plongeons-nous dans certaines des mesures et apprenons comment accélérer votre site.

Visez un score de 75% + pour obtenir un classement SERP maximum

Une métrique clé que le test de vitesse du site Web de DebugBear vous donne est le « Real User Score ».

Ce pourcentage vous aide à comprendre les performances de votre site Web dans le monde réel – avec de vrais utilisateurs.

Basé sur les données que Google recueille auprès de vrais utilisateurs de Chrome, ce nombre indique le pourcentage d’utilisateurs ayant eu une bonne expérience sur votre site Web. Ces données sont utilisées comme signal de classement.

Visez un score d’au moins 75% pour obtenir le boost de classement maximum.

Voyez la charge de votre site à travers les yeux de vos visiteurs

Obtenez une bonne idée de ce que vos visiteurs vivent réellement lorsqu’ils visitent votre site Web.

Vous remarquez que quelque chose se charge lentement ou n’est pas à sa place ? Cela peut vous aider à identifier les décalages importants et les problèmes de conversion rencontrés par vos visiteurs.

La bande de film de la chronologie montre la progression du rendu du site Web au fil du temps.

Par exemple, cette page commence à s’afficher après 0,7 seconde et l’image principale s’affiche après 1,3 seconde.

Le site Web est entièrement rendu, également connu sous le nom de Visually Complete, lorsque le widget de chat s’affiche après 3,7 secondes.

Dans l’outil, vous pouvez également regarder un enregistrement vidéo du processus de rendu.

C’est un excellent moyen de démontrer l’impact des problèmes de performances aux clients ou aux autres membres de votre équipe.

Testez les changements de vitesse du site en voyant vos véritables statistiques de chargement

Disons que vous avez optimisé votre site Web et que vous voulez comprendre si ces changements auront un impact.

Cet outil exécute un « test de laboratoire » dans un environnement optimal pour déterminer si vous optimisez correctement votre site.

Lorsque vous testez votre site, vous obtenez un « score de laboratoire » officiel, qui est un résumé de six mesures de performance issues du score de performance de l’outil Google Lighthouse :

1. First Contentful Paint (10 % de la note globale).
2. Indice de vitesse (10%).
3. La plus grande peinture contente (25%).
4. Temps d’interactivité (10 %).
5. Temps de blocage total (30 %).
6. Changement de mise en page cumulé (15 %).

À l’aide de ces données, vous découvrirez à quel point votre dernière série d’optimisations a été utile et ce que vous devrez peut-être modifier.

A présent, vous vous demandez probablement ce que vous devez changer. Apprenons à optimiser votre site à l’aide de chaque métrique clé de la vue d’ensemble des métriques.

Comment optimiser la vitesse du site Web

L’exécution d’un test de vitesse est la première partie de votre parcours d’optimisation de site Web.

Une fois que vous avez vos mesures, vous devez savoir comment les interpréter et quoi faire pour les corriger.

Dans la zone Aperçu des métriques du rapport sur la vitesse de votre site Web, vous verrez les métriques clés sur lesquelles nous nous concentrerons pour vous aider à accélérer votre site :

• Première peinture contente: Cela peut être accéléré en réparant la vitesse de communication du serveur.
• La plus grande peinture de contenu: Cela peut être accéléré en optimisant les médias et les ressources.

De plus, vous pouvez utiliser la cascade de demandes pour voir combien de temps les demandes prennent et comment cela affecte ces métriques.

Comment accélérer le First Contentful Paint (FCP)

Commençons par faire en sorte que votre site Web apparaisse plus tôt pour vos visiteurs ; nous allons d’abord nous attaquer à First Contentful Paint.

Qu’est-ce que la première peinture de contenu ?

First Contentful Paint mesure la rapidité avec laquelle le contenu d’une page commence à apparaître après que votre visiteur a navigué sur cette page.

Il est important que votre contenu clé s’affiche rapidement afin d’empêcher votre visiteur de quitter votre site Web. Plus vite un utilisateur quitte votre site Web, plus vite Google apprend que l’expérience de la page peut être mauvaise.

Mais comment savez-vous exactement ce qui ralentit le chargement de votre site Web ?

Comment découvrir quels problèmes de serveur ralentissent votre site Web ? Découvrons-le.

Pourquoi ma première peinture de contenu prend-elle si longtemps ?

Votre FCP peut être affecté par la vitesse de connexion au serveur, les demandes du serveur, les ressources bloquant le rendu, etc.

Cela semble beaucoup, mais il existe un moyen simple de voir exactement ce qui ralentit votre FCP – la cascade de requêtes.

Cet outil utile montre quelles demandes sont faites par votre site Web et quand chaque demande commence et se termine.

Par exemple, dans cette capture d’écran, nous voyons d’abord une requête pour le document HTML, puis deux requêtes pour charger des feuilles de style référencées dans le document.

Pourquoi la première peinture de contenu se produit-elle après 0,6 seconde ? Nous pouvons décomposer ce qui se passe sur la page pour comprendre cela.

Comprendre ce qui se passe avant une première peinture de contenu

Avant que les premiers éléments de contenu puissent être chargés sur votre page Web, le navigateur de votre utilisateur doit d’abord se connecter à votre serveur et récupérer le contenu.

Si ce processus prend beaucoup de temps, il faut beaucoup de temps à votre utilisateur pour voir votre site Web.

Votre objectif est de savoir ce qui se passe avant que votre site Web ne commence à se charger afin de pouvoir identifier les problèmes et accélérer l’expérience.

Chargement de la page Partie 1 : Le navigateur crée une connexion au serveur

Avant de demander pour la première fois un site Web à un serveur, le navigateur de votre visiteur doit établir une connexion réseau avec ce serveur.

Cela prend généralement trois étapes :

1. Vérification des enregistrements DNS pour rechercher l’adresse IP du serveur en fonction du nom de domaine.
2. Établir une connexion serveur fiable (appelée connexion TCP).
3. Établir une connexion serveur sécurisée (appelée connexion SSL).

Ces trois étapes sont effectuées par le navigateur, l’une après l’autre. Chaque étape nécessite un aller-retour entre le navigateur de votre visiteur et le serveur de votre site Web.

Dans ce cas, il faut environ 251 millisecondes pour établir la connexion au serveur.

Chargement de la page, partie 2 : le navigateur demande le document HTML (l’heure du premier octet se produit ici)

Une fois la connexion au serveur établie, le navigateur de votre visiteur peut demander le code HTML contenant le contenu de votre site Web. C’est ce qu’on appelle une requête HTTP.

Dans ce cas, la requête HTTP prend 102 millisecondes. Cette durée inclut à la fois le temps passé sur le réseau aller-retour et le temps passé à attendre que le serveur génère une réponse.

Après 251 millisecondes pour créer la connexion et 102 millisecondes pour faire la requête HTTP, le navigateur de votre visiteur peut enfin commencer à télécharger la réponse HTML.

Ce jalon s’appelle le Time to First Byte (TTFB). Dans ce cas, cela se produit après un total de 353 millisecondes.

Une fois la réponse du serveur prête, le navigateur de votre visiteur passe un peu de temps supplémentaire à télécharger le code HTML. Dans ce cas, la réponse est assez faible et le téléchargement ne prend que 10 millisecondes supplémentaires.

Chargement de la page Partie 3 : Votre site Web charge des ressources supplémentaires bloquant le rendu

Les navigateurs ne restituent pas ou n’affichent pas les pages immédiatement après le chargement du document. Au lieu de cela, il existe généralement des ressources supplémentaires bloquant le rendu.

La plupart des pages auraient une mauvaise apparence sans aucun style visuel, donc les feuilles de style CSS sont chargées avant qu’une page ne commence à être rendue.

Le chargement des 2 feuilles de style supplémentaires dans cet exemple de test de vitesse de site Web prend 137 millisecondes.

Notez que ces requêtes ne nécessitent pas de nouvelle connexion au serveur. Les fichiers CSS sont chargés à partir du même domaine qu’auparavant et peuvent réutiliser la connexion existante.

Chargement de la page Partie 4 : Le navigateur rend la page

Enfin, une fois que toutes les ressources nécessaires ont été chargées, le navigateur de votre visiteur peut commencer à afficher la page. Cependant, faire ce travail prend également un certain temps de traitement – dans ce cas, 66 millisecondes. Ceci est indiqué par le marqueur de tâche CPU orange dans la vue en cascade.

Nous comprenons maintenant pourquoi le FCP se produit après 632 millisecondes :

• 364 millisecondes pour la demande de document HTML.
• 137 millisecondes pour charger les feuilles de style.
• 66 millisecondes pour rendre la page.
• 65 millisecondes pour les autres travaux de traitement.

L’autre travail de traitement comprend de petits travaux comme l’exécution de scripts en ligne ou l’analyse du code HTML et CSS une fois qu’il est téléchargé. Vous pouvez voir cette activité sous la forme de petites lignes grises juste sous la pellicule de rendu.

Comment optimiser la première peinture de contenu (FCP)

Maintenant que vous comprenez ce qui conduit au rendu de votre site Web, vous pouvez réfléchir à la manière de l’optimiser.

• Le serveur peut-il répondre plus rapidement à la requête HTML ?
• Les ressources peuvent-elles être chargées via la même connexion au lieu d’en créer une nouvelle ?
• Certaines demandes peuvent-elles être supprimées ou modifiées pour ne plus bloquer l’affichage ?

Maintenant que les premiers éléments de votre site Web se chargent plus tôt, il est temps de vous concentrer sur l’accélération du chargement du site complet.

Comment accélérer la plus grande peinture de contenu (LCP) avec les recommandations de DebugBear

Il existe de nombreuses façons d’accélérer votre LCP.

Pour vous faciliter la tâche, DebugBear nous donne d’excellentes prochaines étapes dans sa section Recommandations.

Examinons quelques exemples de recommandations et apprenons comment accélérer le LCP de ce site Web.

Recommandation 1 : lancer des demandes d’image LCP à partir du document HTML

Si le plus grand élément de contenu de votre page est une image, la meilleure pratique consiste à s’assurer que l’URL est directement contenue dans le document HTML initial. Cela l’aidera à démarrer le chargement dès que possible.

Cependant, cette meilleure pratique n’est pas toujours utilisée et il faut parfois beaucoup de temps avant que le navigateur ne découvre qu’il doit télécharger l’image principale.

Dans l’exemple ci-dessous, le contenu le plus volumineux, qui est une image, est ajouté à la page à l’aide de JavaScript. Par conséquent, le navigateur doit télécharger et exécuter un script de 200 kilo-octets avant de découvrir l’image et de commencer à la télécharger.

Comment réparer: Selon le site Web, deux solutions sont possibles.

Solution 1 : si vous utilisez JavaScript pour charger paresseusement une grande image, optimisez la taille de l’image et supprimez le script de chargement paresseux ou remplacez-le par l’attribut modern loading= »lazy », qui ne nécessite pas JavaScript.

Solution 2 : Dans d’autres cas, le rendu côté serveur éviterait d’avoir à télécharger l’application JavaScript avant que la page puisse s’afficher. Cependant, cela peut parfois être complexe à mettre en œuvre.

Recommandation 2 : Assurez-vous que les images LCP sont chargées avec une priorité élevée

Après avoir chargé le code HTML d’une page, les navigateurs de vos visiteurs peuvent découvrir qu’en plus de votre image principale, un grand nombre de ressources supplémentaires telles que des feuilles de style doivent être chargées.

L’objectif ici est de s’assurer que votre image principale plus grande se charge pour répondre à l’exigence de la plus grande peinture de contenu de Google.

D’autres ressources, comme les scripts d’analyse tiers, ne sont pas aussi importantes que votre image principale.

De plus, la plupart des images référencées dans le code HTML de votre site seront sous la ligne de flottaison une fois la page rendue. Certains peuvent être complètement masqués dans une navigation d’en-tête imbriquée.

Pour cette raison, les navigateurs définissent initialement la priorité de toutes les demandes d’images sur Faible. Une fois la page rendue, le navigateur découvre quelles images sont importantes et change la priorité. Vous pouvez en voir un exemple dans la capture d’écran ci-dessous, comme indiqué par l’astérisque dans la colonne de priorité.

La cascade montre que même si le navigateur était au courant de l’image dès le début, il n’a pas commencé à la télécharger, comme l’indique la barre grise.

Comment réparer: Pour résoudre ce problème, vous pouvez utiliser une nouvelle fonctionnalité de navigateur appelée conseils de priorité. Si vous ajoutez l’attribut fetchpriority= »high » à un élément img, le navigateur commencera à charger l’image dès le début.

Recommandation 3 : ne masquez pas le contenu de la page à l’aide de CSS

Parfois, vous pouvez consulter une cascade de requêtes et toutes les ressources bloquant le rendu ont été chargées, mais aucun contenu de page ne s’affiche. Que se passe-t-il?

Les outils de test A/B masquent souvent le contenu de la page jusqu’à ce que des variantes de test aient été appliquées aux éléments de contenu de la page. Dans ces cas, le navigateur a rendu la page mais tout le contenu est transparent.

Que pouvez-vous faire si vous ne parvenez pas à supprimer l’outil de test A/B ?

Comment réparer: Vérifiez si vous pouvez configurer l’outil pour masquer uniquement le contenu affecté par les tests A/B. Vous pouvez également vérifier s’il existe un moyen d’accélérer le chargement de l’outil de test A/B.

Surveillez la vitesse de votre site avec DebugBear

Vous souhaitez tester en permanence votre site Web ? Essayez notre outil de surveillance payant avec un essai gratuit de 14 jours.

De cette façon, vous pouvez vérifier si vos optimisations de performances fonctionnent et être alerté de toute régression des performances sur votre site.