Pourquoi votre application est lente sur mobile, et comment le mesurer vous-même

Votre ordinateur vous ment

Vous testez votre application sur un ordinateur puissant, avec une bonne connexion, et souvent avec la page déjà en mémoire. Vos clients l'ouvrent sur un téléphone ordinaire, en 4G, pour la première fois. L'écart peut aller du simple au quintuple.

Google mesure cet écart, et en tient compte dans son classement : un site lent sur mobile est aussi moins bien placé dans les résultats de recherche.

La mesure, en une minute

Ouvrez pagespeed.web.dev, collez l'adresse de votre page, lancez l'analyse, et regardez l'onglet Mobile (pas « Ordinateur »). Vous pouvez aussi utiliser Lighthouse, intégré à Chrome : touche F12, onglet Lighthouse, mode « Mobile », puis « Analyser ».

Testez au moins trois pages : l'accueil, la page la plus visitée, et la page où l'on paie ou réserve.

Les trois chiffres à lire

• LCP (Largest Contentful Paint), le temps avant que le contenu principal s'affiche. Bon en dessous de 2,5 secondes, mauvais au-delà de 4.
• INP (Interaction to Next Paint), le temps de réaction quand on touche un bouton. Bon en dessous de 200 millisecondes, mauvais au-delà de 500. Il n'apparaît que dans le bloc des données réelles, en haut du rapport PageSpeed, si votre site a assez de visiteurs. Dans Lighthouse, regardez à la place le TBT (Total Blocking Time) : bon en dessous de 200 millisecondes.
• CLS (Cumulative Layout Shift), les sauts de mise en page pendant le chargement : le bouton qui bouge au moment où l'on tape dessus. Bon en dessous de 0,1, mauvais au-delà de 0,25.

La note sur 100 résume les mesures faites par l'outil. En dessous de 50, elle est en rouge : votre page est lente sur la plupart des téléphones.

Les causes les plus fréquentes

En bas du rapport, les rubriques « Insights » et « Diagnostics » listent ce qui ralentit. On y retrouve presque toujours les mêmes coupables :

• un seul gros fichier de code chargé en entier sur chaque page, y compris des parties que le visiteur ne verra jamais (l'espace administrateur, par exemple) ;
• des scripts tiers chargés partout : un module de paiement chargé dès le planning, alors qu'il ne sert qu'au paiement, comme dans le constat K de Studio Kerelune, un outil d'analyse, une messagerie instantanée ;
• des images trop lourdes : une photo de 4 000 pixels affichée en vignette de 300, dans un format ancien ;
• des polices chargées depuis un service externe, qui retardent l'affichage du texte (et transmettent au passage l'adresse IP de vos visiteurs) ;
• des animations décoratives trop gourmandes pour un téléphone.

Ce dernier point, nous l'avons vécu sur notre propre site : le ciel étoilé animé de leonox.tech bloquait les téléphones modestes. Sur mobile, le score était de 70 ; avec le ciel fixe sur petit écran, il est passé à 97, pour un rendu presque identique.

Si votre score est mauvais

Commencez par ce qui coûte le moins et rapporte le plus : charger les scripts tiers seulement là où ils servent, compresser et redimensionner les images, héberger les polices avec le site. Le découpage du code par page demande un développeur, mais c'est souvent le gain le plus important sur les applications générées par une IA. Après chaque changement, refaites la mesure : c'est le seul juge.

Ce que cette mesure ne couvre pas

La vitesse des réponses de votre base de données quand le volume monte (voir notre guide Votre application tiendra-t-elle à dix fois plus de clients ?), les pages réservées aux utilisateurs connectés, que PageSpeed ne peut pas ouvrir, et ce qui se passe une fois la page chargée. C'est ce que couvre l'axe « qualité et performance » de notre diagnostic.