Quand un site est lent ou bloque sur mobile, on accuse volontiers le serveur. Sur notre propre site, lyaandco.com, l’essentiel du problème était ailleurs : voici ce que nous avons trouvé, corrigé et mesuré, avec les chiffres avant/après et ce qu’il reste à faire.

Le constat : un serveur rapide, une page lente sur mobile

Le 28 septembre 2026, nous avons audité notre site comme celui d’un client. Sur ordinateur, l’accueil obtenait 92/100 à l’outil d’audit Lighthouse. Sur mobile, mesuré en laboratoire en 4G lente simulée, il tombait à 47/100 : l’écran restait blanc 6,75 s et l’image principale n’apparaissait qu’au bout de 10,9 s.

Le temps de calcul du serveur, lui, n’était pas en cause : le 28 septembre comme aujourd’hui, l’accueil se calcule en 0,16 s environ. Le temps se perdait entre le serveur et l’écran du téléphone.

Un second symptôme, signalé le lendemain, était plus déroutant : sur téléphone, le site « bloquait », les premiers gestes ne faisaient rien défiler. En cause, une seule ligne de style, qui fixait le pied de page à 60 px de haut alors que son contenu en fait environ 850 sur mobile. Combinée à une autre règle du thème, elle créait un cadre de défilement invisible, sur téléphone comme sur ordinateur : le doigt faisait défiler ce cadre, pas la page.

Six causes classiques, et leurs corrections

• Rien n’était compressé, et le navigateur ne recevait aucune consigne de cache. Avant le premier affichage, le téléphone devait télécharger 1 079 Ko de styles et de scripts. Compressés, ils pèseraient environ 210 Ko : à 1,6 Mbit/s, environ 1 s de téléchargement au lieu de 5,4 s. Les fichiers texte sont désormais compressés, et le navigateur sait combien de temps garder chaque fichier.
• Des images trop lourdes. Sur la page Produits, deux captures de plus de 2 000 px de large (540 Ko) s’affichaient dans un cadre de 282 × 152 px sur mobile. Réduites à 1 280 px et converties en WebP, elles pèsent environ 57 et 50 Ko (−80 %).
• Des images fantômes. Un carrousel contenait 8 images sans fichier, qui renvoyaient vers l’accueil : le serveur le recalculait 3 fois de plus à chaque visite. Une image transparente intégrée à la page les a remplacées.
• Un script tiers qui fige l’écran. L’outil de mesure d’audience (177 Ko) s’exécutait pendant le défilement et bloquait l’écran jusqu’à 183 ms d’affilée, en laboratoire sur mobile ralenti. Nous avons d’abord repoussé son chargement après l’affichage. Depuis le 29 septembre, il attend aussi un clic sur « Accepter ». À la première visite, avant tout choix, l’accueil n’appelle plus aucun domaine extérieur ; le 28 septembre, il envoyait 9 requêtes extérieures (audience et polices).
• Une page qui saute. Le diaporama de l’accueil avait une hauteur nulle tant que son script n’avait pas démarré, puis prenait soudain 400 à 680 px de haut. Sa hauteur est désormais réservée d’emblée, pour chaque taille d’écran.
• Des polices venues d’ailleurs. La page bougeait encore à l’affichage (décalage, ou CLS, d’environ 0,3 en laboratoire, sur mobile ralenti) : les polices, chargées chez un fournisseur extérieur, arrivaient tard et remplaçaient les polices provisoires. Nous les hébergeons désormais nous-mêmes : sur l’accueil, le décalage tombe à environ 0,02 dans les mêmes conditions.

Pour le défilement bloqué, nous avons contrôlé 18 pages, sur mobile et sur ordinateur : plus aucun cadre caché ni débordement horizontal. Leçon de méthode : notre premier test automatique faisait défiler la page par programme et ne voyait rien ; il a fallu simuler de vrais gestes du doigt.

Au-delà de la page : le serveur et les contenus tiers

Parfois, le serveur est bien en cause. Sur un site que nous hébergeons, il mettait 0,88 s à calculer la page d’accueil : le moteur d’exécution recompilait tout son code à chaque visite. Une fois passé dans un mode qui garde ce code compilé en mémoire, le serveur calcule l’accueil en 0,43 s, environ deux fois moins. Sur un autre site que nous hébergeons, le même changement l’a fait passer de 0,92 s à 0,38 s.

Sur le premier site, certaines pages affichaient des actualités tirées de nombreux flux externes. Pour les utilisateurs connectés, ces flux étaient récupérés en direct à chaque affichage, sans cache : si une source mettait plusieurs secondes à répondre, la page attendait avec elle. Nous gardons désormais une copie locale de chaque flux, rafraîchie toutes les 20 minutes avec un délai de réponse maximal ; si une source ne répond pas, la dernière bonne copie reste affichée. Pour ces utilisateurs, ces pages se calculent maintenant en moins d’une seconde, contre plusieurs secondes auparavant.

La règle : tout ce qui vient d’un site tiers (actualités, polices, statistiques) peut rendre votre site aussi lent que le plus lent d’entre eux. Hébergez chez vous ce que vous pouvez, et imposez au reste un délai maximal.

La check-list du dirigeant

• Testez avec le doigt. Ouvrez votre site sur un téléphone, faites défiler, touchez le menu.
• Exigez une mesure avant et après, sur mobile, en connexion lente simulée, avec le même outil et les mêmes réglages. Un score varie de quelques points d’un passage à l’autre : comparez des médianes.
• Après chaque retouche de style, revérifiez sur petit écran, à 360 et 390 px de large.
• Connaissez le repère. Selon web.dev (Google), l’expérience est jugée bonne quand 75 % des visites réelles respectent trois seuils : le contenu principal s’affiche en 2,5 s au plus, la page réagit en 200 ms au plus et le décalage ne dépasse pas 0,1.

Où en est lyaandco.com au 30 septembre

Nous avons repris l’outil et les réglages du 28 septembre (mesures en laboratoire, 4G lente simulée, médiane de trois passages). Le contenu de l’accueil a un peu changé entre-temps. Les résultats :

• score mobile de l’accueil : de 47 à environ 75 sur 100 ;
• premier affichage : de 6,75 s à 2,81 s ;
• image principale : de 10,9 s à 5,4 s ;
• décalage : sous 0,1 sur toutes les pages mesurées.

Lors d’une première visite (rien en mémoire dans le navigateur), en laboratoire et en 4G lente simulée comme le 28 septembre, le poids de l’accueil est passé de 2,64 Mo à 1,09 Mo. Une partie du gain tient au script d’audience, qui se chargeait d’office le 28 septembre ; sans lui, la baisse reste de 56 %.

Ce qui reste à faire : même en laboratoire, notre image principale reste loin du repère de 2,5 s. Les polices représentent environ 40 % du poids de l’accueil : c’est la prochaine piste à étudier. Enfin, seul le moteur de Chrome a été testé : restent d’autres navigateurs et de vrais téléphones.

Vous voulez savoir ce qui ralentit votre site ? Nous établissons ce diagnostic, mesures à l’appui. Parlons-en.