La performance mobile n’est pas la version étroite de la performance ordinateur. Le téléphone a moins de marge de calcul, le réseau change d’une minute à l’autre, et la zone visible est petite : un seul visuel trop lourd occupe tout l’écran et décide du moment où la page semble prête. On traite cet élément, puis le JavaScript qui bloque le fil, puis les fichiers qui n’ont rien à faire sur un petit écran.
L’élément qui remplit l’écran
Sur un viewport de téléphone, le plus grand élément au chargement est souvent l’image d’en-tête, parfois un titre si l’image est plus bas. C’est le candidat LCP. Il doit :
- avoir des attributs de taille, pour ne pas décaler le texte quand il arrive ;
- être proposé à une largeur proche de l’écran, via
srcset, et non en 3000 pixels « pour les grands moniteurs » ; - être dans un format compact, comme décrit dans WebP et AVIF ;
- ne pas porter
loading="lazy", qui retarde précisément cet élément.
Une bannière masquée en CSS sur mobile mais quand même téléchargée coûte le réseau pour rien. Si la maquette mobile n’affiche pas l’image, ne la chargez pas sur ce viewport. À l’inverse, une image différente sur mobile doit avoir elle aussi une taille adaptée, pas la même source « en plus petit à l’affichage » après un téléchargement complet.
Le texte du premier écran ne doit pas attendre une police distante. font-display: swap et un seul fichier préchargé suffisent dans la plupart des cas. Le détail est dans polices web.
Calcul et scripts tiers
L’INP, mesuré chez les visiteurs, baisse quand le fil principal est occupé au moment où la personne tape ou touche. Sur téléphone, la même fonction JavaScript dure plus longtemps. Les constructeurs de page, les sliders, les gestionnaires de balises et les chats sont les premiers à couper dans un essai : retirez-en un, remesurez. Si l’interaction redevient fluide, vous avez la cause, sans profiler tout le bundle.
Chargez plus tard ce qui est sous la ligne de flottaison : carte, lecteurs, avis tiers. Un script dans le <head> sans defer ni async retarde l’analyse du HTML sur l’appareil le moins à l’aise pour le faire.
Les mises en page qui dépendent d’un framework JavaScript pour afficher le premier paragraphe ajoutent un aller-retour de script avant le moindre texte. Sur ordinateur de bureau en local, cela passe. Sur un réseau mobile moyen, le premier écran reste vide. Servez le contenu principal dans le HTML.
Le zoom et les cibles tactiles ne sont pas un score de laboratoire, mais une page « rapide » dont les liens sont trop serrés reste inutilisable. Un viewport width=device-width est le minimum. Un site qui désactive le zoom pour figer une maquette crée un autre problème d’usage, distinct du poids.
Laboratoire mobile et visiteurs
Lighthouse en mode mobile bride le réseau et le processeur de façon volontairement reproductible. C’est un outil de comparaison avant et après un correctif, pas la moyenne de vos visiteurs. Cette moyenne, quand Google la publie, est dans le rapport de terrain. Pourquoi un site peu visité n’y figure pas, et comment lire les deux, est le sujet de RUM et laboratoire. Les seuils des signaux web sont rappelés dans Core Web Vitals.
Testez aussi sur un téléphone réel, une fois, hors Wi-Fi du bureau : le laboratoire ne reproduit pas un cache déjà chaud ni une couverture faible. Une seule séance suffit à voir si l’image principale arrive, si le menu répond au toucher, si une barre tierce recouvre le contenu. SiteGarde mesure le temps de réponse du serveur, identique quel que soit l’écran. Il ne voit pas le coût CPU du JavaScript sur le téléphone : ce coût se mesure dans le navigateur.