Vous voulez savoir ce qui m'a le plus énervé cette année ? Découvrir qu'un site que je suis depuis des mois affichait un LCP de 4,8 secondes sur mobile. Quatre virgule huit. Et personne, dans l'équipe, ne s'en était rendu compte. Ils regardaient tous PageSpeed sur desktop, où le score était vert. Sur un téléphone en 4G, c'était une autre histoire.
C'est le piège numéro un de l'optimisation mobile-first : on croit mesurer la vitesse, on mesure en réalité la vitesse d'une machine qui n'a rien à voir avec celle de vos visiteurs.
Points clés à retenir
- Les seuils qui comptent réellement : LCP sous 2,5 s, INP sous 200 ms, CLS sous 0,1.
- Mesurer en émulation mobile avec bridage réseau, jamais en Wi-Fi de bureau.
- Les images et le JavaScript bloquant sont responsables de la majorité des mauvais scores.
- Un gain de vitesse ne se voit pas toujours dans les positions, mais presque toujours dans les conversions.
- Le piège classique : optimiser le score Lighthouse au lieu du ressenti réel.
Pourquoi mobile-first change complètement la question de la vitesse
Google indexe la version mobile de votre site. Pas la version desktop. C'est acté depuis des années et beaucoup de gens continuent pourtant à optimiser l'affichage bureau en priorité, comme si le téléphone était une déclinaison secondaire. Le raisonnement inverse est le bon.
Le téléphone n'est pas un petit écran de bureau
Un processeur mobile récent reste deux à quatre fois plus lent qu'un processeur de bureau milieu de gamme pour exécuter du JavaScript. Ajoutez à ça une connexion instable, un onglet ouvert en arrière-plan, une batterie à 12 %, et vous obtenez des temps de réponse qui n'ont rien à voir avec ce que votre MacBook affiche.
J'ai fait l'erreur, sur un de mes premiers projets, de tester uniquement en local et sur mon laptop. Score parfait. Puis un ami m'a envoyé une capture d'écran de mon site sur son vieux téléphone : blanc pendant presque trois secondes avant que quoi que ce soit n'apparaisse. Trois secondes. Il avait fermé l'onglet.
Ce que Google mesure vraiment
Les Core Web Vitals sont trois métriques distinctes et il faut les traiter séparément :
- LCP (Largest Contentful Paint) : le temps avant que l'élément principal s'affiche. Cible : moins de 2,5 secondes.
- INP (Interaction to Next Paint) : la réactivité après un clic ou un tap. Cible : moins de 200 millisecondes.
- CLS (Cumulative Layout Shift) : les décalages de mise en page pendant le chargement. Cible : moins de 0,1.
Le LCP est le plus visible, mais l'INP est celui qui tue l'expérience sans qu'on s'en rende compte. Un site rapide qui met 400 ms à réagir à un tap paraît cassé, pas lent.
Diagnostic : mesurer avant de toucher au code
Optimiser sans mesurer, c'est repeindre une façade sans savoir si les fondations tiennent. Voici la méthode que j'applique systématiquement avant tout changement.
Les bons outils, dans le bon ordre
- PageSpeed Insights — commencez par là, mais lisez les données terrain (CrUX) avant les données de labo. Le labo vous dit ce qui est possible, le terrain vous dit ce qui se passe vraiment.
- Lighthouse en émulation mobile — le mode par défaut de Chrome DevTools. Ne basculez jamais en desktop pour « aller plus vite ».
- WebPageTest — avec un profil de bridage type « 4G lent » ou « 3G rapide », pour voir ce que subissent vos utilisateurs en déplacement.
Un détail qui m'a coûté cher la première fois : penser que le Wi-Fi de bureau et la 4G étaient « à peu près pareils ». Ils ne le sont pas. Sur un réseau chargé, une image de 300 Ko peut mettre plus d'une seconde à arriver, alors qu'elle descend en un clin d'œil sur votre fibre.
Interpréter les résultats sans se tromper
Un score Lighthouse de 65 avec un LCP terrain à 2,1 secondes est meilleur qu'un score de 92 avec un LCP à 3,8 secondes. Le score est un indicateur, pas une fin. C'est le genre de chose qu'on apprend en se plantant une ou deux fois.
Les leviers techniques qui déplacent réellement l'aiguille
Parlons concret. Voici ce qui fonctionne, classé par rapport effort/gain.
Les images, encore et toujours
C'est là que 70 % des sites perdent le plus de temps. Réduisez, compressez, convertissez en formats modernes (WebP, AVIF), et servez la bonne taille selon l'écran.
Sur un projet de e-commerce, j'ai converti une centaine de visuels produits en WebP sans changer les dimensions. Résultat : le poids de la page d'accueil est passé de 2,4 Mo à 780 Ko, et le LCP mobile de 4,1 à 2,3 secondes. Aucun autre changement. Juste les images.
Traquer le JavaScript qui bloque
Tout script placé dans la balise <head> sans attribut defer ou async bloque le rendu. Sur mobile, c'est dévastateur.
- Auditez vos scripts tiers — trackers, widgets, chats en direct.
- Chargez ce qui n'est pas critique après le rendu initial.
- Passer à une bibliothèque plus légère donne parfois des gains de plusieurs centaines de millisecondes.
Franchement, la moitié des scripts tiers sur la plupart des sites ne servent à rien. On les ajoute parce qu'un jour quelqu'un d'un autre service les a demandés. Et on oublie qu'ils coûtent tous, à chaque visite, sur chaque téléphone.
Le CSS critique, incompris mais redoutable
L'idée : inliner dans le HTML les quelques règles nécessaires au rendu de la portion visible, et charger le reste en différé. C'est fastidieux à mettre en place à la main, mais des outils le font automatiquement au build.
Gain mesuré sur un site vitrine : environ 600 ms de moins sur le premier rendu mobile. Pas négligeable.
Cache, CDN, compression moderne
Ce sont les bases, souvent négligées. Un cache bien configuré évite de retélécharger ce qui n'a pas changé. Un CDN rapproche physiquement les fichiers de l'utilisateur. Brotli compresse mieux que gzip, à condition de l'activer côté serveur.
| Levier | Effort | Gain typique sur LCP | Quand s'en prémunir |
|---|---|---|---|
| Compression des images | Faible | Très élevé | Toujours, en premier |
| Cache + CDN | Faible | Élevé | Dès que vous avez du trafic |
| CSS critique | Moyen | Moyen | Sites avec CSS lourd |
| Réduction du JS | Élevé | Variable | Applications web riches |
| Font-display | Très faible | Faible à moyen | Dès qu'une police custom est utilisée |
Les polices web, ce faux ami
Une police personnalisée non optimisée provoque un flash de texte invisible. La propriété font-display: swap affiche une police système en attendant, ce qui évite au visiteur de fixer un écran vide. C'est une ligne à ajouter, et pourtant je vois encore des sites qui l'oublient.
Ce qui ne marche pas (ou pas comme on le croit)
Spoiler : certains réflexes d'optimisation sont du temps perdu.
Le lazy-loading de tout, y compris l'image principale. Charger paresseusement l'élément qui doit justement s'afficher le plus vite, c'est saboter son LCP. Réservez le lazy-loading à ce qui est sous la ligne de flottaison.
Le préchargement excessif. Précharger tout ce qui pourrait servir encombre le réseau et ralentit ce qui compte vraiment. À utiliser avec parcimonie.
Le score Lighthouse à 100. C'est un objectif séduisant et souvent trompeur. Sur un site réel avec des scripts tiers indispensables (paiement, analytics, support), le 100 n'a pas de sens. Visez la performance terrain, pas la note de labo.
Vérifier l'impact réel : au-delà des métriques de vitesse
Un site plus rapide, est-ce que ça convertit mieux ? Presque toujours. Mais pas toujours de façon spectaculaire.
Sur un tunnel d'inscription, j'ai ramené le LCP mobile de 3,6 à 1,9 secondes après plusieurs semaines d'ajustements. Le taux de complétion d'inscription est passé de 41 % à 53 %. C'est le genre de chiffre qui justifie largement les heures passées. Mais j'ai aussi vu des sites rapides avec des taux de rebond élevés, parce que le problème était ailleurs — offre, contenu, ergonomie.
La vitesse n'est jamais la seule variable. Elle est juste celle qu'on contrôle le plus facilement.
Par où commencer demain matin
Si vous ne savez pas dans quel ordre attaquer, voici la séquence que j'applique :
- Mesurez en émulation mobile, notez le LCP, l'INP et le CLS actuels.
- Attaquez les images — c'est le gain le plus rapide pour le moins d'effort.
- Identifiez les scripts tiers et supprimez ou différez tout ce qui n'est pas critique.
- Vérifiez le cache et activez la compression Brotli côté serveur.
- Remesurez une semaine plus tard, puis itérez.
Ce n'est pas glamour. Ça ne fait pas de jolie capture d'écran. Mais c'est ce qui fonctionne.
Ce qui m'a le plus surpris, au fil des projets, c'est à quel point la vitesse mobile est une question de discipline plus que de technique. Les gros gains viennent rarement d'une astuce sophistiquée. Ils viennent de nettoyer ce qu'on a laissé s'accumuler sans jamais y regarder. Et si vous ne devez retenir qu'une chose de cet article, c'est peut-être celle-ci : votre site n'est rapide que sur le téléphone de quelqu'un qui vient de le tester. Sur celui de vos visiteurs, c'est une autre histoire — et c'est la seule qui compte.
