Site lent sur mobile : les corrections à faire avant d’envisager une refonte
Seuils Core Web Vitals 2026, causes courantes de lenteur sur mobile et ordre des corrections, avec le gain mesurable de chaque action.
En bref. Un site est « lent » sur mobile quand son LCP dépasse 2,5 secondes chez 75 % des visiteurs réels. Dans 80 % des cas que l’on rencontre sur des sites vitrines et des boutiques WordPress ou Shopify, trois causes suffisent à expliquer le problème : des images trop lourdes, des scripts tiers chargés au mauvais moment, et un hébergement mutualisé qui répond en plus de 600 ms. On corrige dans cet ordre, on regagne en général 1 à 2 secondes, et refaire le site n’est presque jamais nécessaire.
Ce que Google mesure réellement
Depuis mars 2024, les Core Web Vitals reposent sur trois indicateurs, et un seul a changé : l’INP a remplacé le FID. En 2026, les seuils n’ont pas bougé. Voici les valeurs à connaître, toutes mesurées au 75e percentile des visites réelles sur 28 jours glissants.
| Indicateur | Ce qu’il mesure | Bon | À améliorer | Mauvais |
|---|---|---|---|---|
| LCP | Temps d’affichage du plus gros élément visible | ≤ 2,5 s | 2,5 – 4 s | > 4 s |
| INP | Réactivité aux clics et aux taps | ≤ 200 ms | 200 – 500 ms | > 500 ms |
| CLS | Stabilité visuelle pendant le chargement | ≤ 0,1 | 0,1 – 0,25 | > 0,25 |
Le point que la plupart des gens ratent : le score PageSpeed Insights sur 100 que vous voyez en haut de la page n’est pas ce que Google utilise pour le classement. Ce score vient de Lighthouse, un test simulé lancé depuis un serveur, sur un appareil théorique. Ce qui compte pour le référencement, ce sont les données du rapport CrUX, en bas de la même page, sous l’intitulé « Découvrez l’expérience de vos utilisateurs réels ». Un site peut afficher 62/100 en simulation et passer les trois seuils en données terrain. L’inverse existe aussi.
Si votre site reçoit moins de 1 000 visites par mois, il n’apparaîtra probablement pas dans CrUX : Google n’a pas assez d’échantillon. Dans ce cas, la vitesse ne joue pratiquement aucun rôle dans votre positionnement, et vos efforts sont mieux placés sur le contenu et les liens. Optimisez pour vos visiteurs, pas pour un score.
Les cinq causes les plus fréquentes, par ordre de dégâts
Sur un audit de site vitrine classique, les responsables reviennent presque toujours dans le même ordre.
- Les images non compressées et servies en pleine taille. Une photo de bandeau exportée en JPEG à 2 400 px pèse souvent 900 ko. Sur un écran de smartphone, 800 px suffisent, et en WebP le même visuel tombe à 70 ko. C’est le facteur numéro un du LCP, parce que l’élément le plus grand d’une page d’accueil, c’est presque toujours l’image de la bannière.
- Les scripts tiers chargés dès la première ligne. Google Tag Manager, un chat en direct, un widget d’avis, un pixel publicitaire, une carte interactive : chacun ajoute entre 50 et 300 ko de JavaScript et bloque le thread principal. C’est la cause principale d’un mauvais INP.
- Un temps de réponse serveur élevé (TTFB). Sur un mutualisé à 4 € par mois avec vingt sites par machine, le TTFB grimpe fréquemment à 800 ms – 1,2 s. Ce délai s’ajoute à tout le reste, avant même que le navigateur ait commencé à travailler.
- Les polices web chargées sans font-display. Le texte reste invisible pendant 1 à 3 secondes, puis apparaît d’un coup. Cela dégrade le LCP quand le plus gros élément est un titre, et le CLS quand la police de secours n’a pas les mêmes proportions.
- Les carrousels et les constructeurs de pages surchargés. Un slider avec cinq visuels charge cinq images alors qu’une seule est visible. Un thème polyvalent chargé de fonctionnalités inutilisées ajoute 400 ko de CSS dont vous utilisez 8 %.
L’ordre des corrections, du plus rentable au moins rentable
L’erreur habituelle consiste à installer un plugin de cache en premier et à s’arrêter là. Le cache masque le symptôme sur la page d’accueil et ne change rien aux images ni aux scripts. Voici un ordre qui donne des résultats mesurables, avec le gain typique observé sur un site vitrine de dix pages.
| # | Action | Gain typique sur le LCP | Temps |
|---|---|---|---|
| 1 | Convertir les images en WebP et les redimensionner | 0,8 – 1,5 s | 1 à 2 h |
| 2 | Précharger l’image de bannière, retirer le lazy loading dessus | 0,3 – 0,6 s | 15 min |
| 3 | Différer ou supprimer les scripts tiers non essentiels | 0,2 s sur le LCP, 100 – 300 ms sur l’INP | 1 h |
| 4 | Ajouter font-display: swap et héberger les polices en local | 0,2 – 0,8 s | 30 min |
| 5 | Réserver la hauteur des images, bannières et encarts publicitaires | CLS proche de 0 | 30 min |
| 6 | Passer sur un hébergement à 12 – 25 € par mois | 0,4 – 0,8 s | 2 à 4 h |
Les quatre premières lignes sont accessibles à quelqu’un qui n’écrit pas de code, avec un plugin de conversion d’images et une extension de gestion des scripts. Comptez une demi-journée pour les cinq premières et, dans la majorité des cas, un LCP qui passe de 4,2 s à moins de 2,5 s. La sixième ligne, le changement d’hébergement, ne se justifie que si votre TTFB dépasse 600 ms de façon constante : vérifiez-le avant de payer.
Le cas particulier de l’INP
L’INP est l’indicateur qui piège le plus de sites en 2026, parce qu’il ne se mesure pas au chargement mais pendant toute la visite. Chaque clic sur un menu déroulant, chaque ouverture d’accordéon, chaque filtre de catalogue est mesuré, et c’est la pire interaction qui compte.
Trois réflexes règlent la plupart des cas :
- Repérer les scripts qui bloquent le thread principal plus de 50 ms dans l’onglet « Performances » des outils de développement de Chrome, en simulant un processeur ralenti 4×.
- Charger les widgets non critiques après la première interaction de l’utilisateur, pas au chargement. Un chat en direct qui s’initialise seulement quand on clique sur son icône fait gagner 150 ms d’INP à lui seul.
- Limiter le nombre d’éléments d’un menu mobile. Un méga-menu de 120 liens qui s’ouvre en JavaScript coûte cher à l’affichage sur un téléphone de milieu de gamme.
Ce qui ne sert à rien, ou presque
Trois pistes reviennent souvent dans les conseils et méritent d’être relativisées.
Le CDN pour un site local. Un réseau de diffusion de contenu réduit la latence géographique. Si vos clients sont tous en France et votre serveur à Roubaix ou à Gravelines, le gain se compte en quelques dizaines de millisecondes. Utile pour une audience internationale, marginal pour un artisan à Nantes.
La minification du CSS et du JavaScript. Elle fait gagner 20 à 60 ko sur des fichiers déjà compressés en gzip ou en Brotli par le serveur. C’est une case à cocher, pas une stratégie.
Le passage à l’AMP. Le format n’est plus une condition d’affichage dans les résultats mobiles depuis 2021, et maintenir une seconde version de son site pour un gain de vitesse que l’on peut obtenir autrement n’a plus de sens.
Quand refaire le site devient la bonne réponse
Il existe des situations où l’optimisation ne suffit pas. Si votre site cumule un thème abandonné depuis plus de trois ans, huit extensions qui font le même travail, un constructeur de pages qui génère 3 000 lignes de CSS par page et une base de données de 400 Mo pour douze pages de contenu, chaque correction se heurte à la suivante. Le seuil pratique : si après une demi-journée d’optimisation votre LCP est toujours au-dessus de 4 secondes, la dette technique est le vrai sujet.
Un site vitrine refait proprement, avec un thème léger et sans constructeur, coûte entre 1 500 et 4 000 € chez un indépendant en France, contre 300 à 600 € pour une demi-journée d’optimisation. Faites l’optimisation d’abord : elle vous dira si la refonte est nécessaire, et vous aurez de toute façon besoin des images allégées après.
Comment mesurer sans se tromper
Trois outils suffisent, et ils ne servent pas à la même chose.
- PageSpeed Insights, section « données terrain » : la vérité sur ce que vivent vos visiteurs, avec 28 jours de décalage.
- La Search Console, rapport « Signaux web essentiels » : la vue par groupe d’URL, indispensable pour savoir si le problème touche vos fiches produits ou seulement l’accueil.
- WebPageTest en configuration « Moto G4, 4G lente, Paris » : le diagnostic détaillé, avec la cascade de chargement qui montre exactement quel fichier bloque quoi.
Après chaque correction, attendez au moins 24 heures avant de retester en simulation, et 28 jours avant de juger l’effet sur les données terrain. Les gains réels apparaissent plus tard que la satisfaction.
Questions fréquentes
Un site rapide améliore-t-il vraiment le positionnement Google ?
Marginalement. La vitesse est un facteur de départage entre pages de qualité comparable, pas un levier de classement puissant. En revanche, l’effet sur la conversion est direct : chaque seconde gagnée sur le temps de chargement mobile se traduit en général par 5 à 10 % de conversions supplémentaires. C’est là que se trouve le vrai retour sur investissement.
Faut-il viser un score de 100 sur PageSpeed Insights ?
Non. Le score simulé au-delà de 85 se paie en compromis fonctionnels : suppression de la vidéo d’accueil, de la carte, du chat, des avis clients. Visez les trois seuils en données terrain (2,5 s, 200 ms, 0,1) et gardez ce qui fait vendre.
Mon hébergeur me dit que le problème vient de mon thème, est-ce crédible ?
Souvent, oui, mais c’est vérifiable en deux minutes. Regardez le TTFB dans PageSpeed Insights ou WebPageTest : au-dessus de 600 ms de façon répétée, la responsabilité est du côté du serveur ou du code exécuté à chaque requête. En dessous de 400 ms, votre hébergeur a raison et le poids de la page est en cause.
Combien de temps prend l’optimisation d’un site vitrine de dix pages ?
Entre trois et cinq heures pour les corrections décrites ici, en comptant la mesure avant et après. Une boutique de 300 références demande plutôt une à deux journées, principalement à cause du traitement en masse des images produits et des scripts de suivi accumulés au fil des campagnes.