Site web lent : comment diagnostiquer et prioriser les corrections

Un affichage tardif, une interaction qui répond mal ou une page qui bouge pendant la lecture peuvent gêner une tâche. L’effet commercial dépend toutefois du contexte, du public et du parcours ; un test de vitesse ne permet pas de chiffrer à lui seul des ventes perdues.

Commencez par les pages et actions prioritaires. Notez l’appareil, la connexion, la localisation du serveur, le statut de cache et l’étape qui pose problème afin de rendre le constat reproductible.

LCP mesure l’affichage du principal contenu visible, INP la réactivité globale aux interactions et CLS la stabilité visuelle. Pour être dans la zone « bonne » publiée par Google, les objectifs sont un LCP inférieur ou égal à 2,5 secondes, un INP inférieur ou égal à 200 millisecondes et un CLS inférieur ou égal à 0,1.

Ces seuils s’évaluent au 75e centile des chargements, séparément sur mobile et ordinateur lorsque les données le permettent. Ils décrivent des dimensions précises de l’expérience, pas la valeur globale d’une page ni son résultat commercial.

Les données terrain proviennent d’utilisateurs réels et reflètent leurs appareils, réseaux et parcours. Elles ont besoin d’un volume suffisant et portent souvent sur une période glissante. PageSpeed Insights peut les afficher lorsqu’elles sont disponibles.

• Lighthouse produit un diagnostic de laboratoire dans des conditions simulées.
• Il est utile pour reproduire un problème et tester une correction, mais son score peut varier.
• Analysez les métriques et recommandations plutôt que de traiter la note comme un objectif commercial.

Pour le LCP, examinez l’image ou le bloc principal, le temps de réponse, les ressources bloquantes et le moment où le navigateur découvre l’élément. Pour l’INP, cherchez les tâches JavaScript longues et le travail exécuté après une interaction.

Pour le CLS, réservez l’espace des images, publicités et contenus injectés, puis contrôlez les polices et composants tardifs. Une correction doit viser la cause observée sur le modèle de page concerné, pas une liste générique appliquée partout.

Corrigez d’abord ce qui bloque une action ou touche plusieurs pages : ressource principale trop lourde, script tiers coûteux, mise en page instable ou réponse serveur irrégulière. Vérifiez ensuite que l’amélioration ne dégrade ni accessibilité ni fonctionnalité.

Déployez les changements mesurables par petits groupes et comparez les mêmes conditions. Pour les données terrain, laissez le temps à de nouvelles observations de remplacer les anciennes au lieu d’attendre un changement instantané.

La première est le poids des images. Une photo de quatre mégaoctets sortie d’un téléphone, affichée dans un cadre de trois cents pixels, oblige chaque visiteur à télécharger cent fois plus que nécessaire. Redimensionner, compresser et servir un format moderne comme WebP ou AVIF divise le poids d’une page par cinq ou dix sans perte visible ; c’est presque toujours la première correction à faire.

La deuxième est l’accumulation de scripts tiers : outils de statistiques, widgets de chat, polices chargées depuis un service externe, boutons de partage, pixels publicitaires. Chacun paraît léger seul ; ensemble, ils bloquent le rendu et occupent le processeur du téléphone pendant des secondes. Un inventaire honnête en retire souvent la moitié sans que personne ne s’en aperçoive.

Viennent ensuite un hébergement sous-dimensionné qui répond lentement à la première requête, un thème ou un constructeur de pages qui charge tout son CSS et son JavaScript sur chaque page, et des polices web non optimisées qui font clignoter le texte. Ces cinq causes expliquent la majorité des mauvais LCP et INP constatés sur les sites de PME.

Ouvrez le rapport et commencez par la section des données réelles, si elle existe. C’est la seule qui décrit ce que vos visiteurs vivent. Notez quelle métrique échoue et sur quel type d’appareil ; un LCP mauvais sur mobile mais bon sur ordinateur oriente immédiatement vers le poids des ressources et le réseau, pas vers le serveur.

• Descendez ensuite vers les diagnostics de laboratoire et cherchez l’élément LCP identifié par l’outil.
• Si c’est une image, le problème est son poids, son format ou le moment où le navigateur la découvre.
• Si c’est un bloc de texte, regardez les polices et le CSS bloquant.
• Cette lecture ciblée évite de passer une journée à optimiser quelque chose qui ne pèse pas dans la mesure.

• Ignorez le score global comme objectif.
• Deux pages à 70 peuvent avoir des problèmes sans rapport, et passer de 70 à 95 en laboratoire ne change rien si le LCP réel reste mauvais.
• Traitez les recommandations comme une liste de pistes classées par gain estimé, et vérifiez le gain réel après chaque correction.

Étape un : les images. Redimensionnez-les aux dimensions réellement affichées, convertissez-les en WebP ou AVIF, déclarez leurs dimensions dans le code et chargez en priorité celle qui apparaît en haut de page, en différant les autres. Cette étape seule règle souvent le LCP et le CLS.

• Étape deux : les scripts.
• Listez chaque script tiers, demandez à qui il sert, et supprimez ceux qui n’ont pas de réponse.
• Différez ceux qui restent après le rendu de la page.
• Un outil de statistiques peut attendre une seconde ; un widget de chat peut se charger au premier défilement.

Étape trois : le serveur et la mise en cache. Vérifiez le temps de réponse de la première requête ; au-delà de quelques centaines de millisecondes, un cache de pages ou un réseau de diffusion de contenu s’impose. Étape quatre : les polices et le CSS, en limitant le nombre de fichiers de police, en les hébergeant sur le site et en ne chargeant que les styles nécessaires. Mesurez entre chaque étape, sinon vous ne saurez pas laquelle a agi.

Les études publiées par les grands acteurs du web associent régulièrement une augmentation du temps de chargement à une baisse des conversions. Ces résultats viennent de sites à très fort trafic et ne se transposent pas tels quels à un commerce de quartier ; les citer comme une loi universelle serait malhonnête.

Ce qui se vérifie en revanche sur n’importe quel site : un visiteur mobile sur un réseau moyen qui attend cinq secondes devant un écran blanc a le temps de revenir aux résultats de recherche et de choisir le concurrent suivant. La lenteur ne fait pas fuir tout le monde ; elle fait fuir une partie des personnes les moins décidées, qui sont précisément celles qu’un site doit convaincre.

Pour mesurer chez vous, comparez le taux de visiteurs qui quittent la page d’entrée sans interaction avant et après une correction, à période et source de trafic comparables. Ce n’est pas une preuve, mais c’est une indication propre à votre site, bien plus utile qu’un pourcentage lu ailleurs.

Un site corrigé se dégrade dès la première image lourde publiée sans compression ou le premier script ajouté « pour tester ». La performance est une hygiène, pas un projet clos. Fixez trois règles simples pour ceux qui publient : toute image passe par un redimensionnement automatique, tout nouveau script est justifié par écrit, toute nouvelle page est vérifiée sur mobile avant publication.

Automatisez ce qui peut l’être. Un système de gestion de contenu ou une chaîne de construction moderne peut redimensionner et convertir les images à la publication, sans intervention. Un budget de performance — poids maximal par page, nombre maximal de scripts — vérifié à chaque mise en production arrête les régressions avant qu’elles n’atteignent les visiteurs.

Enfin, regardez les données réelles une fois par mois. Elles évoluent avec les appareils, les réseaux et les contenus ; une métrique qui glisse lentement vers le mauvais côté se corrige à peu de frais tant qu’elle est repérée tôt.

Google recommande de viser de bons Core Web Vitals pour la recherche et pour les utilisateurs. Il précise toutefois que l’expérience de page comprend d’autres aspects et qu’un bon score ne garantit pas les premières positions.

Travaillez donc la vitesse pour les utilisateurs et la robustesse du service. Associez-la à un contenu utile, une architecture compréhensible, une compatibilité mobile, une connexion sécurisée et l’absence d’interstitiels gênants.