Vitesse d'affichage d'une page web

Quatre moments dans le chargement d'une page

Quand un visiteur clique, quatre choses se produisent l'une après l'autre, et chacune se mesure séparément. Le serveur répond, ce qui donne le TTFB. Le navigateur affiche le premier élément de contenu, c'est le FCP. Il termine le plus grand bloc visible, texte ou image, c'est le LCP. Enfin la page réagit aux clics et aux saisies, ce que mesure l'INP.

Un site peut être irréprochable sur les trois premières étapes et rester pénible à utiliser parce que le menu met une demi-seconde à s'ouvrir. Un autre affichera son titre instantanément et laissera le visiteur devant un espace blanc pendant trois secondes, le temps que l'image principale arrive. Parler de « page lente » sans préciser laquelle de ces quatre mesures décroche, c'est se condamner à optimiser à l'aveugle.

La stabilité visuelle, mesurée par le CLS, n'est pas une vitesse, mais elle se traite avec le même outillage. Une page qui bouge sous le doigt pendant son chargement donne exactement la même impression de site mal fini.

Les seuils publiés par Google

Trois de ces mesures font partie des Core Web Vitals et ont des seuils officiels. Le TTFB et le FCP n'en font pas partie, mais Google publie aussi leurs valeurs de référence, et ce sont celles qui servent au diagnostic.

Ces seuils s'apprécient au 75e centile des visites d'un mois glissant, pas sur un test unique depuis votre bureau en fibre. Autrement dit, une page est « bonne » quand trois visiteurs sur quatre l'obtiennent dans le temps indiqué, ce qui laisse la place aux connexions dégradées sans laisser passer un site lent pour la moitié de son audience.

Le serveur donne le départ

Le TTFB additionne tout ce qui précède le premier octet utile : les redirections éventuelles, la résolution DNS, la négociation TLS, puis le temps que met le serveur à fabriquer le HTML. Tant qu'il n'a pas répondu, le navigateur n'a rien à faire. C'est pour cette raison que je commence toujours un diagnostic de lenteur par cette mesure, avant même de regarder le poids des images.

Elle se vérifie en une commande, sans rien installer.

Le chiffre renvoyé est en secondes. Lancez la commande trois fois de suite. Si le premier appel est lent et les suivants rapides, vous regardez un cache qui se remplit, et les visiteurs qui arrivent sur une page froide subissent le premier chiffre. Les causes habituelles d'un TTFB élevé sont peu nombreuses.

• Une page régénérée à chaque visite. Sans cache de page complète, un WordPress exécute des dizaines de requêtes SQL pour chaque visiteur, y compris les robots.
• Un hébergement mutualisé saturé. Les ressources se partagent avec des centaines de sites, et le TTFB devient irrégulier selon l'heure, ce que révèlent trois mesures espacées dans la journée.
• Des redirections en chaîne. Un http:// vers https:// vers www ajoute deux allers-retours complets avant que le serveur ne commence à travailler.
• Une distance géographique inutile. Un serveur américain pour une audience française coûte de l'ordre de 100 millisecondes par échange réseau, que l'on ne rattrape jamais ensuite.

Le cache de page complète règle le premier point, un hébergement adapté au trafic réel le deuxième, et une redirection unique vers l'URL canonique le troisième. Le CDN, lui, accélère surtout les fichiers statiques et ne sauvera pas un serveur qui met deux secondes à assembler le HTML.

Les freins les plus fréquents

Chaque frein dégrade une mesure précise, et se confirme par un test précis. C'est cette correspondance qui permet de trancher entre deux corrections plutôt que de tout faire en même temps.

Le dernier mérite une attention particulière, parce qu'il échappe au développeur du site. Un widget de chat ou une régie ajoutée par le service marketing peut à lui seul faire basculer l'INP du vert au rouge, sans qu'une seule ligne du thème ait bougé. Bloquer son domaine dans l'onglet Réseau et relancer la mesure donne la réponse en deux minutes, et fournit surtout un argument chiffré pour la discussion qui suivra.

Mesurer avant de corriger

Deux familles d'outils coexistent et racontent des choses différentes. Les mesures de laboratoire rejouent un chargement dans des conditions standardisées, toujours identiques, donc parfaites pour comparer un avant et un après. Les données de terrain viennent des navigateurs Chrome de vos visiteurs réels, avec leurs téléphones et leurs réseaux, et ce sont celles que les systèmes de classement utilisent.

• PageSpeed Insights affiche les deux : données terrain en haut quand la page reçoit assez de trafic, audit Lighthouse en dessous. Le bloc du haut est celui qui compte, celui du bas explique pourquoi.
• La Search Console regroupe les URL par problème à l'échelle du site, ce qui permet de corriger un gabarit plutôt qu'une page. C'est le bon point d'entrée quand le sujet dépasse une page isolée, traité sur la page performance d'un site web.
• WebPageTest teste depuis une autre ville, une autre connexion, un autre appareil, et détaille le chargement ressource par ressource.
• Les outils de développement de Chrome donnent la cascade de chargement et les tâches longues, avec la possibilité de brider la connexion pour reproduire une 4G lente.

Lancez toutes ces mesures en navigation privée, sans extension active. Un bloqueur de publicités installé dans votre navigateur supprime précisément les scripts qui plombent vos visiteurs, et le diagnostic devient faux.

Dans quel ordre corriger

Les leviers ne se valent pas et ne s'appliquent pas tous en même temps. L'ordre suivant suit la chaîne de chargement, donc chaque étape conditionne la suivante.

1. TTFB au-dessus de 0,8 seconde

   Cache de page complète, version de PHP récente avec OPcache, requêtes de base de données et plugins superflus, redirections en chaîne. Rien d'autre ne sert tant que ce point n'est pas réglé, puisque le navigateur attend.

2. TTFB correct mais LCP au-delà de 2,5 secondes

   Identifiez l'élément responsable, que PageSpeed Insights nomme explicitement. Si c'est une image, servez-la en WebP ou AVIF, à la dimension réelle d'affichage, avec fetchpriority="high" et sans chargement différé. Si c'est un bloc de texte, la police est souvent en cause.

3. LCP correct mais INP au-delà de 200 millisecondes

   Le sujet devient le JavaScript. Différez ce qui n'est pas nécessaire au premier rendu, retirez les scripts tiers qui ne servent plus, découpez les traitements longs. Un thème à constructeur de pages charge souvent sur chaque page le code de toutes les fonctionnalités du site.

4. CLS au-dessus de 0,1

   Déclarez width et height sur les images et les vidéos, réservez la place des bannières et des publicités insérées après coup, et choisissez une police de repli aux métriques proches pour éviter le saut au moment de la substitution.

Sur un site vitrine ou éditorial, les deux premières étapes suffisent presque toujours à faire passer la page dans le vert. L'INP devient le sujet principal sur les applications, les configurateurs et les sites chargés de scripts marketing.

Le chargement différé des images

L'attribut loading="lazy" demande au navigateur de ne télécharger une image qu'à l'approche de la zone visible. Sur une page longue qui en compte trente, le gain sur le chargement initial est net.

L'erreur classique consiste à l'appliquer partout, y compris à l'image d'en-tête. Le navigateur retarde alors précisément l'élément qui déclenche le LCP, et la mesure se dégrade au lieu de s'améliorer. WordPress a connu exactement ce problème. Le chargement différé automatique introduit en version 5.5 abîmait le LCP, et la version 5.9 a corrigé le tir en excluant la première image du contenu, avec un gain médian mesuré autour de 7 %. Sur un thème à deux ou trois colonnes où plusieurs images sont visibles d'emblée, le filtre wp_omit_loading_attr_threshold permet d'en exclure davantage.

Tout ce qui est visible sans faire défiler se charge normalement, avec fetchpriority="high" sur l'élément LCP. Le reste passe en différé.

Ce que la vitesse pèse vraiment dans le classement

Google a annoncé la vitesse comme signal de classement en 2010 pour les recherches sur ordinateur, l'a étendue au mobile en juillet 2018 avec la Speed Update, puis a remplacé ces signaux par les Core Web Vitals en juin 2021. La documentation actuelle reste prudente. Les Core Web Vitals sont utilisés par les systèmes de classement, il n'existe pas de signal unique, et Google précise qu'il cherche avant tout le contenu le plus pertinent, même quand l'expérience de page est médiocre.

Concrètement, la vitesse départage rarement une page hors sujet d'une page pertinente, et souvent deux pages également pertinentes. C'est une raison suffisante pour s'en occuper, mais pas pour attendre un bond de positions après avoir gagné 300 millisecondes.

Du côté du chiffre d'affaires, deux statistiques circulent depuis dix ans. L'abandon de 53 % des visites mobiles au-delà de trois secondes vient d'une étude Google et SOASTA de 2016, menée sur des sites marchands. La baisse de 7 % des conversions vient d'un rapport Akamai de 2017, et elle est presque toujours mal citée. Ces 7 % correspondent à un retard de 100 millisecondes, pas d'une seconde, et là encore sur du commerce en ligne. Les reprendre telles quelles pour un site de services revient à promettre un résultat que personne n'a mesuré.

La mesure qui vaut est la vôtre. Dans Google Analytics, comparez le taux de conversion de vos pages d'entrée classées par LCP terrain ; dans la Search Console, regardez si les URL passées au vert ont bougé différemment des autres sur les mois suivants. Quand j'accompagne un site sur ce sujet, c'est ce relevé avant-après que je mets dans le rapport, pas une statistique d'un rapport sectoriel vieux de dix ans.

Questions fréquentes

Quelle vitesse de chargement faut-il viser ?

Un LCP sous 2,5 secondes et un TTFB sous 0,8 seconde, mesurés au 75e centile des visites réelles et non sur un test isolé. Ces deux seuils sont ceux que Google publie dans sa documentation Web Vitals. Sur mobile, atteindre 2,5 secondes demande plus de travail que sur ordinateur, à cause des réseaux et des processeurs, mais le seuil reste le même.

Faut-il viser 100/100 sur PageSpeed Insights ?

Non. Le score sur 100 est une note de laboratoire, calculée sur une simulation de chargement avec un appareil et un réseau standardisés. Ce qui compte pour le classement, ce sont les données terrain issues de vos visiteurs, affichées en haut du rapport quand votre page reçoit assez de trafic. Un site peut afficher 70 en laboratoire et passer les trois seuils sur le terrain, et l'inverse existe aussi.

Par quoi commencer quand une page est lente partout ?

Par le temps de réponse du serveur. Tant que le premier octet arrive après 800 millisecondes, aucune optimisation d'image ou de script ne rattrapera ce retard, puisque le navigateur attend sans rien pouvoir afficher. Une fois le serveur en dessous du seuil, on traite l'élément qui déclenche le LCP, puis le JavaScript qui pèse sur la réactivité.

Mon site est lent mais bien positionné, faut-il quand même optimiser ?

La pertinence prime sur l'expérience de page, et Google l'écrit noir sur blanc, donc une page lente peut très bien tenir la première position. L'arbitrage se fait plutôt sur le revenu que sur le classement. Si la page convertit, mesurez ce que la lenteur vous coûte en abandons avant d'engager des jours de développement. Si elle est aussi pertinente que ses concurrentes, la vitesse devient un des signaux qui les départagent.