Vitesse du site, temps de chargement etc

WRInaute occasionnel
Salut,

J'aurais aimé savoir les éléments que vous regardez lorsque vous auditez un site lent : par exemple j'ai un temps de chargement des pages qui n'est pas si mauvais avec mon outil de crawl, la plupart des charges se chargent entre une à deux secondes c'est pas génial mais pas aussi pire que l'indice pourri sur lighthouse (4 sur 100 en performance!), un autre résultat sur Dareboost (67).
Faites vous la différence entre le load time et la vitesse de page? Regardez vous le temps de chargement du premier octet (time to first byte) et pourquoi? Quelle donnée il importe le plus de regarder en SEO s'il y en a une?
Merci pour l'éclairage!!
 
WRInaute accro
Déjà tu t'en rend compte de visu si c'est lent ou non

Ensuite il faut regarder en combien de temps la page est affichée et permet une interaction de la part de l'utilisateur, même si le chargement se poursuit toujours en asynchrone
 
WRInaute occasionnel
En fait j'aimerai savoir comment faire le tri des infos :

Exemple : sur onCrawl dans le load time 68% des pages sont entre 1 et 2 secondes
Le TTFB est à 0,65 secondes
Le meaningful content est a 11 s
Le time to interactive 21 sec
bon on est d'accord c'est archi nul mais je comprends pas la premiere valeur (onCrawl), c'est sur que les 3 derniers sont à optimiser
 
WRInaute accro
Et que dit Google dans l'onglet vitesse de la search console ?
Quel est ton nombre de pages lentes, à vitesse modérée et rapides ?
 
Olivier Duffez (admin)
Membre du personnel
vu tes autres valeurs, je suppose que oncrawl ne mesure pas le onload mais le temps de téléchargement du HTML seul. Si c'est entre 1 et 2 sec, c'est bien trop long.
 
WRInaute passionné
Ce qui compte c'est le FCP (first contentful paint) puisque c'est ce que Google nous indique dans la search console. Moi il me crie dessus parce que je suis à 3,1 secondes sur mobile (la limite de "lent" étant 3 s).
 
WRInaute occasionnel
Merci pour vos réponses. J'ai donc une indication sur qu'est le load time sur oncrawl qui était flou.
Et pareil pour rick, je me demandais sur quel facteur était basé le fameux moins de 3 secondes, 3 secondes de quoi? Donc c'est bon je sais maintenant. Y a du pain sur la planche.
Je me permets pour ceux que ça interesse de partager ce lien que j'ai lu ce matin parce que ça m'a pas mal aidé à comprendre de manière simple ce qui est pris en compte pour le page speed :
https://fr.ryte.com/magazine/comment-mesurer-le-page-speed

Après je comprends pas franchement l'écart entre la search console (problème FCP dépasse les 3 s : 0 alors que dans lighthouse je suis à 11s...). dans search console je n'ai "que" problème fid : 1600.
 
Dernière édition:
WRInaute passionné
Après je comprends pas franchement l'écart entre la search console (problème FCP dépasse les 3 s : 0 alors que dans lighthouse je suis à 11s...).

Le FCP et le FMP sont deux choses différentes : le FCP c'est dès qu'il y a un premier truc qui s'affiche, alors que le FMP c'est quand tout a l'air d'être affiché correctement (avec les polices de caractères, images...) dans l'écran du visiteur (je ne sais pas exactement les détails, mais c'est l'idée).

Le FCP peut être amélioré en ayant un serveur plus performant, en diminuant le CSS et le JS, et c'est à peu près tout en gros.
 
WRInaute discret
Pour ma part, si je suis bon dans PageSpeed Insights et la search console chrome, ca me va et je ne me pose pas plus de question.

John.
 
T
thomasrossignol
Guest
Bonjour,
Je diviserais votre sujet en deux / trois questions :
- la métrique utilisée pour mesurer la vitesse de chargement (ici vous citez TTFB et PLT)
- ce que signifie un test fait sur votre navigateur ou pagespeedinsight
- comment l'optimiser

Métrique utilisée
Aujourd'hui Page Load Time est considéré comme désué car cette métrique prend notamment en compte l'ensemble des éléments d'une page y compris ceux qui sont chargés au delà du "viewport" ou fenêtre d'affichage (qui n'ont pas d'influence sur l'expérience utilisateur)
TTFB est lui trop limité : il calcule le temps pour recevoir un premier byte de votre site (c'est à dire le premier paquet de votre fichier HTML) mais omet le temps de transfert du fichier HTML et de TOUTES les ressources qui constituent votre page (CSS, Javascripts, images, etc.). Elle vous donne une idée du temps de réponse de votre serveur, mais peu de choses par rapport à l'expérience utilisateur.
La bonne pratique maintenant consiste à s'appuyer sur les 3 métriques de Google Web Core Vitals :
- Largest Contentful Paint (vitesse de chargement de l'élément graphique le plus important)
- First Input Delay (interactivité de votre site)
- Cumulative Layout Shift (stabilité visuelle)

Méthode de test
Tester depuis votre machine avec Chrome WebDevTools est un point de départ mais il ne mesure que le temps de chargement depuis votre machine (avec ses ressources propres), votre connexion réseau, la taille de votre fenêtre d'affichage.
Il faut être conscient que la vitesse d'affichage variera fortement en fonction de la localisation, du dispositif (mobile, tablette, laptop, de ses ressources systèmes, de la taille de son écran), de son accès réseau (par rapport à la localisation de vos serveurs, CDNs, services tiers etc.). Ceci varie également pour chaque page ou interaction avec votre application. Pour capturer correctement ces variations la meilleure méthode consiste à mettre un place un monitoring de type Real User Monitoring (un exemple chez nous).

Comment l'optimiser
A mon sens il y a 5 facteurs clés à prendre en compte :
- profil de vos utilisateurs (devices, navigateurs, localisation)
- contenu de vos pages
- attributs de performance de chaque ressource (poids, impact sur le processing serveur)
- le "critical rendering path", c'est à dire comment elles sont combinés dans une page)
- votre plateforme d'hébergement (cloud, régions employés, CDN, protocoles employés, etc...)

Nous avons également partagé un guide qui explique cela plus en détails : https://www.kadiska.com/fr/blog-5-f...rformance-web-et-de-l-experience-utilisateur/
 
WRInaute discret
mais il ne mesure que le temps de chargement depuis votre machine
Non, l'outil de développement de Chromium/chrome, simule différents types de connexion, de tailles d'écran, et d'appareils.
 
Discussions similaires
Haut