Les graphiques des chutes d’eau sont des diagrammes qui représentent la façon dont les ressources du site Web sont téléchargées, parsed par le moteur, dans une chronologie qui nous donne la possibilité de voir la séquence et les dépendances entre les ressources. Il aide à déterminer où des événements importants se sont produits pendant le processus de chargement. Ils peuvent également laisser l’utilisateur facilement voir comment bon ou mauvais les performances de leur site web est, vous montrant exactement ce qui ralentit votre site.
Les graphiques cascades au sein de la plate-forme Dotcom-Monitor peuvent aider les utilisateurs à identifier où des événements importants se sont produits pendant le processus de chargement de la page. Les graphiques cascade nous permettent de voir un effet de cascade sur plusieurs tâches, et en l’air de quelques secondes, l’utilisateur peut voir à quel point les performances du site web sont mauvaises ou bonnes, telles que le nombre de ressources qui bloquent les téléchargements parallèles ou le nombre de lignes existantes. L’utilisateur a le résumé sur l’appareil, avec des visualisations descriptives des statistiques de l’appareil sur les diagrammes à secteurs. Les utilisateurs peuvent également regarder la vidéo de chargement d’URL réelle dans la fenêtre du navigateur.
La capture d’écran ci-dessous est un échantillon d’un tableau de chute d amazon.com pour introduire ce que les cartes cascade ressemblent. Comme vous pouvez le voir, il ya beaucoup d’éléments différents qui entrent en jeu pendant le temps de chargement de la page. Voici quelques-uns de ces facteurs :
- Url
- Emplacement du test
- Navigateur (Chrome, Firefox, Internet Explorer, navigateurs mobiles, etc…)
- Connexion
- Nombre de tests
- Afficher l’avis de répétition
Éléments utilisés dans les graphiques cascade
Curseur interactif: Le curseur interactif est un indicateur des performances de chaque élément en termes de millisecondes. Dans l’image ci-dessous, il est pointé vers avec la flèche. L’utilisateur peut faire glisser le curseur interactif pour voir quel élément est chargé, et dans quel moment dans le temps. Dans cette capture d’écran, vous pouvez voir les éléments mis en surbrillance sont chargés dans la 531e milliseconde.
Grille de temps de chargement: La zone surlignée ci-dessous est appelée grille de temps de chargement. Il montre combien de temps il faut pour charger pour chaque élément.
Liste des éléments: Les éléments qui existent dans la page Web sont affichés dans la liste des éléments. L’extension de l’élément peut être HTML, CSS, GIF, etc.
Performances des éléments: Un utilisateur peut atteindre les informations sur les performances de chaque élément qui existe dans le tableau des chutes d’eau.
Lorsque l’utilisateur clique sur le bouton élément spécifique, il est accueilli par une page de performances, indiquée ci-dessous.
En analysant la page de performances, l’utilisateur a une connaissance plus approfondie des détails de la réponse. Ils peuvent sélectionner le bouton de souris désiré et libérer pour afficher les détails. L’utilisateur peut également observer les problèmes de performances en prêtant attention à la zone marquée rouge, cequi signifie qu’il ya une période de baisse des performances.
Détails du temps dechargement pour les éléments individuels : Dans le graphique cascade, lorsque l’utilisateur déplace son curseur sur une barre spécifique, on lui montre un temps de chargement qui sont DnsTime, ConnectTime, SSLTime, RequestTime, FirstByteTime, ResponseTime, StartTime, EndTime, Speed qui est pointé dans un ovale rouge.
Explication du codage des couleurs :Dans la plate-forme Dotcom Monitor, la représentation des détails du temps de chargement est définie par les couleurs suivantes :
Calendriers de navigation: Ils peuvent être affichés comme une colonne dans le graphique cascade pour afficher le démarrage de navigation, rediriger démarrer, rediriger la fin, aller chercher démarrer, domain lookup start, domain lookup end, connect start, secure connection start, connect end, request start, response end, unload event start, unload event end, DOM Loading, DOM Interactive, DOM Content Loaded Event Start, DOM Content Loaded Event End , DOM Complete, Load Event Start et Load Event End avec codage couleur (indiqué ci-dessous dans l’ovale rouge).
Il est important de mentionner que dans la plate-forme Dotcom Monitor il ya une fonctionnalité qu’un utilisateur peut regarder la vidéo de chargement url réelle dans la fenêtre du navigateur (montré ci-dessous).
Optimiser les performances Web en comprenant les graphiques waterfall
La performance et la rapidité d’un site Web jouent un rôle énorme. Si votre site web n’est pas assez rapide, l’utilisateur n’attendra pas qu’il finisse le chargement. Un site web rapide augmente les taux de conversion et vous conduit à bien performer sur les moteurs de recherche. Pour comprendre la vitesse de votre site Web, des diagrammes de chute d’eau sont utilisés. Les graphiques waterfall vous aident à identifier la source du problème et sont un excellent moyen de diagnostiquer ce qui ralentit vos pages Web.
Dans un graphique cascade en regardant une taille d’un fichier qui est plus de 1 Mo peut provoquer votre site à ralentir. Avec l’aide de la chronologie dans le graphique cascade, l’utilisateur est en mesure de découvrir les différentes phases de chargement des ressources et de comprendre quelles phases ralentissent leur site Web. Certaines des phases sont présentées ci-dessous :
- Réception. Le temps qu’il faut pour télécharger des fichiers. Il s’agit de la première phase du calendrier. Les fichiers volumineux, tels que les images non optimisées, retardent le temps de téléchargement et absorbent plus de bande passante, ce qui entraîne un retard sur le site Web. La solution à ce problème spécifique est que l’utilisateur doit optimiser les médias en réduisant la taille des images sans diminuer leur qualité. Pour augmenter la disponibilité de la bande passante, l’utilisateur doit conserver les images sur un serveur cloud.
- Temps d’attente. Le temps capturé par le serveur pour produire une réponse. Si le temps d’attente est trop long, cela peut signifier un serveur réseau surchargé ou il peut y avoir un code inefficace, qui doit être corrigé par les développeurs de logiciels en trouvant les bogues et en corrigeant le code. De plus, l’utilité de mise en cache peut réduire le temps d’attente. Dans ce cas, l’utilisateur doit passer de l’hébergement partagé à l’hébergement dédié.
- Demande en file d’attente. Se compose de connexions pratiques HTTP/HTTP2, HTTP authentification, exécution de CSS ou JavaScript, SSL connect time, est une phase importante de la chronologie.
- DNS rechercher. Se compose du temps pour le DNS à résoudre et donne à l’utilisateur un grand indice ce qui ralentit le site. En général, la plupart des scripts ralentissent les sites Web en raison de la recherchez DNS.
Lorsque l’utilisateur identifie les problèmes qui ralentissent leur page Web à l’aide de graphiques cascade, ils peuvent commencer à trouver une solution au problème. Certains des problèmes et leurs solutions sont représentés ci-dessous.
| Solution de | problème |
Lien de suivi de page | Désinstaller ou supprimer l’outil de suivi utilisé |
| Lente recherchez DNS | L’utilisateur peut utiliser un CDN |
| Fin de serveur lente | Envoyez un e-mail à votre fournisseur de services. |
| Erreur due aux plugins | L’utilisateur peut désinstaller les plugins. |
| Personnalisation du thème inutilisé/encombrant | L’utilisateur peut engager un développeur Web |
Même l’utilisateur abeginner peut rapidement comprendre les raisons spécifiques qui ralentissent leur site Web en observant les graphiques cascade. Par exemple, les barres longues signifient que l’élément connexe prend trop de temps à charger, le texte rouge signifie une erreur pour récupérer des données, et de longs écarts entre les barres signifient des moments où il n’y a pas de demandes.
Comment faire charger les sites Web plus rapidement
En utilisant des graphiques cascade, nous pouvons créer une grande expérience utilisateur en rendant une charge de page Web plus rapide.
Diminuer la largeur de la chute d’eau
Les performances du site Web peuvent être améliorées en réduisant le temps qu’il faut pour télécharger les ressources qui mènent réduire la largeur du graphique cascade.
S’il ya de longues barres violettes dans la carte cascade
. Violet signifie temps passé à effectuer une négociation SSL/TLS. Dans le cas où un utilisateur fait face à violet en permanence, cela signifie que le site n’est pas optimisé pour TLS. L’utilisateur doit optimiser les performances TLS.
S’ll y a beaucoup d’orange dans la carte des chutes d’eau. Orange signifie la connexion TCP initiale faite pour votre site Web. Seules 2 à 6 demandes à un nom d’hôte spécifique doivent créer une connexion TCP. Après 2-6 demandes, les connexions existantes sont réutilisées. Lorsqu’un utilisateur est confronté à beaucoup d’orange, il doit comprendre que le site n’utilise pas de connexions persistantes. Lorsque la connexion persistante est faite, la largeur de chaque demande sera la moitié puisque le navigateur Web ne va pas faire de nouvelles connexions avec chaque demande.
S’il y a de longues barres bleues dans le diagramme de chute d’eau.
Couleur bleue signifie temps passé à télécharger la réponse. S’il y a une longue barre bleue, il y a de fortes chances que ce soit parce que la ressource est trop grande. La réduction de la taille du fichier peut aider à résoudre le problème. Un utilisateur peut diminuer la taille par optimisation d’image ou compression HTTP.
S’il y a trop de vert le diagramme de chute d’eau.
La couleur verte signifie que le navigateur est en attente d’obtenir du contenu. Pour réduire le vert, l’utilisateur doit déplacer le contenu statique vers un CDN.
Diminuer la hauteur de la carte cascade
La vitesse du site Web peut être améliorée en diminuant le nombre de demandes que le navigateur doit effectuer pour charger la page Web, ce qui conduit à diminuer la hauteur de la chute d’eau. L’utilisateur doit examiner tout son contenu dans chaque page et décider s’il en a vraiment besoin.
S’il ya trop de fichiers JavaScript / CSS qui sont moins de 2kb
. L’utilisateur doit impliquer le contenu de ces fichiers directement dans le HTML via inline, , or
étiquettes.
S’il ya trop de fichiers JavaScript / CSS dans le tableau cascade
. L’utilisateur doit les combiner avec le plugin CMS ou dans le cadre d’un processus de build. Cette action permettra de réduire le nombre de demandes faites, d’augmenter la vitesse de la page.
S’il ya trop de 302 redirections
. Les lignes jaunes signifient des redirections, ce qui signifie que les liens sur la page sont faits par erreur ou obsolètes, ce qui crée des redirections inutiles qui augmentent la hauteur de la chute d’eau. La solution est de remplacer ces liens par des liens directs.
Augmenter le temps de rendu
Pour améliorer le temps de rendu, l’utilisateur doit optimiser la commande des demandes de ressources, ce qui déplace la ligne de rendu de démarrage vert vers la gauche.
S’il y a trop de demandes pour des fichiers CSS distincts
. Avant que les navigateurs commencent à rendre la page, ils attendent que tout le CSS soit téléchargé. L’utilisateur doit en ligne ou combine ces fichiers CSS.
Si un utilisateur voit des appels pour charger les bibliothèques JavaScript
. JavaScript inclut peut bloquer le rendu de page. L’utilisateur doit les déplacer plus bas dans la page.
Si un utilisateur voit des polices externes
. Jusqu’à ce que le navigateur télécharge la police externe, il ne dessine rien. L’utilisateur doit éviter d’utiliser des polices externes.
Première visite et visite répétée. Qu’y a-t-il de plus important?
Basé sur la visite de l’utilisateur, il peut y avoir deux types de graphiques cascade créés: Première visite et visite répétée. Quelle est la différence ?
Cache vide (Première vue) : L’utilisateur accède au site web pour la première fois et n’a pas de données mises en cache. Les outils typiques basés sur le navigateur vont effacer le cache avant de faire les demandes. En d’autres termes, les gens visitent le site web pour la première fois.
Mode cache (visite répétée) : L’utilisateur accède au site web pour la deuxième fois, imitant une deuxième visite du point de vue de l’utilisateur, qui inclut tous les fichiers désormais mis en cache dans un stockage local. En d’autres termes, parce que les gens ont visité votre site à l’avance, maintenant ils peuvent avoir vos images, CSS encaissé dans leur navigateur de sorte que le système n’a pas à livrer beaucoup pour eux.
Dans les captures d’écran ci-dessous, vous pouvez voir à quel point le tableau de la première visite cascade et le graphique chute d’eau de visite répétée sont.
Une des choses importantes à réaliser est que le cache vide prend 6,8 secondes à charger, tandis que la répétition, qui est un mode mis en cache, prend 1,9 secondes.
Si le site fonctionne bien, ce sera le même cas en termes de comparaison des timings, avec cache vide prenant plus de temps que la version mise en cache. La raison en est dans la première visite, les outils videront le cache avant de faire les demandes, et dans la visite répétée, le système aura les fichiers qui peuvent être mis en cache dans un stockage local, conduisant à un temps plus court pour charger le site Web.
Le graphique mode mis en cache (Repeat View) a moins de lignes, ce qui signifie que beaucoup moins de ressources ont été chargées. C’est un bon exemple d’un site Web où la mise en cache efficace est utilisée.
Sans rien changer sur le site, la visite répétée répondrait plus rapidement en raison des éléments mis en cache. La première visite prendrait plus de temps que la visite répétée. Si quelque chose ne va pas sur le site, ce qui ralentit le site, l’utilisateur le corrige. Et ils testent à nouveau le site. Ils considèrent des facteurs tels que la géolocalisation, les serveurs CDN et pop (points de présence). Ils peuvent voir à partir de graphiques cascade quel élément ralentit le processus. Peut-être que le site utilise trop de Processeur. Après l’avoir correcté, ils peuvent tester le site à nouveau.
La première visite est importante parce que l’utilisateur comprend combien de temps il faut pour télécharger les photos et autres ressources. La visite répétée est également importante car après le processus de mise en cache, l’utilisateur doit évaluer combien de temps il faut pour charger les éléments restants. En outre, l’utilisateur observe quelles ressources sont mises en cache en regardant les graphiques cascade de la première visite et la visite répétée. C’est ainsi qu’un utilisateur peut comprendre les performances du site web et les problèmes de contenu avec les ressources.
Vous voulez voir quels éléments pourraient ralentir votre site Web? Exécutez un test de vitesse gratuit sur le site Web et consultez vos résultats à travers des graphiques de chutes d’eau et des rapports de performances.
Comment utiliser un graphique waterfall pour surveiller votre distribution CDN appropriée
Un réseau de diffusion de contenu (CDN) est un groupe géographiquement réparti de serveurs optimisés pour fournir du contenu statique aux utilisateurs finaux. Ce contenu statique peut être presque n’importe quel type de données, mais les CDN sont généralement utilisés pour fournir des pages Web et leurs fichiers connexes, audio, streaming vidéo, et de grands paquets logiciels.
Utilisation du CDN
Les serveurs de bord d’un CDN améliorent la vitesse en comblissant l’écart entre les ressources du site Web et ses visiteurs. Au lieu de faire des demandes directement à l’origine d’un site Web, les utilisateurs se connectent aux différentes plateformes de distribution CDN du fournisseur. Plus une demande se rapproche, plus le temps est gagné. En outre, l’hébergement CDN s’adapte à la compression des fichiers qui améliore la navigation globale parce que de plus petites tailles de fichiers équivalent à des vitesses de chargement plus rapides.
Utilisation de graphiques waterfall pour la surveillance des CDN
Dans la capture d’écran d’un tableau de chute d’eau ci-dessous, la zone URL de surveillance représente la liste de tous les éléments individuels, ainsi que leur taille et leurs performances à droite.
Si l’utilisateur tire parti d’un CDN, il peut voir de nombreux fichiers et ressources provenant de cette seule source – ce qui est un moyen de déterminer si le CDN est configuré correctement.
Avez-vous besoin d’un CDN?
Les graphiques cascades permettent à l’utilisateur de découvrir comment la latence influence la vitesse du site Web. Pour en revenir au graphique codé en couleur plus tôt dans l’article, la barre jaune signifie que le navigateur Web attend les données du serveur de noms de domaine (DNS). Généralement, le temps d’attente de 100ms est accepté comme normal tandis que 400ms est considéré comme lent. Lorsqu’il y a un problème de vitesse, il peut être interprété comme une ressource prenant trop de temps à télécharger ou sa taille étant trop grande. En outre, cela peut signifier que la vitesse de transfert du serveur Web est trop lente. Pour ce problème spécifique, l’utilisation de CDN pourrait être une solution pour réduire le temps d’attente.
En outre, si l’utilisateur éprouve trop de temps d’attente pour obtenir une réponse, cela peut signifier que le contenu du site web est physiquement plus éloigné du visiteur. Pour être en mesure de décider s’il ya un besoin de CDN, l’emplacement du serveur doit être connu. Pour cela, une plate-forme comme Dotcom-Monitor peut être utilisée pour surveiller un emplacement le plus éloigné de votre serveur. Passez en revue le tableau des chutes d’eau et les lignes pour les demandes et les ressources. Si le temps d’attente est supérieur à 100 ms, l’utilisateur doit envisager d’utiliser CDN.
Essayez la plate-forme Dotcom-Monitor gratuite pendant 30 jours.
