Afficher vite le contenu principal de la page sur mobile
Description
Ce critère mesure la vitesse de la page dans les conditions d’un téléphone moyen : iPand la charge une fois, à froid, sur un Pixel 7 simulé, avec le réseau et le processeur ralentis du profil mobile de Lighthouse. Il relève l’affichage du plus grand élément visible (LCP) et le temps de blocage par les scripts (TBT) ; le délai de réponse du serveur (TTFB) est mesuré lors de la récupération directe de la page.
C’est une mesure de laboratoire, pas la vitesse vécue par vos visiteurs réels (rapport Chrome UX).
Pourquoi c’est important pour les IA
Google recommande d’offrir une bonne expérience de page pour apparaître dans ses fonctionnalités d’IA, et la vitesse d’affichage en fait partie. Un serveur lent freine aussi l’exploration : quand les temps de réponse s’allongent, Google explore moins de pages de votre site.
- Le LCP marque le moment où le contenu principal devient visible : web.dev le juge bon à 2,5 s au plus.
- Le TTFB n’est pas un Core Web Vital, mais web.dev conseille de ne pas dépasser 0,8 s : tout le reste du chargement attend la réponse du serveur.
- Chaque tâche JavaScript de plus de 50 ms bloque la page ; le TBT additionne ces blocages et signale une page qui réagit mal aux actions des visiteurs.
Comment corriger
- 1 Accélérez l’affichage de l’élément principal Le LCP ne doit pas dépasser 2,5 s ; c’est la mesure qui pèse le plus dans le critère. Repérez l’élément principal, souvent l’image du haut de page ou le premier titre. Servez-le à la bonne taille et dans un format léger, ne le chargez pas en différé (loading=lazy) et préchargez-le si le navigateur le découvre tard.
- 2 Faites répondre le serveur plus vite Le serveur doit envoyer les premiers octets de la page en 0,8 s au plus. Mettez les pages en cache côté serveur ou sur un CDN, évitez les redirections avant la page et allégez les traitements faits à chaque visite, comme les requêtes à la base de données ou les extensions du CMS.
- 3 Différez les scripts non essentiels Le TBT ne doit pas dépasser 200 ms. Chargez les scripts avec defer ou async, retirez les scripts tiers devenus inutiles (widgets, outils de suivi en double) et découpez les traitements longs. La part de chaque tâche qui dépasse 50 ms s’ajoute au TBT.
- 4 Gardez une marge sous les seuils Testez la page avec Lighthouse ou PageSpeed Insights en mode mobile, dans des conditions comparables à celles d’iPand. Une valeur à ± 10 % d’un seuil garde le verdict de l’analyse précédente, pour que le statut ne bascule pas d’un jour à l’autre : visez nettement en dessous.
À retenir
iPand juge la page comme la verrait un téléphone moyen : contenu principal en 2,5 s, serveur en 0,8 s, blocage par les scripts de 200 ms au plus. Gardez une marge sous ces seuils pour un verdict stable.
