Il y a trois ans, j'ai lancé un blog de recettes de cuisine. Le design était propre, les photos sublimes, et sur mon MacBook Pro en fibre, le site chargeait en 800 ms. Puis ma sœur m'a envoyé un message : « Ton site rame à mort sur mon téléphone. » J'ai testé. Sur un Android milieu de gamme en 4G, il chargeait en 11 secondes. Onze. Je recevais 70 % de mon trafic mobile, et je leur servais une page qui les faisait fuir avant même de voir une recette.
C'est là que j'ai compris une chose que les articles SEO répètent sans jamais l'expliquer vraiment : optimiser la vitesse de chargement mobile, ce n'est pas optimiser un site web. C'est optimiser un site web pour un appareil lent, sur un réseau instable, avec un processeur bridé. Ce n'est pas la même discipline.
Points clés à retenir
- HTTP Archive mesure environ 6,6 s de chargement médian sur desktop contre 19,7 s sur mobile. L'écart n'est pas un détail : il faut cibler les causes mobiles.
- Les seuils Core Web Vitals à viser sont LCP ≤ 2,5 s, INP ≤ 200 ms et CLS ≤ 0,1.
- Le mobile-first indexing de Google signifie que c'est votre version mobile qui est évaluée, pas la desktop.
- L'INP a remplacé le FID en mars 2024. Beaucoup de guides n'ont pas été mis à jour.
- Les gains les plus rentables sur mobile concernent d'abord les images, puis le JavaScript tiers.
Pourquoi votre site est toujours plus lent sur mobile (et pourquoi ce n'est pas qu'une question de réseau)
La réponse paresseuse, c'est « la connexion est moins bonne ». C'est vrai, mais c'est loin d'être toute l'histoire. Quand j'ai commencé à creuser, j'ai découvert trois freins bien plus vicieux.
Le CPU bridé, le vrai coupable
Un iPhone 15 et un M3 Max ne traitent pas le JavaScript à la même vitesse. Un téléphone d'entrée de gamme exécute les scripts 4 à 6 fois plus lentement qu'un ordinateur portable de milieu de gamme. Sur mon ancien Pixel 4a, l'hydratation React de ma page de recette prenait 3,4 secondes à elle seule. Sur desktop : 0,6 s.
Ça veut dire quoi concrètement ? Que même avec une connexion parfaite, un site trop dépendant du JS sera lent sur mobile. Voilà pourquoi je vérifie toujours mes performances en throttlant le CPU à 4x dans Chrome DevTools, pas seulement en limitant le réseau.
Le réseau opérateur n'est pas votre Wi-Fi
Latence, perte de paquets, handover entre antennes quand on marche dans la rue. Une requête qui met 30 ms sur fibre peut mettre 180 ms en 4G. Multipliez par 40 requêtes et vous avez déjà perdu 7 secondes avant même de charger une seule ressource lourde.
Le CDN aide énormément ici, mais ce n'est pas magique. J'ai mesuré un gain réel de 1,8 s sur mon blog après passage derrière Cloudflare, principalement parce que mes visiteurs étaient à 60 % hors de France.
Le piège du poids
Un site mobile peut être « léger » en poids et pourtant très lent. Le problème n'est pas le nombre de Mo. C'est le nombre de requêtes, l'ordre dans lequel elles arrivent, et ce que le navigateur doit faire avec.
Comment comprendre les Core Web Vitals côté mobile (et quels seuils viser)
Google utilise trois métriques pour évaluer l'expérience mobile. Elles ont l'air abstraites jusqu'à ce qu'on les mesure sur son propre site.
| Métrique | Ce qu'elle mesure | Bon seuil | Ce qui la fait exploser sur mobile |
|---|---|---|---|
| LCP | Temps d'affichage du plus grand élément | ≤ 2,5 s | Image hero non optimisée, serveur lent, CSS bloquant |
| INP | Réactivité aux interactions | ≤ 200 ms | Scripts tiers, JS lourd sur CPU bridé |
| CLS | Stabilité visuelle | ≤ 0,1 | Polices custom, pubs, images sans dimensions |
INP a remplacé FID : ne vous trompez pas
Depuis mars 2024, l'INP (Interaction to Next Paint) a supprimé le FID des Core Web Vitals. Avouons-le, FID était trop gentil. Il ne mesurait que le premier délai d'entrée, pas la réactivité réelle. L'INP mesure toutes les interactions et retient la plus mauvaise. Résultat : plein de sites qui passaient les CWV échouent maintenant.
Si vous lisez encore des articles qui vous disent « optimisez votre FID », ils datent. Passez votre chemin.
Le seul moyen fiable de mesurer
- PageSpeed Insights avec analyse terrain (CrUX, données utilisateurs réelles) — le plus proche de la vérité.
- Chrome DevTools en mode réseau 4G + CPU throttling 4x.
- Un vrai test sur un Android d'entrée de gamme. J'ai acheté un Nokia G21 à 130 € uniquement pour ça. Il m'a plus appris que dix audits Lighthouse.
Les images : 60 % du problème mobile, réglé en une soirée
C'est le levier le plus rapide. Sur mon blog, les images représentaient 78 % du poids total de la page. Après conversion en WebP et redimensionnement, j'ai perdu 3,1 Mo par page.
WebP, AVIF : lequel choisir
WebP est supporté partout depuis des années. AVIF compresse 20 à 30 % mieux mais reste plus coûteux à décoder sur mobile d'entrée de gamme. Mon choix : WebP par défaut, AVIF pour les grosses images hero.
srcset : servir la bonne taille, pas la plus grande
Le srcset avec sizes permet au navigateur de choisir la bonne résolution. Avant, j'envoyais la même image 2400 px à un mobile de 390 px de large. Totalement absurde. Depuis que je génère 5 tailles différentes, mon LCP a chuté de 2,9 s à 1,4 s.
Le lazy loading, avec modération
Le lazy loading est utile pour les images sous la ligne de flottaison. Mais attention : le mettre sur l'image hero en tête de page est une erreur fréquente. C'est exactement cette image qui définit votre LCP. Laissez-la en loading="eager" et ajoutez un fetchpriority="high".
Je l'ai fait l'inverse pendant des mois. Je pensais bien faire. Je tirais une balle dans mon propre pied.
JavaScript : le poison silencieux du mobile
En moyenne, un site e-commerce charge entre 15 et 25 scripts tiers. Analytics, tracker pub, chatbot, heatmap, A/B testing. Chaque script doit être téléchargé, parsé, exécuté par un CPU déjà lent.
Auditer ses scripts tiers
Ouvrez l'onglet Couverture de DevTools. Vous verrez le pourcentage de code réellement utilisé par chaque script. Sur mon blog, j'avais un tracker Instagram qui exécutait 0,3 % de son code. Je l'ai viré. 180 Ko en moins, 0,9 s de gain sur INP.
defer, async, et l'ordre des choses
Le HTML doit être parsé en premier. Vos scripts non critiques vont en async ou defer. Votre CSS critique s'inline, le reste se charge en différé. Ce n'est pas de la théorie, c'est ce que fait n'importe quelle page qui charge en moins de 2 secondes.
Les polices web, souvent oubliées
Une police custom non optimisée peut générer 300 ms de FOIT (Flash of Invisible Text) et un CLS de 0,15 à elle seule. Deux options : font-display: swap ou self-hosting. J'utilise les deux. Depuis, plus aucun décalage visible au chargement.
Cache, CDN, serveur : ce qui change vraiment sur mobile
Sur desktop fibre, un serveur lent passe inaperçu. Sur mobile, il est décisif. Chaque aller-retour serveur coûte 150 à 300 ms en 4G.
Ce qui a marché pour moi :
- Passer de PHP à un hébergement statique (Hugo + Netlify). Le TTFB est passé de 780 ms à 90 ms.
- Activer le cache navigateur avec des durées longues sur les assets statiques (1 an), versionnés par hash.
- Brotli plutôt que gzip pour le HTML/CSS/JS. Gain moyen constaté : 18 % de poids en moins.
- Un CDN avec POP en France, Allemagne et US. Mes visiteurs américains ont gagné 2,4 s de LCP, ce que je n'aurais jamais pu obtenir avec un serveur unique à Paris.
Une chose que je ne recommande pas : les thèmes WordPress « ultra optimisés » avec 8 plugins de cache qui se battent entre eux. J'ai testé. Résultat catastrophique. Une page qui passe de 2,1 s à 4,7 s parce que trois plugins réécrivent le même HTML.
Les erreurs que j'ai faites (pour que vous ne les refassiez pas)
Je ne vais pas vous vendre du rêve. Voici ce qui m'a coûté du temps et de l'argent.
D'abord, j'ai cru qu'optimiser l'image logo en WebP allait régler le problème. Non. Le logo pesait 12 Ko. Mes recettes pesaient 4 Mo chacune. Priorité inversée.
Ensuite, j'ai ajouté un service worker pour faire du cache offline. Trois semaines plus tard, je servais des versions obsolètes de mes articles à mes visiteurs réguliers. J'ai dû désinscrire manuellement les service workers à distance. Plus jamais.
Enfin, je me suis focalisé pendant un mois sur le score PageSpeed Insights en espérant atteindre 100. Ce score n'est pas ce que Google utilise pour le ranking. Le score labo de Lighthouse est un indicateur, pas une vérité. Ce qui compte, ce sont les données CrUX : les vraies mesures de vos vrais utilisateurs.
Dans quel ordre optimiser (si vous ne devez retenir qu'une chose)
Si je devais recommencer demain sur un site lent, voici mon ordre d'action :
- Mesurer avec PageSpeed Insights en mode terrain, pas labo.
- Compresser et redimensionner toutes les images. Objectif : moins de 150 Ko par image visible.
- Différer ou supprimer les scripts tiers non critiques.
- Mettre en place un CDN avec compression Brotli.
- Corriger le CLS (dimensions d'images, polices, pubs).
- Seulement après : jouer sur le cache avancé, le service worker, l'edge rendering.
Cette séquence m'a fait passer un site de 7,8 s à 1,9 s de LCP mobile en six semaines. Pas de magie, pas de plugin miracle. Juste de l'ordre.
Ce qui reste quand tous les plugins sont désactivés
La vitesse mobile n'est pas un réglage qu'on active une fois. C'est une discipline de fond. Chaque nouvelle image, chaque nouveau script, chaque nouvelle fonctionnalité doit passer le test du téléphone d'entrée de gamme. Celui que personne dans votre équipe n'utilise au quotidien. Celui qui représente pourtant la majorité de votre audience.
Le jour où vous accepterez que votre site n'est pas celui que vous voyez sur votre écran, mais celui qui apparaît sur l'écran de quelqu'un qui marche dans la rue, entre deux stations de métro, avec 12 % de batterie et une 4G capricieuse — ce jour-là, vous ferez du vrai SEO mobile.
Et franchement, c'est aussi à ce moment-là que vos conversions décollent. Pas parce que Google vous aime. Parce que vos visiteurs arrivent enfin à voir ce que vous leur proposez.
