Un site rapide sur l’ordinateur du bureau et lent sur téléphone n’est pas « normalement lent à cause de la 4G ». L’écart vient souvent d’un HTML différent, d’une image trop lourde devenue l’élément LCP, d’un cache qui ne sert pas les mobiles, ou du même JavaScript exécuté sur un processeur bien plus lent. On ne le voit pas en réduisant la fenêtre du navigateur.
Séparer terrain et laboratoire
Search Console, rapport Core Web Vitals, distingue mobile et ordinateur. Ce sont des mesures de terrain : vrais téléphones, vrais réseaux, regroupées par Google. Si seul le mobile est « à améliorer » ou « médiocre », l’écart existe chez les visiteurs, pas seulement dans un test.
Lighthouse en mode mobile bride le processeur et le réseau. C’est un modèle de laboratoire, utile pour comparer deux versions, pas une copie du téléphone d’un client. WebPageTest, profil mobile, montre en plus la cascade et le film du chargement. Le cadre des trois indicateurs (LCP, INP, CLS) est dans Core Web Vitals.
Regardez l’élément LCP des deux côtés. Sur mobile, c’est souvent l’image du bandeau, en pleine largeur. Sur ordinateur, le même bandeau peut être plus petit à l’écran, ou le LCP peut être un bloc de texte. Optimiser le titre ne changera rien au téléphone si l’image est le LCP.
Causes qui ne touchent que le mobile
Image sans srcset. Le téléphone télécharge le JPEG de 2000 pixels prévu pour le bureau. Le correctif est une source adaptée à la largeur réelle, et surtout pas loading="lazy" sur cette image LCP. Voir lazy-loading.
HTML différent. Un thème « mobile » encore actif, un cache ou un CDN qui varie sur le User-Agent, une page AMP oubliée. Comparez « Afficher le code source » avec un user-agent mobile et sans. Si le HTML, les CSS ou l’image hero diffèrent, vous n’avez pas un seul site lent : vous en avez deux.
Cache manqué. Beaucoup de pages anonymes sont mises en cache pour un user-agent « bureau ». Le mobile tombe dans une règle d’exclusion et attend le PHP à chaque fois. Le temps jusqu’au premier octet, mesuré avec le même outil et deux user-agents, le montre.
JavaScript identique, processeur plus lent. Le même bundle met 200 ms sur le poste de dev et bien plus sur un téléphone d’entrée de gamme. L’INP et les longues tâches s’en ressentent d’abord sur mobile. Réduire le script (constructeur, tags) aide le mobile plus que l’ordinateur, même si les deux téléchargent le même fichier. Le tri des tags est dans scripts tiers.
Bandeau et interstitiel. Un consentement ou une pop-up qui couvre l’écran retarde le LCP et peut dégrader le CLS, surtout sur petit écran. Mesurez avec et sans, sur le même profil.
La séquence de diagnostic
- Notez LCP, INP et CLS mobile et ordinateur dans Search Console, sur la même période.
- Identifiez l’élément LCP sur un profil mobile (Lighthouse ou WebPageTest), pas seulement sur le bureau.
- Comparez le HTML et la liste des requêtes avec un user-agent mobile. Cherchez une image plus lourde, un CSS de plus, un cache absent (en-tête
X-Cacheou équivalent en « miss » seulement d’un côté). - Corrigez une cause :
srcsetet dimensions de l’image LCP, ou mise en cache de la variante mobile, ou retrait d’un script. - Remesurez en laboratoire sur le même profil. Le rapport de terrain met plusieurs semaines à bouger : ne concluez pas le lendemain depuis Search Console seul.
Si le téléphone est lent uniquement sur un réseau (partage de connexion d’un opérateur) et que le laboratoire bridé est correct, regardez le DNS et un éventuel proxy de cet opérateur. Ce n’est plus un problème de modèle de page. S’il est lent sur tous les téléphones testés, y compris en Wi-Fi, la cause est dans la page servie au mobile.
Le mode responsive du navigateur reste utile pour la mise en page. Il ne sert pas à trancher une lenteur. Sans bridage, votre poste de développement exécute le JavaScript trop vite et masque le problème que les visiteurs ont déjà.