J'ai passé trois semaines à traquer un problème de lenteur sur mon propre blog. Résultat : 4,1 secondes de chargement sur mobile, un taux de rebond à 71 %, et moi qui m'acharnais sur des détails de CSS alors que le coupable était un script d'analytics oublié qui bloquait tout. Voilà pourquoi je me méfie des articles qui répètent en boucle "compressez vos images".
Optimiser la vitesse mobile de son site, ce n'est pas une liste de recettes. C'est un arbitrage permanent entre ce que le visiteur veut voir tout de suite et ce que votre code a décidé de charger avant. Et la plupart des sites échouent sur ce dernier point.
Points clés à retenir
- Les Core Web Vitals ne sont pas des options : visez LCP sous 2,5 s, INP sous 200 ms, CLS sous 0,1.
- Le matériel mobile (CPU bridé, connexion instable) est souvent le vrai plafond de verre.
- Priorisez le JavaScript bloquant et les polices avant de toucher aux images.
- Un seul outil ne suffit pas : Lighthouse pour l'audit, Chrome UX Report pour le terrain, WebPageTest pour la latence réseau.
- Un budget de performance chiffré (en kilo-octets et en millisecondes) vaut plus que dix rapports d'audit.
- Sur un site vitrine, gagner 1,5 s peut suffire ; sur un e-commerce, chaque seconde compte deux fois.
Pourquoi la vitesse mobile est devenue le vrai juge de paix
Il y a une statistique que je ressors chaque fois qu'on me dit "oh, on est un peu lents mais ça va". Le rapport de HTTP Archive sur l'état du web : environ 6,6 secondes de chargement médian sur desktop, contre 19,7 secondes sur mobile. Le mobile n'est pas "un peu plus lent". Il est trois fois pire.
Et ce n'est pas parce que les développeurs sont mauvais. C'est mécanique.
Le matériel et le réseau vous plafonnent avant votre code
Un smartphone d'entrée de gamme a une puissance CPU qui n'a rien à voir avec votre station de travail. Quand je teste depuis mon MacBook Pro en fibre, tout va bien. Quand je teste depuis un Android à 150 € en 4G dans le métro, ma page met le temps qu'elle mettra pour 40 % de mes visiteurs.
Google documente ce point depuis des années : chaque requête réseau ajoute de la latence opérateur, souvent 40 à 100 ms rien qu'en aller-retour. Multipliez par 15 ressources critiques. Vous avez déjà perdu deux secondes avant d'avoir affiché un pixel.
L'approche mobile-first de Google existe depuis 2019, et l'indexation se fait donc sur la version mobile de votre page. Si elle est lente, votre version desktop rapide ne sert à rien.
Ce que ça vous coûte vraiment
Je n'aime pas citer des "études montrent que" sans nom. Alors je vous donne le chiffre de Google, issu de son propre service Test My Site : quand le délai de chargement passe de 1 à 3 secondes sur mobile, le taux de rebond augmente d'environ 32 %. De 1 à 5 secondes, on grimpe à 90 %.
Sur mon blog, je suis passé de 4,1 s à 1,9 s en une semaine. Taux de rebond : 71 % → 54 %. Aucune flamboyance, juste des visiteurs qui restent. Franchement, je ne m'y attendais pas à ce point-là.
Les seuils concrets à atteindre (ou vous allez vous arrêter)
Voilà ce qui manque cruellement dans la plupart des guides : des chiffres à viser. Sans cible, une optimisation n'a pas de fin. Voici les miennes, tirées des Core Web Vitals de Google.
| Métrique | Ce qu'elle mesure | Cible | Mon record actuel |
|---|---|---|---|
| LCP (Largest Contentful Paint) | Délai du plus grand élément affiché | < 2,5 s | 1,8 s |
| INP (Interaction to Next Paint) | Réactivité après un clic ou un tap | < 200 ms | 134 ms |
| CLS (Cumulative Layout Shift) | Stabilité visuelle (éléments qui sautent) | < 0,1 | 0,04 |
| TTFB (Time to First Byte) | Réponse serveur | < 800 ms | 320 ms |
| Poids total de page | Budget de performance | < 1,5 Mo | 1,1 Mo |
Mon budget de performance, je l'ai fixé à 1,5 Mo et 50 requêtes maximum. C'est arbitraire. Mais un budget arbitraire tenu vaut mieux qu'un objectif vague jamais respecté.
Le budget performance, c'est quoi exactement ?
C'est une limite que vous vous imposez : poids maximal, nombre de scripts, taille de police, etc. Dès qu'une nouvelle fonctionnalité dépasse le budget, elle ne passe pas en production. J'ai découvert cette pratique chez des équipes e-commerce, et je l'ai adoptée pour mon petit site. C'est brutal, mais ça marche.
Les optimisations qui comptent vraiment (dans quel ordre)
Ici, je vais être direct : si vous commencez par compresser vos images, vous perdez votre temps. J'ai fait cette erreur pendant des mois.
Étape 1 : supprimez le JavaScript bloquant
Un script dans le <head> sans attribut async ou defer bloque le rendu. Le navigateur attend de l'avoir téléchargé et exécuté avant d'afficher quoi que ce soit. Sur mobile, c'est catastrophique.
- Passez tout en defer sauf ce qui doit absolument s'exécuter avant l'affichage.
- Chargement paresseux (lazy loading) sur tout ce qui n'est pas dans le viewport initial : images, iframes, vidéos.
- Retirez les scripts tiers que vous n'utilisez plus. Vraiment inutiles, pas "au cas où".
J'ai gagné 1,2 seconde juste en retirant un widget de chat que personne n'utilisait depuis huit mois. Avouons-le, je n'avais même pas souvenir qu'il était là.
Étape 2 : inlinez le critical CSS et differez le reste
Le CSS bloque aussi le rendu. La technique consiste à inclure dans le <head> uniquement le CSS nécessaire à la première vue, puis charger le reste en différé. Ça peut sembler technique, mais des outils comme Critical ou l'option intégrée de frameworks modernes le gèrent automatiquement.
Gain mesuré sur mon site : 0,6 s. Pas spectaculaire, mais cumulé avec l'étape précédente, on arrive à 1,8 s de gagné.
Étape 3 : optimisez les polices et les images
Une police web pèse facilement 150 Ko par graisse. Si vous en chargez quatre, vous êtes mort. Utilisez deux graisses maximum, au format WOFF2, avec font-display: swap.
Pour les images, convertissez en WebP ou AVIF, servez-les en srcset adapté au viewport, et n'oubliez jamais les dimensions explicites (width et height) pour éviter le CLS. Ce dernier point, je l'ai appris à mes dépens : mes images chargeaient sans dimensions et faisaient sauter tout mon contenu. Le CLS était à 0,34. Honteux.
Et le CDN ? Si votre audience est géographiquement dispersée, un CDN réduit le TTFB de façon parfois spectaculaire. Sur mon site à audience majoritairement française, le gain a été modeste (80 ms). Sur un projet plus international que j'ai suivi, on est passé de 900 ms à 220 ms.
Quels outils utiliser pour mesurer, et comment les lire
Un seul outil vous mentira. Tous vous mentiront un peu, mais différemment.
- PageSpeed Insights : le point d'entrée. Donne à la fois les données de terrain (Chrome UX Report) et un audit Lighthouse.
- Lighthouse (intégré à Chrome DevTools) : utile pour tester en local, mais ne reflète pas les conditions réelles de vos visiteurs.
- WebPageTest : le plus précis pour simuler une connexion 4G dégradée sur un appareil Android réel. C'est là que j'ai compris mon vrai problème de latence.
- Chrome UX Report : les vraies données de vos utilisateurs Chrome, agrégées. C'est ce que Google utilise pour ses Core Web Vitals.
La règle que je me suis donnée : Lighthouse pour diagnostiquer, Chrome UX Report pour juger. Le premier vous dit ce qui pourrait être amélioré. Le second vous dit si ça compte.
Faut-il passer par un service d'audit payé ?
Franchement, non, pas au début. Les quatre outils ci-dessus couvrent 90 % des cas. Les services payants deviennent utiles quand votre site a plusieurs milliers de pages et que vous devez prioriser à grande échelle. Avant, vous payez pour du diagnostic que vous auriez pu faire vous-même en une soirée.
Quel arbitrage pour quel type de site
Je ne vais pas vous servir la liste universelle qui ne convient à personne. Chaque type de site a ses priorités.
- Site vitrine : le HTML/CSS bien minifié + un serveur correct suffisent souvent. Ne vous aventurez pas dans le CDN ou l'edge computing.
- Blog : images et polices sont vos deux plus gros postes. Optimisez-les en premier.
- E-commerce : tout compte. Chaque seconde de plus au chargement a un coût direct sur le panier moyen. C'est là que le budget de performance doit être le plus strict.
- Application web : l'accent doit être mis sur l'INP, pas seulement sur le LCP. Un utilisateur qui clique et attend deux secondes s'en va.
La question honnête à se poser n'est pas "quel est le meilleur score Lighthouse possible". C'est "quel est le score minimum pour que mon visiteur fasse ce que je veux qu'il fasse".
Ce que j'ai fini par comprendre après des années
La vitesse mobile n'est pas un projet ponctuel. C'est une discipline. Chaque nouvelle fonctionnalité, chaque nouvelle image, chaque script tiers que vous ajoutez est une dette de performance qui s'accumule silencieusement.
Le vrai piège, c'est de croire qu'on "optimise une fois". J'ai optimisé mon site trois fois. La quatrième, je me suis rendu compte que ce n'était pas le site qui était en cause, mais mes habitudes. J'ajoutais plus vite que je ne retirais.
Alors la prochaine fois que vous ouvrez PageSpeed Insights et que vous voyez du rouge, avant de chercher quel plugin installer, posez-vous une question plus simple : de quoi mon visiteur a-t-il vraiment besoin dans les deux premières secondes ? Si vous ne savez pas répondre, aucune optimisation ne vous sauvera.
