Il y a un chiffre qui me hante depuis des années : 53 % des visiteurs mobiles quittent un site qui met plus de trois secondes à charger. Je ne l'ai pas trouvé dans une étude marketing. Je l'ai vu dans mes propres statistiques, un par un, quand j'ai enfin connecté mes rapports Analytics aux données terrain de la Search Console. Trois secondes. C'est le temps qu'il faut à un utilisateur pour décider que votre site ne mérite pas son attention.
Le problème, c'est que la plupart des articles sur le Core Web Vitals vous expliquent la théorie et vous refilent une liste de courses génériques. Mais améliorer les Core Web Vitals sur mobile, c'est un travail de chirurgie, pas de décoration. Et la chirurgie, ça se pratique sur un patient précis, pas sur une capture d'écran de PageSpeed.
Points clés à retenir
- Le LCP mobile est presque toujours plombé par le TTFB et le poids des images — pas par le JavaScript, contrairement à ce qu'on croit.
- Le CLS sur mobile vient rarement des images sans dimensions : il vient des polices personnalisées et des bannières publicitaires injectées après coup.
- L'INP a remplacé le FID depuis mars 2024. Si votre outil parle encore de FID, il vous ment sur l'expérience réelle.
- Un test PageSpeed est une photo. Les données de terrain (CrUX) sont le film. Le classement se joue sur le film.
- Optimiser pour un score de 100 vous fera perdre du temps. Optimiser pour l'INP et le LCP de vos pages qui convertissent vous en fera gagner.
Pourquoi les Core Web Vitals mobiles ne se traitent pas comme ceux du desktop
La première fois que j'ai audité sérieusement mon propre site, j'étais fier : score desktop de 96, tout au vert. Le mobile ? 38. J'ai cru à un bug de Lighthouse. C'était moi.
Le mobile n'est pas une version réduite du desktop. C'est un environnement hostile. Le processeur est plus lent, le réseau fluctue, la mémoire disponible fond comme neige au soleil dès qu'un onglet reste ouvert. Google le sait, et c'est pour ça qu'il évalue le mobile en priorité depuis que l'indexation mobile-first est devenue la norme.
La différence entre un test synthétique et vos vrais utilisateurs
PageSpeed Insights vous donne deux onglets : les données de laboratoire et les données de terrain. La plupart des gens regardent le premier. Erreur classique.
Le laboratoire, c'est un serveur Google qui teste votre page avec une connexion simulée et un processeur bridé. Le terrain, c'est le rapport d'expérience utilisateur Chrome, agrégeant les mesures réelles de personnes qui ont visité votre site sur les 28 derniers jours.
- Le test synthétique vous dit ce qui pourrait se passer dans des conditions idéales.
- Le terrain vous dit ce qui se passe vraiment chez vos visiteurs, avec leur forfait mobile à 4G saturée et leur téléphone acheté il y a quatre ans.
- Et surtout : Google classe votre site sur la base du terrain. Pas du laboratoire. Jamais.
J'ai passé des semaines à optimiser un score Lighthouse pour découvrir que mon TTFB réel sur mobile était de 1,4 seconde. Le test synthétique affichait 0,2 s. L'écart venait de mon hébergement et de la distance géographique avec mes visiteurs. Une leçon que j'aurais pu apprendre en regardant le bon onglet dès le premier jour.
Comment améliorer concrètement le LCP sur mobile
Le Largest Contentful Paint mesure le temps d'affichage du plus grand élément visible dans la fenêtre initiale. Sur mobile, cet élément est très souvent une image d'en-tête, une bannière ou un gros bloc de titre. Et c'est justement là que ça dérape.
Réduire le TTFB avant tout le reste
On m'a demandé mille fois : « par où je commence ? ». La réponse est frustrante mais imparable — commencez par le serveur. Si votre TTFB dépasse 800 ms sur mobile, aucune optimisation d'image ne vous sauvera. Vous réparez la fuite pendant que le tuyau explose.
Ce que j'ai fait sur un projet client l'an dernier : migration vers un hébergement avec serveurs en Europe de l'Ouest, activation d'un cache de page complet côté serveur, mise en place d'un CDN. Le TTFB est passé de 1,2 s à 280 ms. Le LCP a suivi mécaniquement : de 3,8 s à 1,9 s. Sans toucher une seule image.
Les images du LCP : priorité et format
Une fois le serveur assaini, on s'attaque à l'élément LCP lui-même. Trois leviers, dans cet ordre :
- Chargez l'image LCP en priorité. Ajoutez
fetchpriority="high"sur cette seule image. Pas sur les quinze autres. - Format moderne obligatoire. Le WebP puis l'AVIF font généralement gagner 30 à 50 % de poids à qualité visuelle comparable.
- Préchargez la police si elle sert au titre principal, et seulement dans ce cas.
Avouons-le : j'ai longtemps zappé le fetchpriority en le trouvant anecdotique. Sur un site e-commerce, il a fait gagner 400 ms de LCP à lui seul. Quatre cents millisecondes. Pour un attribut.
Le vrai problème : personne n'a une 5G parfaite
Voilà un angle que je ne vois presque jamais traité. Votre utilisateur mobile n'est pas dans un laboratoire. Il est dans le métro, dans un ascenseur, dans un train qui traverse la campagne. Le débit tombe à 2 Mb/s. La latence grimpe à 300 ms. Le réseau change de cellule trois fois pendant le chargement.
Dans ces conditions, chaque requête compte double. Chaque redirection est un couperet. Chaque script tiers bloquant est une punition. Réduisez le nombre de requêtes avant d'optimiser leur poids. C'est contre-intuitif, mais un fichier de 200 Ko vaut mieux que quatre fichiers de 60 Ko quand le réseau hoquette.
| Levier | Impact typique sur le LCP mobile | Effort |
|---|---|---|
| Réduction du TTFB (cache + CDN) | Fort — souvent 500 ms à 1,5 s | Moyen |
fetchpriority="high" sur l'image LCP | Modéré à fort — 200 à 400 ms | Faible |
| Conversion WebP/AVIF | Modéré — gain de poids, gain de temps | Faible |
| Suppression des redirections en chaîne | Variable — jusqu'à 300 ms par saut évité | Faible |
| Préchargement des polices critiques | Faible à modéré | Faible |
Le CLS mobile : les vrais coupables ne sont pas ceux qu'on croit
Tout le monde vous dira de mettre des width et height sur vos images. C'est vrai. C'est aussi la partie facile. Sur mobile, le Cumulative Layout Shift a deux causes bien plus vicieuses.
Les polices personnalisées qui décalent tout
Une police custom met quelques centaines de millisecondes à charger. Pendant ce temps, le navigateur affiche une police de secours. Quand la vraie arrive, tout se redessine, tout bouge. Sur un titre de section, ce décalage peut à lui seul faire exploser votre score de stabilité visuelle.
La solution que j'applique systématiquement aujourd'hui : font-display: swap combiné à une police de secours métriquement proche via size-adjust. Résultat, l'œil ne perçoit plus le basculement. J'ai fait tomber un CLS de 0,24 à 0,04 sur un site de presse avec cette seule technique.
Le contenu injecté après le rendu
Bannières cookies qui apparaissent en bas, bandeaux promotionnels chargés en JavaScript, encarts publicitaires sans hauteur réservée. Chacun de ces éléments pousse le contenu vers le bas au moment où l'utilisateur s'apprêtait à lire.
La règle est simple, même si elle est pénible à faire respecter en réunion : réservez la place de tout élément injecté. Un conteneur avec une hauteur minimale fixe, une classe CSS dédiée, et le tour est joué. Le layout ne bouge plus. L'utilisateur ne perd plus son doigt au moment de cliquer.
INP ou FID : la métrique qui a changé de nom (et ce que ça implique)
Beaucoup d'articles circulent encore avec le First Input Delay comme référence de réactivité. C'est périmé. Depuis mars 2024, Google a remplacé le FID par l'Interaction to Next Paint, et la différence n'est pas cosmétique.
Le FID mesurait un seul délai : entre le clic de l'utilisateur et le moment où le navigateur commençait à traiter l'événement. Il ne mesurait rien de ce qui se passait ensuite. L'INP mesure le délai total entre l'interaction et l'affichage de la mise à jour visuelle. Autrement dit, il capture ce que l'utilisateur ressent réellement : la sensation que « ça rame ».
Et franchement, c'est bien plus dur à satisfaire. J'ai vu des sites au FID impeccable se faire démolir par l'INP, parce qu'un gestionnaire d'événement JavaScript monopolisait le thread principal pendant 300 ms.
Réduire l'INP : trois pistes concrètes
- Découpez les longues tâches. Tout bloc JavaScript qui dépasse 50 ms bloque le thread. Le découper en morceaux, ou le repousser via
requestIdleCallback, change tout. - Virez les scripts tiers que vous ne contrôlez pas. Chat en direct, pixels de reciblage, A/B testing. Chacun peut être celui qui plombe votre INP sans que vous le sachiez.
- Déléguez les événements au lieu d'attacher un écouteur par élément. Sur une liste de 200 produits, ça n'est pas un détail.
Mon erreur passée : j'avais laissé tourner un script d'analytics custom qui recalculait une grille entière à chaque scroll. L'INP était catastrophique. J'ai mis deux jours à comprendre que le coupable n'était pas Google Analytics, mais mon propre code.
Quels outils utiliser pour suivre tout ça sans y passer vos soirées
Le piège, c'est de croire qu'il faut tout surveiller en permanence. Je suis passé par une phase de monitoring obsessionnel — à consulter mes scores trois fois par jour. Inutile. Ce qui compte, c'est de regarder les bonnes données aux bons moments.
Une dernière chose sur la mesure : ne vous fiez pas à un seul jour. Les Core Web Vitals sont calculés sur une fenêtre glissante de 28 jours. Une amélioration visible en laboratoire mettra parfois deux à trois semaines avant d'apparaître dans vos données de terrain. J'ai failli annuler des optimisations qui fonctionnaient très bien parce que je regardais les chiffres trop tôt.
Une optimisation qui tient dans le temps
Les Core Web Vitals ne sont pas un projet qu'on termine. C'est un régime qu'on tient. Chaque nouvelle fonctionnalité, chaque nouveau script marketing, chaque image ajoutée par un rédacteur pressé peut faire remonter votre LCP de 500 ms sans prévenir.
La vraie question n'est pas « quel est mon score ? ». C'est : mes visiteurs mobiles trouvent-ils ce qu'ils cherchent sans s'énerver ? Le jour où j'ai arrêté de chasser le 100 sur Lighthouse pour me concentrer sur les trois pages qui génèrent 80 % de mes conversions, tout a changé. Moins de temps passé. Plus de résultats mesurables.
Le reste, c'est du bruit.
