Guide pour optimiser le temps de chargement de votre site WordPress

Le jour où j'ai découvert que mon site WordPress mettait 6,8 secondes à s'afficher

Un soir, vers 23h, je regardais les logs d'un de mes sites. Pas par plaisir : un lecteur venait de m'écrire pour me dire que la page d'accueil « ne se chargeait jamais » sur son téléphone. J'ai lancé le test sur mon propre mobile en 4G. 6,8 secondes.

Je savais que c'était mauvais. Je ne savais pas à quel point. Et surtout, je n'avais aucune idée d'où venait le problème — un site que je trouvais « rapide » sur mon ordinateur branché en fibre ressemblait à une catastrophe dès qu'on le sortait de mon bureau.

Cet article raconte comment j'ai optimisé le temps de chargement de ce site WordPress, quelles erreurs j'ai commises, et ce qu'il faut vraiment regarder quand on veut aller vite. Pas de magie. Juste une méthode ordonnée, des chiffres et des outils.

Diagnostiquer avant de toucher à quoi que ce soit

Mon premier réflexe a été d'installer un plugin de cache. Erreur classique. J'ai gagné 400 millisecondes, soit rien. Le vrai souci était ailleurs, et je ne l'aurais jamais vu sans mesure.

Avec quels outils mesurer honnêtement

Il existe des dizaines d'outils. Trois suffisent largement pour couvrir le spectre.

• PageSpeed Insights — donne les Core Web Vitals (LCP, CLS, INP) sur données de terrain, pas seulement en labo.
• GTmetrix — pratique pour comparer avant/après avec un historique propre.
• Query Monitor, côté WordPress — un plugin de développement qui liste les requêtes SQL lentes, les appels HTTP externes, les scripts chargés.

Query Monitor a été la révélation. Sur ma page d'accueil, 214 requêtes SQL s'exécutaient à chaque affichage. La plupart venaient de trois plugins que j'avais installés « pour voir » et jamais désactivés. Aucun test PageSpeed ne m'aurait dit ça.

Repérer les goulots d'étranglement réels

Un site WordPress lent a presque toujours l'un de ces cinq problèmes. Les voici, par ordre de fréquence dans mon expérience :

1. Des images envoyées telles quelles depuis un appareil photo ou un téléphone (2 à 5 Mo par fichier).
2. Des plugins en surnombre, dont la moitié ne sert à rien.
3. Une base de données pleine de révisions, de transients expirés et de tables orphelines.
4. Un hébergement mutualisé bas de gamme avec un TTFB (Time To First Byte) supérieur à 800 ms.
5. Un thème lourd qui charge 4 sliders dont vous n'utilisez que le premier.

Le TTFB est le point que la plupart des guides oublient. Si votre serveur met 900 ms à répondre, aucun plugin côté navigateur ne vous sauvera. C'est un plafond de verre.

Optimiser les images : le gain le plus rapide

Rien de spectaculaire, désolé. Mais sur mon site, la seule optimisation des images a fait passer le LCP de 4,1 s à 2,3 s. En une soirée.

Quels formats et quel poids viser

Le WebP est aujourd'hui supporté partout. Il faut y passer. L'AVIF commence à devenir intéressant sur les images très compressibles, mais le support navigateur reste inégal sur les vieux terminaux Android — j'ai eu des surprises.

Mes cibles concrètes :

• Images d'illustration dans un article : moins de 100 ko.
• Images de héros ou bannières : moins de 200 ko.
• Vignettes et logos : moins de 30 ko.

Concrètement, j'utilise deux outils : ShortPixel pour la compression automatique à l'upload, et Squoosh (outil web de Google) pour les cas particuliers où je veux ajuster à la main. Le second est gratuit et vraiment pratique pour tester plusieurs ratios côte à côte.

Le lazy loading natif de WordPress

WordPress applique du lazy loading natif depuis la version 5.5, avec une exception : l'image du premier écran ne doit pas être en lazy, sinon vous dégradez votre LCP au lieu de l'améliorer. C'est un piège classique et beaucoup de plugins de cache le corrigent mal. Vérifiez le code source de votre page d'accueil : si l'image principale porte loading="lazy", il faut la retirer du lazy loading.

Cache, OPcache et base de données : la couche invisible

Le cache de page est utile, mais ce n'est qu'un étage de l'immeuble. Trois niveaux cohabitent dans WordPress, et il faut les traiter dans l'ordre.

Cache de page, cache objet, OPcache : ne pas confondre

Le cache de page stocke le HTML final. C'est ce que font WP Rocket, LiteSpeed Cache ou WP Super Cache. Indispensable.

Le cache objet persistant (Redis ou Memcached) stocke les résultats de requêtes SQL répétées. Sur un site avec beaucoup de visiteurs connectés ou un WooCommerce, c'est souvent la différence entre 300 ms et 1,2 s de temps de réponse serveur. Sur mon site, activer Redis a divisé le nombre de requêtes SQL par page de 214 à 47.

L'OPcache PHP, enfin, est un cache de bytecode côté serveur. La plupart des hébergeurs corrects l'activent par défaut. Si vous êtes sur du mutualisé bas de gamme, vérifiez — c'est parfois désactivé pour économiser de la RAM.

Nettoyer la base de données sans casser le site

Avant de supprimer quoi que ce soit : sauvegardez la base. Vraiment. Pas « je ferai ça demain ».

Ce qu'on peut nettoyer sans risque :

• Les révisions de billets (WordPress en garde une par défaut, ce qui suffit largement).
• Les transients expirés — accumulateurs chroniques.
• Les commentaires en spam.
• Les tables laissées par des plugins désinstallés.

Sur mon site de 8 ans avec 340 articles, ce nettoyage a fait passer la base de 68 Mo à 19 Mo. Le gain direct sur le temps de réponse serveur était modeste (200 ms environ) mais l'effet sur les sauvegardes quotidiennes, lui, a été immédiat.

Hébergement et pile serveur : là où ça se décide

Franchement, si vous êtes sur un mutualisé à 3 €/mois avec 500 sites sur la même machine, arrêtez d'optimiser. Vous vous battez contre la mauvaise personne.

PHP 8.x, HTTP/2, CDN : le socle minimal en 2026

Trois choses à vérifier auprès de votre hébergeur :

Élément	Cible acceptable	Impact principal
Version PHP	8.2 ou 8.3	Vitesse d'exécution, cache OPcache
Protocole HTTP	HTTP/2 minimum, HTTP/3 idéal	Chargement parallèle des ressources
Serveur web	LiteSpeed ou Nginx (pas Apache seul)	TTFB, gestion des connexions
CDN	Cloudflare ou BunnyCDN	Latence pour visiteurs hors zone
Cache objet	Redis disponible	Requêtes SQL répétées

J'ai migré mon site d'un mutualisé français vers un hébergeur LiteSpeed avec Redis, pour environ 12 €/mois. Le TTFB est passé de 870 ms à 210 ms. Aucun plugin n'aurait pu produire ce résultat. Les plugins optimisent ce qui passe après la réponse serveur. Ils ne peuvent rien contre un serveur lent.

Minification CSS/JS et plugins superflus

Ici, la règle est simple : moins de plugins, mieux configurés. J'ai vu des sites avec trois plugins de cache qui se battaient entre eux. Le résultat était pire que sans aucun.

Ce que je fais systématiquement :

• Un seul plugin de cache (LiteSpeed Cache si l'hébergeur est LiteSpeed, sinon WP Rocket).
• Minification CSS et JS activée, mais testée visuellement — la minification casse parfois un menu ou un slider.
• Suppression du jQuery inutile quand le thème ne l'utilise pas.
• Chargement différé des scripts non critiques (commentaires, widgets sociaux).

Attention aux plugins qui promettent de « tout optimiser » en un clic. J'ai cassé un site client en activant la minification automatique d'un plugin réputé, sans avoir testé sur une préproduction. Deux heures de restauration. Leçon apprise.

Mesurer, vérifier, itérer

Après toutes ces étapes, où en était mon site ?

• LCP mobile : 6,8 s → 1,9 s.
• TTFB : 870 ms → 210 ms.
• Requêtes SQL par page d'accueil : 214 → 47.