Un site WordPress lent coûte des clients avant même qu’ils aient lu une ligne : sur mobile, beaucoup de visiteurs abandonnent une page qui met plusieurs secondes à s’afficher. Google en tient compte aussi, à travers les Core Web Vitals. La bonne nouvelle, c’est qu’un site lent a presque toujours une cause identifiable. Voici la méthode que j’applique sur les optimisations que je réalise : mesurer, trouver la vraie cause, corriger, puis mesurer à nouveau.

Étape 1 : mesurer avant de toucher quoi que ce soit

Sans mesure, on optimise au hasard. Deux outils gratuits suffisent pour commencer :

  • PageSpeed Insights (pagespeed.web.dev) : il affiche les données réelles de vos visiteurs quand elles existent, et un test de laboratoire avec des recommandations. Testez la page d’accueil, mais aussi une page de service, un article et, pour une boutique, une fiche produit.
  • Le temps de réponse du serveur (TTFB) : c’est le temps que met le serveur à commencer à envoyer la page. S’il dépasse largement une demi-seconde, le problème vient du serveur ou de WordPress lui-même, pas des images.

Les trois indicateurs à surveiller sont le LCP (affichage du contenu principal, bon sous 2,5 secondes), l’INP (réactivité aux clics, bonne sous 200 millisecondes) et le CLS (stabilité de la mise en page, bonne sous 0,1).

Les causes les plus fréquentes d’un site WordPress lent

1. Un hébergement sous-dimensionné

Un hébergement mutualisé d’entrée de gamme partage ses ressources entre des centaines de sites. Quand le serveur est saturé, aucune optimisation côté WordPress ne compense. Un temps de réponse élevé même sur une page simple est le signe typique. Dans ce cas, changer d’offre ou d’hébergeur est souvent la mesure la plus rentable, et une migration bien préparée se fait sans coupure.

2. Pas de cache de page

Sans cache, WordPress reconstruit chaque page à chaque visite : requêtes PHP, base de données, extensions. Un cache de page sert directement une version déjà prête. C’est souvent le gain le plus spectaculaire sur un site vitrine. Attention avec WooCommerce : le panier, le compte client et la commande ne doivent jamais être mis en cache.

3. Des images trop lourdes

Une photo de 4 Mo affichée en vignette de 400 pixels de large est l’erreur la plus courante. Il faut redimensionner, compresser, utiliser un format moderne comme le WebP et charger en différé les images situées plus bas dans la page. En revanche, l’image principale du haut de page doit se charger tout de suite : la retarder dégrade le LCP.

4. Des extensions trop gourmandes

Le nombre d’extensions compte moins que leur qualité. Une seule extension mal écrite peut charger ses scripts sur toutes les pages ou lancer des requêtes lourdes à chaque visite. L’extension Query Monitor permet de repérer celles qui ralentissent le serveur. Les constructeurs de pages chargent aussi beaucoup de code : bien réglés, ils restent acceptables, mais ils demandent plus de soin.

5. Une base de données encombrée

Révisions d’articles par milliers, données temporaires expirées, tables laissées par d’anciennes extensions, options chargées automatiquement à chaque page : la base grossit sans que personne ne s’en aperçoive. Un nettoyage ciblé, fait après une sauvegarde, réduit nettement le temps de réponse sur les sites anciens.

6. Des scripts externes

Chat en ligne, outils de suivi, polices, vidéos intégrées, widgets de réseaux sociaux : chaque service externe ajoute des requêtes vers d’autres serveurs. Gardez ceux qui servent vraiment et chargez les autres après l’affichage de la page.

7. Une version de PHP dépassée

Les versions récentes de PHP sont nettement plus rapides que PHP 7. Passer à une version supportée améliore les performances et la sécurité, à condition de vérifier la compatibilité du thème et des extensions. J’explique la démarche dans le guide passer de PHP 7 à PHP 8.

Étape 2 : corriger dans le bon ordre

  1. Le serveur : version de PHP, ressources, cache objet si l’hébergeur le propose.
  2. Le cache de page, avec les bonnes exclusions pour les pages dynamiques.
  3. Les images : formats, dimensions, chargement différé.
  4. Le code : scripts et styles inutiles, extensions remplacées ou supprimées.
  5. La base de données, après une sauvegarde complète.

Chaque correction se teste sur une copie ou à un moment calme, en vérifiant ensuite les formulaires, le panier et les pages clés. Une optimisation qui casse le tunnel de commande coûte plus cher que la lenteur.

Étape 3 : mesurer à nouveau et garder le niveau

Refaites les mêmes mesures, sur les mêmes pages, pour constater le gain réel. Ensuite, la vitesse se dégrade naturellement : nouvelle extension, nouvelles images, nouvelle version d’un thème. Une maintenance régulière (voir la checklist de maintenance) permet de surveiller ces indicateurs et de corriger avant que les visiteurs ne le remarquent. Si vous ne savez pas par où commencer, un audit complet classe les problèmes par priorité.

Questions fréquentes

Une extension de cache suffit-elle à rendre un site rapide ?

Elle aide beaucoup quand la cause est l’absence de cache. Mais elle ne corrige ni un serveur saturé, ni des images de plusieurs mégaoctets, ni une extension qui ralentit chaque requête. C’est pour cela qu’il faut mesurer avant d’installer quoi que ce soit.

Faut-il viser 100/100 sur PageSpeed Insights ?

Non. Le score de laboratoire est un indicateur, pas un objectif. Ce qui compte, ce sont les Core Web Vitals de vos vrais visiteurs et le ressenti sur mobile. Un site à 85 qui s’affiche vite et ne bouge pas vaut mieux qu’un site à 100 dont une fonction utile a été supprimée.

Mon site est lent seulement dans l’administration, est-ce lié ?

Souvent, oui. Une administration lente révèle généralement un serveur saturé, une base de données encombrée ou une extension qui lance des tâches lourdes en arrière-plan. Le cache de page ne s’applique pas à l’administration, donc ces problèmes y sont plus visibles.