Un site lent fait partir des visiteurs, surtout sur mobile, mais « lent » ne dit pas où se trouve le problème. Il peut venir du serveur, des images, du code ou de scripts chargés depuis d’autres sites. Ce guide commence par la mesure, puis passe en revue les causes les plus fréquentes.
Les points à retenir
- Mesurez d’abord avec les données de vrais visiteurs (Search Console, PageSpeed Insights) avant de vous fier à un test de laboratoire.
- Repérez quelle métrique est mauvaise : LCP (chargement), INP (réactivité) ou CLS (stabilité visuelle).
- Corrigez une cause à la fois et remesurez, sinon vous ne savez pas ce qui a servi.
1. Mesurer avec les bons outils
PageSpeed Insights (pagespeed.web.dev) analyse une adresse et affiche deux séries de résultats. La première, « Données utilisateurs réelles », provient de visiteurs de Chrome sur les 28 derniers jours ; elle n’apparaît que si l’adresse reçoit assez de trafic. La seconde est un test de laboratoire exécuté par Lighthouse : il sert à reproduire un problème, mais ses résultats varient d’un test à l’autre.
Dans Google Search Console, le rapport « Signaux Web essentiels » classe les pages du site par état (bon, à améliorer, médiocre), pour mobile et pour ordinateur. Il montre si le problème touche une page isolée ou un modèle de page entier, ce qui change le travail à faire.
2. Comprendre les trois métriques
Les Core Web Vitals sont trois mesures publiées par Google, évaluées sur le 75e centile des visites. Le LCP (Largest Contentful Paint) mesure le temps d’affichage du plus gros élément visible, souvent une image ou un titre : il est bon jusqu’à 2,5 secondes. L’INP (Interaction to Next Paint) mesure le délai entre un clic ou une frappe et la réponse visible de la page : il est bon jusqu’à 200 millisecondes. Le CLS (Cumulative Layout Shift) mesure les décalages de mise en page pendant le chargement : il est bon jusqu’à 0,1. L’INP a remplacé le FID en mars 2024.
Chaque métrique oriente vers des causes différentes. La liste ci-dessous indique où chercher en premier.
- LCP élevé : temps de réponse du serveur, image principale trop lourde ou chargée tard.
- INP élevé : JavaScript volumineux, scripts tiers, menus ou filtres qui bloquent le navigateur.
- CLS élevé : images sans dimensions, polices qui changent à l’affichage, bandeaux ou publicités insérés après coup.
Référence : web.dev : Core Web Vitals.
3. Images trop lourdes
Une photo de 4 000 pixels de large affichée dans une colonne de 800 pixels oblige le navigateur à télécharger un fichier bien plus lourd que nécessaire. Redimensionnez les images à leur taille d’affichage, utilisez un format moderne comme WebP ou AVIF et renseignez la largeur et la hauteur dans le code : la page réserve alors l’espace avant le chargement, ce qui réduit le CLS.
Le chargement différé (attribut loading="lazy") convient aux images situées sous la première fenêtre. Sur l’image principale en haut de page, qui détermine souvent le LCP, il retarde l’affichage : laissez-la se charger normalement, voire ajoutez fetchpriority="high".
4. Trop d’extensions, thème chargé, pas de cache
Chaque extension ajoute du code PHP exécuté à chaque requête, des feuilles de style et des scripts. Le nombre n’est pas le seul critère : une extension de sauvegarde ou de statistiques peut peser plus que dix petites. Sur un site de test, l’extension Query Monitor affiche les requêtes lentes et les extensions qui les produisent.
Le cache de page enregistre la version finale d’une page pour la servir sans refaire les calculs à chaque visite. Sans lui, WordPress interroge la base de données à chaque affichage. Une extension comme WP Rocket ou LiteSpeed Cache, ou le cache fourni par l’hébergeur, change souvent beaucoup de choses sur un site de contenu. Sur une boutique, le panier et la page de paiement ne doivent pas être mis en cache : vérifiez que la configuration les exclut.
5. Hébergement sous-dimensionné
Le TTFB (Time To First Byte) est le délai avant que le serveur renvoie le premier octet de la page. web.dev recommande de rester à 0,8 seconde ou moins. Un TTFB élevé, même sur une page simple, pointe vers le serveur : ressources partagées saturées, version de PHP ancienne, base de données lente.
Mesurez-le plusieurs fois, à des heures différentes. Passer à une version de PHP maintenue peut apporter un gain sans changer d’offre ; contrôlez d’abord la compatibilité des extensions sur un site de test.
- curl -o /dev/null -s -w "%{time_starttransfer}\n" https://exemple.fr : affiche le TTFB en secondes depuis votre poste.
- Navigateur : onglet Réseau des outils de développement, colonne « Temps d’attente » de la première requête.
6. Scripts tiers et polices
Les widgets de chat, pixels publicitaires, gestionnaires de balises, cartes et vidéos intégrées chargent du code depuis d’autres serveurs que le vôtre. Vous ne contrôlez ni leur poids ni leur disponibilité. La section « Diagnostics » de PageSpeed Insights indique le temps pris par chaque domaine tiers. Pour chacun, demandez-vous s’il est utile, et chargez-le seulement quand le visiteur le demande : un clic pour afficher la vidéo ou la carte suffit souvent.
Les polices web posent un problème voisin. Tant que la police n’est pas chargée, le texte s’affiche avec une autre, puis change d’aspect et décale la page. Hébergez les polices sur votre domaine, limitez le nombre de graisses et ajoutez font-display: swap pour que le texte s’affiche tout de suite avec une police de secours.
Et pour votre site ?
Une fois la métrique faible identifiée, le travail consiste à traiter les causes dans l’ordre de leur effet et à remesurer après chaque changement. L’expertise performance de Serein commence par ce relevé, avant de proposer des actions.
Faire mesurer la vitesse de mon site