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.
Capture d'écran montrant le résultat d'un test de performances Web DebugBear, octobre 2022 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.
Capture d'écran de DebugBear montrant la progression du rendu d'un site Web au fil du temps, octobre 2022 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.
Capture d'écran montrant un enregistrement vidéo d'un site Web partiellement rendu dans DebugBear, octobre 2022 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 :
- First Contentful Paint (10 % de la note globale).
- Indice de vitesse (10%).
- La plus grande peinture contente (25%).
- Temps d'interactivité (10 %).
- Temps de blocage total (30 %).
- 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 :
- First Contentful Paint : Cela peut être accéléré en réparant la vitesse de communication du serveur.
- Largest Contentful Paint : 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 demandes.
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.
Capture d'écran montrant les données de débogage pour la métrique First Contentful Paint dans DebugBear, octobre 2022 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 :
- Vérification des enregistrements DNS pour rechercher l'adresse IP du serveur en fonction du nom de domaine.
- Établir une connexion serveur fiable (appelée connexion TCP).
- É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.
Capture d'écran DebugBear montrant les allers-retours réseau utilisés pour établir une connexion serveur, octobre 2022 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.
Capture d'écran DebugBear montrant les différents composants d'une requête HTTP, octobre 2022 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.
Capture d'écran DebugBear montrant des ressources supplémentaires bloquant le rendu chargées après le document HTML, octobre 2022 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 à rendre 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.
Capture d'écran DebugBear montrant les étapes menant du chargement du document HTML au rendu de la page Web, octobre 2022 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.
Capture d'écran DebugBear montrant une chaîne de requêtes séquentielles menant à une requête d'image, octobre 2022 Comment réparer : Selon le site Web, il existe deux solutions 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é.
Capture d'écran DebugBear montrant une image LCP en cours de chargement avec une faible priorité initiale, octobre 2022 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.
Capture d'écran DebugBear montrant une pellicule de rendu où le contenu est masqué par un outil de test A/B, octobre 2022 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.
Capture d'écran montrant les tendances de vitesse de site pour un site Web dans DebugBear, octobre 2022 
Capture d'écran montrant les données Core Web Vitals dans DebugBear, octobre 2022