Délai avant premier octet (Time to First Byte)
Le Time to First Byte (TTFB) correspond au délai entre l'émission de la requête vers une page web et la réception du premier octet de données (le début de la réponse HTML).
Le TTFB est très important pour le référencement naturel puisqu'il conditionne l'accès au HTML. En effet le robot Googlebot alloue un "quota" pour visiter chaque site web (sans doute un délai, ou peut-être d'autres métriques). S'il ne parvient pas à parcourir votre site dans ce quota : tant pis pour vous, certaines de vos pages risquent de ne pas être actualisées, voire ne pas être indexées !
Google recommande que les traitements du serveur pour produire une page prennent moins de 200ms (source). Veillez à respecter cette recommandation, pertinente pour le SEO, mais également pour vos visiteurs !
Le TTFB est composé de plusieurs étapes (dont certaines sont facultatives). Je vous propose de les découvrir rapidement, mais si les détails techniques ne sont pas votre fort, n'hésitez pas à passer directement au paragraphe suivant !
- Résolution DNS : pour envoyer la requête, votre navigateur doit disposer de l'adresse IP du serveur web. Il va donc interroger un serveur DNS pour connaître l'adresse IP qui correspond au nom de domaine du site.
- Établissement de la connexion réseau : le protocole HTTP nécessite une connexion sous-jacente. Il est également possible que le site demandé utilise le HTTPS, qui va demander des opérations supplémentaires pour garantir l'identité du site interrogé. Enfin, l'établissement de la connexion dépend aussi de la latence, une durée incompressible qui correspond au temps nécessaire pour aller de votre navigateur jusqu'au serveur web.
- Traitement du serveur : le plus souvent, le serveur va procéder à de nombreux traitements pour produire la page web demandée, le web étant essentiellement constitué de pages dynamiques aujourd'hui.
Avant de recevoir les premières données, il ne reste donc plus que le temps de parcours de la réponse du serveur jusqu'à votre navigateur web, c'est à dire la latence (qui est donc présente à l'aller comme au retour) !
Début de l'affichage (Start Render)
Le Start Render (ou Début de l'affichage) est très important en termes d'expérience utilisateur, puisqu'il correspond au délai nécessaire avant qu'un premier élément ne s'affiche sur la page. Certes, cet élément pourrait être anecdotique et la très grande majorité de la page reste encore blanche, mais peu importe, c'est un bon signe pour l'internaute : la page est en train d'arriver, pas besoin d'actualiser, de réessayer de cliquer sur le lien ou autre.
C'est un point qui doit attirer votre vigilance. En effet, avant cet affichage, le visiteur n'a aucune certitude sur le fait de réussir à charger votre page, et si cela se prolonge, il pourrait abandonner avant même d'avoir visualisé la moindre information !
En quoi le Start Render est important pour le référencement ? Parce qu'il l'est pour votre utilisateur ! En effet, Google observe énormément les comportements des internautes, notamment le pogosticking. Si votre page met du temps avant d'afficher quoi que ce soit, les internautes vont très vite penser à un dysfonctionnement et abandonner, pour s'orienter vers un autre résultat de leur recherche.
Visuellement complet (Visually Complete)
Dans la lignée du Start Render, le Visually Complete va mesurer le temps nécessaire à ce que la partie de la page située au dessus de la ligne de flottaison (sans que l'utilisateur n'ait besoin de faire défiler) soit dans son état final.
On s'intéresse donc ici à ce qui est immédiatement nécessaire à l'internaute, ce qu'il va voir en premier. Et vous l'aurez peut-être remarqué, cela va être énormément dépendant de la résolution de l'internaute, puisque d'un écran à l'autre, la ligne de flottaison peut se déplacer de façon très importante.
Attention : dans certains cas le Visually Complete n'est pas un indicateur adapté : si vous disposez sur votre page d'animations, comme un carrousel en défilement automatique par exemple, la notion d'état final n'existe pas vraiment, et cela peut conduire à avoir une valeur très pessimiste de cet indicateur.
Temps de chargement
Lorsqu'on entend parler de temps de chargement, la notion sous-jacente est généralement le temps total que prend le chargement de la page, qui va inclure le temps nécessaire à certaines ressources et traitements asynchrones.
Plus vous mettrez en place des techniques avancées pour améliorer l'expérience utilisateur de votre site, moins vous aurez à accorder de l'importance à cette valeur.
Néanmoins, le surveiller vous permettra de vous assurer de ne pas avoir de débordement sur certains comportements, c'est la vision globale du chargement de votre page. D'autant plus que Googlebot se rapproche de plus en plus d'un internaute lambda, et exécute depuis un moment déjà le javascript de vos pages !
Comment faire ces mesures et corriger son site ?
DareBoost, l'outil français testé et approuvé :-)
Toutes ces mesures peuvent être effectuées facilement grâce à des outils en ligne dédiés à la performance web comme DareBoost que j'ai découvert récemment. Il me semble que c'est l'un des plus complets (et cerise sur le gâteau, il est français).
L'outil vous apportera de très nombreuses recommandations pour améliorer votre site après l'avoir analysé. Essayez, vous serez surpris de la quantité de choses que cet outil analyse... Vous serez également content d'être accompagné avec autant de détails pour résoudre vos problèmes et rendre votre site plus rapide.
Concrètement, chaque analyse de DareBoost porte sur ~100 points de contrôle (d'ailleurs, pas seulement la webperf, également le SEO et l'accessibilité pour n'en citer que 2).
Pour vous guider dans la correction des points bloquants, l'outil identifie automatiquement les technologies que vous utilisez (type de serveur, CMS, framework JS, outil de mesure d'audience, etc.). Ainsi, les conseils fournis sont extrêmement précis (et en français, c'est toujours plus sympa).
Une fois que vous aurez corrigé la plupart de vos pages, et que vous aurez constaté qu'avoir un site rapide est très bénéfique (expérience utilisateur, taux de conversion, etc.), vous voudrez conserver ces bonnes performances. Profitez donc de l'offre de surveillance de DareBoost : dès qu'un problème est détecté, vous êtes prévenu. Un monitoring synthétique des pages les plus stratégiques est très simple à mettre en place. En cas de problème, la défaillance est décrite en détails afin de comprendre son origine. Enfin, vous recevrez chaque semaine un rapport sur la performance de votre site web.
En tant que consultant, j'ai bien apprécié leur offre permettant de générer des rapports en marque blanche. Si vous aussi vous êtes prestataire de services (par exemple SEO), je suppose que vous trouverez comment l'intégrer dans vos prestations...
Voici ce que ça donne sur la page d'accueil du site LeMonde.fr... qui n'a pas obtenu de très bons scores !
D'abord, un score global et une synthèse des résultats :
Ensuite, les principaux KPI :
Enfin, le sommaire des conseils personnalisés :
Sans oublier un gadget qui se révèle en fait assez pratique : une sorte de vidéo créée à partir d'images prises à différents moments du chargement de la page :
Autres outils possibles
D'abord, allez lire les conseils de Google et de Yahoo, ils sont très bons.
Ensuite, testez les perfs directement dans votre navigateur, avec Firefox Developer Tools sur Firefox ou les outils pour développeurs intégrés à Chrome, ou des plugins tels que YSlow.
Google ne propose plus de plugin mais un outil en ligne : Google PageSpeed Insights.
Parmi les outils de test de webperf les plus connus, je vous conseille Pingdom ou GTmetrix. Ils sont bien mais ne mesurent malheureusement ni le start render, ni le visullay complete, ni le speedindex. Et surtout les conseils ne sont pas en français comme avec DareBoost !
Il y a aussi le classique WebPageTest, très complet pour la partie mesure mais trop complexe à utiliser pour un public moyennement technique (avec une interface pas très agréable et uniquement en anglais).
Enfin, Google Search Console fournit également des mesures concernant le temps de téléchargement (tout comme mon outil RM Tech) : j'y reviendrai dans un prochain dossier.
Dareboost est vraiment bien pour tester car il indique de manière très claire les 3 indicateurs de vitesse importants à mes yeux, le premier octet important pour le crawl, le début d'affichage et la fin de chargement pour l'expérience utilisateur. Toutes les techniques de compression, d'optim d'image que l'ont peut mettre en place peuvent énormément jouer sur le premier octet car elles nécessitent du temps côté serveur. Par exemple sur mon site j'ai choisi de ne pas compresser les données entre mon serveur et mon CDN, ça faisait exploser le premier octet même si j'y gagnais en temps d'affichage total. C'est donc une histoire de compromis, les 3 indicateurs que proposent Dareboost sont cohérents je pense.
Poids de la page : 708KB
20 requêtes
PageSpeed : 99%
YSlow : 98%
Dareboost : 96%
Perf Grade Pingdom : 100%
@Brienois
Je tiens à préciser une chose tout d'abord : l'article ne présente pas la performance comme une nécessité absolue pour le SEO, c'est un facteur parmi d'autres. Mais il y a d'autres motivations, et elles sont nombreuses.
Prendre note également que la performance est un domaine de compromis, et que chaque acteur fait face à des contraintes qui lui sont propres.
Concernant Google, il ne joue tout simplement pas avec les mêmes règles que nous : pas de meta description... nous sommes assez peu à pouvoir nous permettre ce genre de choses. Il faut bien comprendre que Google n'est pas vraiment un site standard...
Mais oui, nous travaillons également avec de grands groupes, le besoin de rapidité sur le web est assez universel.
Re-Bonjour
Suis désolé d'être le poil a gratter, mais je pense sincèrement que ces discussions techniques comportent beaucoup de "masturbation intellectuelle"
J'ai continué mes petits tests avec Dareboost dont voici les résultats:
Yahoo : 78 %
Google : 84 %
Orange : 83 %
Alors, je dis a Damien qu'il devrait proposer ses services à ces sociétés, puisqu'il assure pouvoir faire mieux que Google (en dessous de 90, il y a des choses simples à faire !)
Je suis tout nouveau sur le forum mais j'ai voulu voir un peu ce qu'il en était des résultats de test appliqués à dareboost et webrankinfo..
Dareboost : 99/100
Webrankinfo : 67/100
Je ne m'estime pas faire partie des meilleurs mais mes sites tournent entre 63 et 75 /100 et je suis très souvent devant des agences renommées sur recherche par mots clés.
Je crois qu'on devrait essayer de travailler surtout sur les contenus en les allégeant le plus possible, en respectant les règles de base et ensuite, passer des heures pour gagner 2 ou 3 %... Le jeu en vaut il la chandelle ?
Pour ma part: pas du tout
Olivier-HCR: rien à redire sur la page d'accueil, beau travail! Le HTTPS gratuit arrive bientôt (cf Let's Encrypt évoqué plus haut dans les commentaires), mais il faut encore patienter un peu.
Il reste quelques corrections sur d'autres pages, mais rien d'impératif, sur ce que j'ai observé.
J'utilise Dareboost depuis plusieurs année et j'en suis satisfait ( a mon niveau).
J'ai actuellement un Score de 99 / 100 , que puis je faire d'autre ?
Voici la page du rapport:
https://www.dareboost.com/fr/report/560294700cf245b55c45808a
Et mon site : hamster-russe.fr
Bien évidement, j'aimerai bien passé en https (gratuitement) , mais ou et qui ?
Les clients de WebRankExpert ne sont pas sur de l'hébergement mutualisé, mais ne dramatisons pas. Avoir un TTFB supérieur à 200ms et même proche de la seconde ne vous fera pas déréférencer. Le positionnement est relatif, celui que vous devancez dans les SERPs fait juste pas aussi bien que vous et cela ne suffit pas à vous attribuer le prix de l'excellence. On continuera à bien se classer, même en approchant la demi-seconde si par ailleurs en dehors de la vitesse, le contenu est de qualité et bien optimisé.
@Forepeek : il ne s'agit pas ici des clients de WebRankExpert (clients que vous ne connaissez pas d'ailleurs) mais de tous les lecteurs de cet article. Une grande partie d'entre eux sont sur des serveurs mutualisés (il suffit de discuter dans le forum pour s'en rendre compte).
Nulle part il est écrit qu'avoir un mauvais temps de réponse fera "déréférencer" le site. Il n'est pas non plus indiqué que ça vous fera dépasser les concurrents.
C'est simplement qu'avoir un site est rapide fait partie des fondamentaux du SEO. On peut choisir de minimiser son importance, comme on pourrait aussi le faire sur la compatibilité mobile, sur les contenus dupliqués, sur la profondeur des pages, etc. A force, on est loin derrière les concurrents !
Il faut donc essayer de progresser sur tous les fronts, et cet article est là pour apporter de l'information et des solutions.
""All" = "All best practices" disponible en haut à gauche quand on visualise les conseils."
Ca ne suffit pas et ça n'est pas cohérent : il faut deviner que cette option existe, mais uniquement dans un menu qui apparait si on est assez bas dans la page. Sauf que si je vais sur un rapport et que je filtre sur quelque chose avec peu de tests comme :
https://www.dareboost.com/en/report/55fbc8b90cf245b55c435951
avec un filtre sur Apache, la page est trop courte pour déclencher l'affichage du menu, par conséquent l'option n'est pas affichée.
On dispose aussi d'un formulaire de contact ;)
"All" = "All best practices" disponible en haut à gauche quand on visualise les conseils.
Bon, on ne va pas squatter les commentaires de WRI... Je vais te faire quelques retours via les votes de l'outil, ça sera plus simple. Enfin c'est pas non plus génial, c'est quand même un peu limité mais bon... c'est déjà ça.
Un problème en passant par les votes c'est que ça ne permet ni de suggérer d'autres tests, ni de faire des remarques plus générales sur l'outil.
Un exemple : dans Best practices summary, on peut choisir de n'afficher qu'un type de recommandations. Mais une fois ce choix fait, il n'est pas possible de le désactiver, soit en re-cliquant dessus, soit (ce qui serait mieux) via une option "All".
Joey, merci à nouveau pour ce retour complet.
Nous recommandons bel et bien le HTTPs, si le site utilisé ne l'utilise pas (catégorie sécurité, le boost SEO est également mentionné dans le conseil). Nous n'y parlons pas encore de LetsEncrypt, car le projet ouvre à peine sa beta, mais vous verrez ici que nous avons abordé le sujet il y a plusieurs mois déjà : http://blog.dareboost.com/fr/2015/04/chrome-firefox-et-recherches-google-passage-en-force-du-https/
Oui, le 1024*768 n'est pas le plus courant, mais nos tests sont gracieusement offerts, et limiter la résolution nous permet de limiter les coûts associés (capture vidéo, etc).
Concernant les commentaires HTML, nous nous contentons d'expliquer pourquoi ils peuvent être utilisés, mais peut être notre anglais n'est pas le meilleur et je rate une nuance ? (pour précision: le service est également disponible en français).
N'hésitez pas à "voter" directement sur un conseil dans ce genre de cas, nous recevrons votre commentaire et le contexte, ce qui nous permet de faire évoluer constamment le référentiel et de l'enrichir.
"Nous ne détectons pas SPDY (idem pour HTTP2) (...) c'est une limitation de l'outil, mais la part de sites éligibles à ces technologies (over HTTPS) analysés chez nous reste très minoritaire."
C'est bien ça le problème que je pointais : l'outil donne des conseils pour le SEO, la vitesse de chargement et la sécurité. Actuellement la meilleure pratique "de base" est d'utiliser SPDY/H2 sur HTTPS pour combiner sécurité et rapidité, et même si c'est encore un signal très (très) faible, c'est aussi un signal pour le SEO.
L'outil devrait au mieux encourager à aller dans cette direction, ou au moins éviter de donner des conseils contre-productifs dans ce cas de figure.
De plus, la situation pourrait bien évoluer rapidement avec l'arrivée de BONS certificats gratuits. Oui ça existe déjà mais c'est vraiment nul actuellement. Ce qui arrive est parrainé par Mozilla, Cisco, Akamai, la EFF... c'est d'un tout autre niveau : https://letsencrypt.org
"Concernant le redimensionnement d'images, il est certes généralement plus complexe de mettre en oeuvre les choses de façon "propre", mais c'est loin d'être impossible."
Pas impossible dans certains cas très particuliers. Mais bon, c'est un long sujet qu'on ne va pas pouvoir traiter dans les commentaires de WRI.
"Le test est effectué en 1024*768, ce qui est paramétrable pour nos clients."
C'est une bonne chose mais l'outil devrait être préconfiguré avec les réglages les plus utiles possibles. Si le réglage par défaut est 1024 alors que les utilisateurs sont plutôt en 1280, c'est à vous de le paramétrer pour qu'il renvoie les meilleurs conseils possibles en fonction du parc actuel. C'est ce qui fait la valeur de ce type d'outils.
Pour les commentaires, sur une page au HTML minifié, sans commentaires, le message informatif ressemble à une bonne pratique :
Did you know -> tag "quality"
i No HTML code is commented
Comments allow to detail a portion of code, and help you to navigate more efficiently in the DOM. However, make sure that no sensitive information is exposed in your comments.
None of your comments contains HTML code."
Sur un rapport pour une page dont le HTML n'est pas minifié et contenant des commentaires :
The other tips -> tag Quality :
! Avoid HTML code in comments
Comments allow to detail a portion of code, and help you to navigate more efficiently in the DOM. However, make sure that no sensitive information is exposed in your comments.
Ca n'était qu'un détail pris complètement au hasard pour répondre à Olivier.
Selon moi il y a bien d'autres priorités, mais bon... c'est votre outil, c'est vos specs, vos priorités :-)
@Joey, merci pour ces précisions sur les remarques initiales.
Nous ne détectons pas SPDY (idem pour HTTP2) car nous ne l'utilisons pas lors de nos analyses, justement car nous avons en cours un chantier pour mettre en place un référentiel adapté de recommandations. J'en conviens, c'est une limitation de l'outil, mais la part de sites éligibles à ces technologies (over HTTPS) analysés chez nous reste très minoritaire.
Concernant le redimensionnement d'images, il est certes généralement plus complexe de mettre en oeuvre les choses de façon "propre", mais c'est loin d'être impossible. Le test est effectué en 1024*768, ce qui est paramétrable pour nos clients.
Pouvez-vous m'indiquez où avez-vous vu une recommandation sur l'ajout de commentaires dans le HTML ? Je pense qu'il y a eu erreur de formulation de notre côté ou d'interprétation du vôtre.
un exemple : il ne détecte pas SPDY et affiche les conseils sur les CSS sprites (discutables, particulièrement avec SPDY), conseille d'utiliser un domaine cookieless alors que les cookies sont minimaux (ce qui casse un gros avantage de SPDY/H2). Et il n'y a aucun avertissement pour prévenir que les cookies peuvent aussi affecter des ressources qui semblent statiques.
Autre technique que l'outil n'apprécie pas : le redimensionnement des images coté client. Pour un site "Responsive" c'est quasi inévitable. Et ce redimensionnement est détecté sur mon site, donc le test s'effectue probablement en 1024, une résolution qui n'est pas la plus représentative pour le desktop (y compris en incluant les tablettes).
Si on minimise son HTML c'est bien. Mais il conseille quand même de mettre des commentaires comme bonne pratique. Et s'il y en a, il conseille de les retirer.
Voilà juste trois exemple pour illustrer le fait que ce ne sont pas des critiques gratuites.
Voilà un commentaire bien plus constructif ;-)
Le problème des outils comme Dareboost, c'est qu'ils peuvent donner de très mauvais conseils et les asséner comme des vérités. Je l'ai testé pour deux sites : dans un cas il donne des conseils contre-productifs, dans l'autre il oublie des choses qui me paraissent essentielles. Et il me donne même des suggestions contradictoires.
Bref, ce genre d'outils est utile pour un site dans un mauvais état qui doit être optimisé par quelqu'un qui ne connait rien à l'optimisation. En suivant les conseils, globalement le site sera meilleur.
Par contre si quelqu'un suit les conseils de l'outil et passe derrière une personne qui a optimisé précautionneusement un site, non seulement ça peut demander beaucoup de temps mais en plus le résultat sera négatif, voire même franchement négatif.
Je trouve aussi que la présentation et le classement des priorités de Dareboost devrait être revu et épuré, en tenant compte des possibilités réelles d'action de son utilisateur.
Bref, pour le moment je le trouve trop bêtement technique. Mais c'est une base intéressante pour évoluer vers quelque chose qui manque vraiment : un outil "intelligent".
@Joey : ce commentaire serait nettement plus constructif avec des exemples, car pour l'instant il "assène des vérités" pour casser ce genre d'outils...
Dareboost a l'air de vraiment apporter une couche de conseil supplémentaire avec :
- Proposition de plugin wordpress adaptés pour solutionner les problèmes
- Détection des technologies utilisées
- Analyse très globale SEO, Validation, Performances
Je ne connaissais pas mais je crois que je vais maintenant l'ajouter dans ma BAO ;)
Merci pour cet article !
@LCONSEIL: je confirme le propos d'Olivier, s'intéresser à ses concurrents est une bonne approche.
Se focaliser uniquement sur le score global comporte des risques, car même avec un bon score, certaines recommandations peuvent avoir des impacts importants, alors que la correction est simple. Il est rare qu'avec un score inférieur à 90 il n'y ait pas d'action "quick-win" à mettre en oeuvre.
@Nicolas : WPT est un excellent outil, mais dont l'aspect recommandation reste limité à Page Speed Insights, dont le nombre de points de contrôle est bien plus limité que ce que nous offrons.
Il est effectivement possible de faire de la surveillance avec une instance privée de WPT, mais cela oblige a minima d'y combiner d'autres solutions, et généralement de procéder à des développements spécifiques.
"Dareboost est basé en partie sur WebPageTest " > nous n'utilisons pas WPT mais uniquement le composant de calcul du speedindex, puisque c'est indice a été introduit par WPT
Ok pour l'interface un peu austère, mais WebPageTest est le plus complet des outils quand on parle de performance web ! Gratuit et développé par un Googler, il est constamment mis à jour et peut être installé en local pour des tests automatisés. Dareboost apporte quelques tests supplémentaires et des explications en français, à voir si cela vaut les 30 euros mensuels...
D'ailleurs je suis presque sur que Dareboost est basé en partie sur WebPageTest (speedindex, capture vidéo...) :)
@Nicolas : j'ai été honnête, j'ai listé tout un tas d'autres outils. Moi j'ai eu un bon fit avec DareBoost, d'où cet article et leur mise en avant.
Je doute qu'ils utilisent WebPageTest, par contre DareBoost intègre tous les conseils de Google PageSpeed et Yahoo YSlow, ça c'est sûr.
merci pour ce très bon article. Quel est à votre avis le score minimum a ne pas atteindre ?
merci
Laurent
@LConseil : je ne connais pas le score minimum conseillé, mais une façon de faire serait de comparer aux concurrents