Site WordPress lent : pourquoi, et comment l'accélérer pour de bon.

« Mon site est lent » est la deuxième demande que je reçois le plus, juste après « mon site est piraté ». Et dans les deux cas, la cause est rarement là où on la cherche. On accuse WordPress, on accuse l'hébergeur, on installe un plugin miracle… et trois mois plus tard, rien n'a changé. Voici une méthode qui change quelque chose.

Ce que la lenteur vous coûte vraiment

Les chiffres de Google sont connus mais valent d'être rappelés : 53 % des visiteurs mobiles quittent un site qui met plus de 3 secondes à s'afficher, et la probabilité de rebond augmente de 32 % quand le temps de chargement passe de 1 à 3 secondes. Depuis 2021, la vitesse fait aussi partie des signaux de classement via les Core Web Vitals.

Pour un artisan ou une PME locale, c'est très concret : la personne qui cherche « plombier Lagny » sur son téléphone, au bord de la fuite, ne vous attend pas. Elle revient en arrière et appelle le suivant. Un site lent, c'est de la publicité payée pour les concurrents — et si vous faites du Google Ads, c'est littéralement de l'argent jeté, puisque vous payez le clic d'un visiteur qui repart avant d'avoir vu la page.

Mesurer : les outils et les chiffres à regarder

Avant de toucher quoi que ce soit, mesurez. Trois outils gratuits suffisent :

• PageSpeed Insights : la référence Google. Regardez d'abord les données terrain (ce que vivent vos vrais visiteurs sur 28 jours) quand elles sont disponibles, puis le diagnostic de laboratoire pour les causes. Testez en mobile, c'est là que ça se joue.
• GTmetrix : la cascade de chargement (waterfall) montre fichier par fichier ce qui prend du temps. C'est l'outil qui désigne les coupables.
• Query Monitor (plugin WordPress) : côté serveur, quels plugins et quelles requêtes SQL ralentissent la génération de la page.

Les quatre chiffres à retenir, avec les seuils Google :

Les 9 causes d'un site WordPress lent

Classées par fréquence, d'après les sites qui passent entre mes mains.

1. Un hébergement sous-dimensionné

Un TTFB au-delà d'une seconde signe presque toujours un hébergement mutualisé d'entrée de gamme saturé, parfois combiné à une version de PHP ancienne. Aucune optimisation côté WordPress ne rattrape un serveur qui met 1,5 s à commencer à répondre. Un hébergement sérieux pour un site vitrine coûte entre 5 et 15 € par mois ; ce n'est pas là qu'il faut économiser.

2. Pas de cache de page

Sans cache, WordPress reconstruit chaque page à chaque visite : PHP s'exécute, interroge la base de données des dizaines de fois, assemble le HTML. Avec un cache, la page est servie toute faite en quelques millisecondes. C'est l'optimisation au meilleur rapport effort/gain, et elle manque sur une part étonnante des sites que je reçois.

3. Des images non optimisées

La photo de 4 000 pixels et 3 Mo sortie directement de l'appareil, affichée en 800 pixels de large. Pas de format moderne (WebP ou AVIF, 30 à 50 % plus légers que le JPEG), pas de dimensions déclarées (d'où les sauts de mise en page), pas de chargement différé pour les images sous la ligne de flottaison. Sur un site vitrine, les images représentent souvent 70 % du poids total.

4. Trop de plugins, ou les mauvais

Ce n'est pas le nombre qui compte, c'est ce qu'ils chargent. Un slider, un plugin de « réseaux sociaux », un constructeur de formulaires lourd, un plugin de statistiques qui écrit en base à chaque visite, trois plugins qui font la même chose… Chacun ajoute ses fichiers CSS et JavaScript sur toutes les pages, même celles où il ne sert à rien. J'ai écrit une liste des plugins à garder et de ceux à bannir.

5. Un thème « à tout faire »

Les thèmes multi-usages vendus sur les places de marché embarquent des dizaines de fonctionnalités dont vous utilisez 5 %. Résultat : 40 à 80 fichiers chargés sur chaque page, un constructeur de pages intégré, des polices et des bibliothèques en double. C'est la cause la plus difficile à corriger sans changer de thème.

6. Les scripts tiers

Google Tag Manager avec quinze balises, un widget de chat, le pixel Facebook, une carte Google Maps intégrée, des vidéos YouTube en direct, des polices Google chargées depuis leurs serveurs, un bandeau cookies lourd… Chacun pris isolément est raisonnable ; ensemble, ils peuvent bloquer l'affichage pendant deux secondes. Et vous n'avez aucun contrôle sur leur vitesse.

7. Une base de données encombrée

Des milliers de révisions d'articles, des transients expirés jamais nettoyés, des tables laissées par des plugins désinstallés il y a cinq ans, et surtout une table wp_options dont les données chargées automatiquement (autoload) dépassent 1 Mo : WordPress les lit à chaque page. Sur un site de dix ans, c'est systématique.

8. Pas de CDN ni de compression

Sans compression (Gzip ou Brotli), le HTML, le CSS et le JavaScript voyagent trois à quatre fois plus lourds que nécessaire. Sans CDN, un visiteur à Marseille attend que les fichiers viennent d'un serveur en Allemagne. Cloudflare en version gratuite règle les deux en une heure.

9. PHP obsolète et absence de cache objet

Passer de PHP 7.4 à PHP 8.3 accélère l'exécution de 20 à 40 % sans toucher au site. Et sur une boutique WooCommerce, où le cache de page ne peut pas tout couvrir (panier, compte client), un cache objet comme Redis change la donne sur le temps de réponse serveur.

La méthode d'optimisation, dans le bon ordre

L'ordre a de l'importance : traiter les images avant d'avoir réglé l'hébergement, c'est repeindre une maison dont le toit fuit.

1. Mesurer et sauvegarder. Captures des scores PageSpeed et GTmetrix avant intervention, sauvegarde complète. On ne touche à rien sans filet.
2. Serveur d'abord : PHP 8.x, hébergeur correct si le TTFB dépasse 0,8 s, HTTP/2 ou HTTP/3 activé.
3. Cache de page : WP Rocket (payant, le plus simple) ou LiteSpeed Cache (gratuit si le serveur est LiteSpeed). Un seul.
4. Images : conversion en WebP, redimensionnement à la taille réellement affichée, dimensions déclarées, chargement différé sauf pour l'image principale du haut de page (qui, elle, doit être préchargée).
5. Audit des plugins avec Query Monitor : suppression de ce qui est inutile, remplacement des plugins lourds, chargement conditionnel des autres.
6. Scripts tiers : polices hébergées sur votre serveur, exécution différée du JavaScript non essentiel, façade cliquable pour YouTube et Google Maps, allègement de Tag Manager.
7. Base de données : nettoyage des révisions et transients, suppression des tables orphelines, correction des options en autoload.
8. CDN et compression : Cloudflare, Brotli, en-têtes de cache navigateur longs.
9. Re-mesurer, page par page, sur mobile. Et conserver un relevé mensuel : la performance se dégrade avec le temps si personne ne surveille.

Ce qui ne sert à rien (ou aggrave le problème)

• Empiler les plugins d'optimisation. Deux plugins de cache se marchent dessus ; trois plugins d'images, idem. Un seul outil par fonction.
• Activer toutes les options « d'optimisation ». La minification et la combinaison agressives du CSS et du JavaScript cassent régulièrement l'affichage ou les formulaires, pour un gain marginal avec HTTP/2.
• Courir après le 100/100. Les derniers points coûtent des heures et n'apportent rien à vos visiteurs. Un 90 stable vaut mieux qu'un 100 fragile.
• Changer de thème sans diagnostic. Si le problème est l'hébergement ou les images, vous aurez dépensé pour rien.
• Différer le chargement de l'image principale. Le lazy loading sur l'image du haut de page retarde le LCP au lieu de l'améliorer — erreur très courante des plugins automatiques.
• Désactiver les mises à jour « pour ne pas casser la perf ». Vous échangez un problème de vitesse contre un problème de sécurité.

Combien coûte une optimisation de performance ?

Le retour sur investissement est facile à calculer si vous faites de la publicité : un site deux fois plus rapide convertit sensiblement mieux les mêmes clics, donc chaque euro de budget Google Ads rapporte davantage. Et sans publicité, c'est votre référencement naturel qui en profite.

Quand la refonte est la seule vraie solution

Il y a des cas où optimiser revient à mettre des rustines sur un pneu à plat :

• Le thème ou le constructeur de pages est si lourd que même optimisé, le site plafonne à 50-60 en mobile.
• Le site tourne sur une version de PHP que le thème empêche de mettre à jour.
• Le code a été modifié par cinq prestataires successifs et plus personne ne sait ce qui fait quoi.
• Le design date de 2016 et le problème de vitesse n'est qu'un symptôme parmi d'autres.

Dans ces cas, une refonte sur un thème léger construit avec l'éditeur natif de WordPress est plus rentable que des journées d'optimisation. À condition de la faire sans perdre le référencement acquis — ce qui est un sujet à part entière.

Questions fréquentes