Ton site est lent sur mobile : pourquoi et comment y remédier

À qui s’adresse ce guide

Tu as un site, et sur mobile il paraît lent : la page reste vide un moment, le texte saute pendant que d’autres éléments se chargent, ou un menu réagit en retard quand on le touche. Peut-être que tout semble correct sur ton ordinateur portable, et qu’un visiteur ou un collègue te dit le contraire. Ou un test de vitesse est revenu au rouge et tu ne sais pas par où commencer.

Ce guide vaut pour WordPress, les créateurs de sites, et les sites codés à la main ou statiques. Les premières étapes ne demandent aucune connaissance technique : mesurer et redimensionner les images. Les étapes suivantes touchent aux extensions, aux scripts, aux polices et à l’hébergement : il te faudra peut-être la personne qui a construit ou qui s’occupe de ton site.

Ce que veut dire « lent », et pourquoi le mobile le révèle en premier

« Lent » n’est pas une seule mesure. Google décrit l’expérience avec trois indicateurs, les Core Web Vitals, et fixe un seuil pour chacun. Une page est « bonne » quand elle atteint les trois pour au moins 75 % des chargements de page, mesurés séparément pour les mobiles et pour les ordinateurs (web.dev) :

• LCP (Largest Contentful Paint) : le temps avant que le plus grand élément de l’écran, souvent l’image principale ou le titre, soit visible. Bon : jusqu’à 2,5 secondes.
• INP (Interaction to Next Paint) : le temps que met la page à réagir quand on touche, clique ou écrit. Bon : jusqu’à 200 millisecondes.
• CLS (Cumulative Layout Shift) : à quel point le contenu saute pendant le chargement. Bon : jusqu’à 0,1.

Les problèmes se voient d’abord sur mobile, parce qu’il a moins de puissance de calcul qu’un ordinateur portable et souvent une connexion plus faible : une page lourde ou un tas de scripts y coûte plus de temps. Et attendre fait perdre des visiteurs : dans une étude Google/SOASTA de 2017, la probabilité qu’un visiteur mobile quitte la page était 32 % plus élevée quand une page mettait 3 secondes à charger au lieu d’1 seconde.

Comment savoir quelle cause s’applique

Fais d’abord l’étape 1, puis compare avec ce que tu vois :

• Le LCP dépasse 2,5 secondes. L’image principale ou le titre arrive tard. Causes probables : une image principale trop grande ou mal préparée, un serveur lent, ou un texte qui attend une police. Passe aux étapes 2, 3, 4, 8 et 9.
• L’INP dépasse 200 millisecondes. Les touches et les menus semblent lourds : le téléphone est occupé à exécuter des scripts. Causes probables : trop d’extensions et de scripts, ou des widgets externes lourds. Passe aux étapes 6 et 7. Le guide de Google sur l’INP explique le côté technique pour un développeur.
• Le CLS dépasse 0,1. Des éléments bougent pendant le chargement et on touche le mauvais bouton. Causes probables : des images et des contenus intégrés sans place réservée, des bandeaux ou des publicités qui apparaissent tard, des polices qui changent après coup. Passe aux étapes 5 et 8.
• Rapide sur ton ordinateur, lent sur mobile. C’est normal : un ordinateur sur un Wi-Fi rapide cache le problème. Teste sur un téléphone en données mobiles (étape 1) et commence par les images (étape 2) et les scripts (étape 6).
• Seules certaines pages sont lentes. Regarde ce que ces pages ont de plus que les autres : un diaporama, une vidéo, une carte, une galerie ou un widget. Passe aux étapes 4, 5 et 7.
• Les données de labo et de terrain se contredisent. Les données de labo sont un seul test simulé, les données de terrain montrent ce que de vrais visiteurs ont vécu. Fie-toi aux données de terrain pour le verdict et utilise le test de labo pour chercher les causes (pourquoi elles diffèrent).
• Aucune donnée de terrain n’est affichée. La page n’a pas encore assez de visites. Utilise le test de labo et un vrai téléphone, et vérifie à nouveau dans quelques semaines.

Les étapes pour corriger

1. Mesurer sur un vrai téléphone et noter les valeurs. Ouvre PageSpeed Insights, saisis l’adresse de ta page d’accueil et d’une ou deux autres pages importantes, et lis l’onglet Mobile. La partie du haut montre des données de terrain : l’expérience de vrais visiteurs Chrome sur les 28 derniers jours. La partie du bas est un test de labo avec Lighthouse, une exécution simulée qui liste des problèmes concrets (la différence entre les deux). Note le LCP, l’INP et le CLS de chaque page. Si ton site est validé dans Google Search Console, son rapport sur les Core Web Vitals montre les mêmes données regroupées par pages similaires, ce qui te dit quels types de pages posent problème. Ouvre ensuite le site toi-même sur un téléphone, Wi-Fi coupé, et vois comment il se comporte. Les données de terrain couvrent 28 jours et bougent lentement après une correction. Utilise le test de labo pour vérifier un changement tout de suite.

2. Redimensionner et compresser les images. Les photos trop grandes sont la cause la plus fréquente. Une photo sortie directement d’un appareil ou d’une banque d’images peut faire plusieurs milliers de pixels de large, alors qu’un téléphone l’affiche sur quelques centaines. Donne à chaque image à peu près la taille de son plus grand affichage, puis compresse-la. Propose plusieurs tailles avec srcset pour qu’un téléphone télécharge la petite (images adaptatives). Dans WordPress, insère les images à la taille affichée plutôt qu’en taille originale. Une extension d’images ou ton hébergeur peut souvent les redimensionner et les convertir pour toi.

3. Utiliser un format d’image moderne. WebP et AVIF peuvent compresser mieux que JPEG et PNG : la même image se charge plus vite. Convertis tes images et garde un JPEG ou un PNG de secours pour les navigateurs qui ne gèrent pas le nouveau format, si ton outil ne le fait pas à ta place (choisir un format). N’enregistre pas encore et encore une image déjà compressée, car la qualité baisse à chaque fois. Convertis à partir du fichier d’origine.

4. Charger l’image principale en premier, le reste en différé. L’image principale en haut de la page (souvent l’élément LCP) doit se charger le plus tôt possible. Mets-la dans la page comme une balise <img> normale, pas en arrière-plan CSS ni dans un diaporama chargé par script, et ajoute fetchpriority="high" pour que le navigateur la récupère en premier (optimiser le LCP). N’y mets jamais loading="lazy". Pour les images plus bas, c’est l’inverse : avec loading="lazy", elles ne se chargent que lorsque le visiteur approche en faisant défiler (chargement différé). WordPress fait les deux automatiquement pour l’image principale probable depuis la version 6.3 (annonce de WordPress), mais les thèmes, les diaporamas et les constructeurs de pages peuvent le désactiver : regarde le code source de la page.

5. Réserver la place pour que rien ne saute. Donne à chaque image et vidéo les attributs width et height, ou une propriété CSS aspect-ratio, pour que le navigateur laisse le bon espace avant l’arrivée du fichier (optimiser le CLS). Fais de même pour les cartes, vidéos et widgets intégrés : fixe leur taille et charge en différé ceux qui commencent sous le premier écran (bonnes pratiques pour les contenus intégrés). Les bandeaux de cookies, les barres d’annonce et les publicités qui apparaissent tard et repoussent le contenu sont une cause classique de décalage. Donne-leur un emplacement fixe, ou affiche-les en superposition.

6. Retirer les extensions et scripts inutilisés. Chaque extension, chaque balise de suivi et chaque module peut apporter ses propres scripts et styles, souvent sur toutes les pages. Dresse la liste de ce qui est installé, supprime ce que personne n’utilise et remplace les plus lourds par des solutions plus légères. Retire-les un par un et mesure à nouveau : tu sauras lequel a changé quelque chose. Fais d’abord une sauvegarde. Dans WordPress, il est plus prudent de désactiver une extension sur une copie de test du site que sur le site en ligne. Lighthouse, dans PageSpeed Insights, liste le JavaScript et le CSS inutilisés et te mène aux coupables.

7. Retarder les widgets externes. Bulles de chat, fils de réseaux sociaux, badges d’avis, cartes, lecteurs vidéo et balises publicitaires chargent du code d’autres entreprises. Ils se chargent souvent en dernier et rivalisent avec ton propre contenu. Ne charge que ce qu’il te faut, et charge-le tard : ajoute async ou defer aux scripts, ou charge un widget seulement après un clic, avec une simple image d’aperçu à sa place (JavaScript tiers). Lighthouse signale le code tiers qui bloque le fil principal pendant 250 millisecondes ou plus (détails). Pour chaque widget, demande-toi : quelqu’un s’en sert-il ?

8. Charger les polices intelligemment. Utilise peu de familles et de graisses, et héberge les fichiers de police sur ton propre domaine au format WOFF2, avec seulement les caractères dont tu as besoin. Règle font-display pour que le texte s’affiche tout de suite dans une police de secours au lieu de rester invisible, et ne précharge que la ou les deux polices dont le premier écran a besoin (bonnes pratiques pour les polices). Un changement de police peut déplacer le texte : choisis une police de secours de taille proche.

9. Ajouter du cache et un réseau de diffusion de contenu. Un serveur lent retarde tout ce qui suit. Le cache permet au serveur ou au navigateur du visiteur de réutiliser une page au lieu de la reconstruire, et un réseau de diffusion de contenu (CDN) sert les fichiers depuis un emplacement proche du visiteur. La plupart des bons hébergeurs et des extensions de cache WordPress proposent les deux. Vérifie que les mises à jour apparaissent toujours après l’activation du cache (LCP et temps de réponse du serveur).

10. Mesurer à nouveau et garder un œil dessus. Refais l’étape 1 avec les mêmes pages et compare les valeurs. Ne change qu’une chose à la fois, pour voir ce qui a aidé. Vérifie encore dans un mois, car les données de terrain mettent 28 jours à suivre, et de nouvelles extensions, de gros fichiers ajoutés et de nouveaux widgets défont peu à peu le travail. Note un contrôle de vitesse dans ton agenda chaque trimestre, ou fais-le avant chaque mise à jour importante du contenu.

Quand demander de l’aide

Fais appel à quelqu’un d’expérimenté si :

• les valeurs restent rouges après les étapes 1 à 9
• tu n’as pas accès aux réglages du thème, de l’hébergement ou des extensions, ou tu ne sais pas qui y a accès
• le site repose sur du code sur mesure ou un constructeur de pages que personne ne maintient
• la lenteur vient du serveur lui-même, par exemple quand le premier octet met des secondes à arriver
• les pages lentes te coûtent des demandes ou des ventes, comme sur des pages d’atterrissage pour la publicité ou dans une boutique, et tu veux une installation mesurée et surveillée plutôt qu’une correction ponctuelle