WordPress lent : comment le rendre rapide sans tout refaire en 2026

Un WordPress lent se répare dans 80% des cas sans toucher au thème ni migrer vers une autre stack. L’ordre qui fonctionne chez mes clients est toujours le même : hébergement et version PHP d’abord, cache ensuite, plugins et images en troisième position, base de données en dernier. Fait dans cet ordre, je fais passer un site de 40-50 sur Lighthouse mobile à 85-92 en deux à trois jours de travail, sans refonte.

WordPress fait encore tourner 41,9% des sites du web selon W3Techs en mai 2026, en léger recul face aux générateurs statiques et aux sites sans CMS détectable. La majorité de ces sites tournent lentement pour les cinq mêmes raisons, dans le même ordre de fréquence. Voici comment je les corrige chez mes clients, avec les chiffres exacts et un cas réel que je suis en train de traiter.

Le diagnostic qui évite de perdre une semaine sur le mauvais problème

Avant de toucher à quoi que ce soit, je mesure trois chiffres : le TTFB (time to first byte), le nombre de requêtes HTTP par page, et le poids total transféré. Sans ça, on optimise à l’aveugle et on perd du temps sur un problème qui n’en est pas un.

J’installe systématiquement Query Monitor, un plugin gratuit qui affiche en direct les requêtes SQL lentes, les hooks qui traînent et les plugins responsables. C’est ce plugin qui m’a montré, en juin 2026 sur le site de Julien, chauffeur VTC parisien (taxijulien.com), que 60% du temps de rendu venait de trois requêtes de base de données lancées par un plugin de réservation abandonné depuis deux ans.

État initial de taxijulien.com quand je l’ai repris : TTFB à 720 ms, LCP mobile à 3,9 secondes, neuf plugins actifs, thème Elementor avec 380 Ko de CSS par page. Rien d’extraordinaire, c’est le profil que je croise sur la moitié des audits que je fais pour des indépendants et petites PME en Île-de-France.

L’hébergement et PHP : la fondation qu’on court-circuite toujours

Le premier levier n’est ni un plugin ni un réglage, c’est la version de PHP. Make WordPress Core a publié en mai 2026 sa clarification de printemps sur le support PHP : la version minimale recommandée reste PHP 8.3, et WordPress 6.9 comme 7.0 (sorti en avril 2026) documentent désormais un support complet jusqu’à PHP 8.5. Chaque version de PHP entre 7.4 et 8.3 apporte des gains de performance mesurables sur le moteur Zend, avant même de toucher au code du site.

Sur taxijulien.com, l’hébergeur mutualisé faisait tourner PHP 8.0 par défaut. Un changement de version dans le panneau d’administration de l’hébergeur, sans redéploiement ni ligne de code modifiée, a fait passer le TTFB de 720 à 480 ms. C’est le gain le plus rentable de tout l’audit : zéro euro, zéro risque, dix minutes de travail.

Deuxième point sur l’hébergement : un mutualisé à 3 ou 5 euros par mois partage ses ressources CPU avec des centaines d’autres sites sur la même machine. Je ne migre pas systématiquement mes clients vers un hébergement infogéré premium, mais je vérifie toujours si l’offre actuelle propose LiteSpeed Web Server plutôt qu’Apache ou Nginx nu : LiteSpeed apporte un gain de traitement PHP notable et débloque la version gratuite de LiteSpeed Cache, contrairement à Apache qui oblige à passer par un plugin payant pour un niveau de cache équivalent.

Le cache : le levier qui rapporte le plus en une heure de travail

Une fois l’hébergement et PHP réglés, le cache est le geste qui rapporte le plus vite. Trois couches de cache existent, et elles ne résolvent pas le même problème :

Type de cache	Ce qu’il résout	Outil que j’utilise	Coût typique
Cache de page (HTML)	Régénération de la page à chaque visite	LiteSpeed Cache (si serveur compatible)	Gratuit
Cache d’objet (requêtes DB)	Requêtes SQL répétées à chaque chargement	Redis via LiteSpeed Cache ou WP Rocket	Gratuit à 10€/mois
Cache de contenu statique (CDN)	Latence géographique pour images/CSS/JS	Cloudflare (plan gratuit)	Gratuit

LiteSpeed Cache dépasse aujourd’hui 7 millions d’installations actives sur WordPress.org, ce qui en fait le plugin de cache le plus utilisé de l’écosystème, et il est gratuit dès lors que l’hébergeur tourne sous LiteSpeed Web Server. Quand ce n’est pas le cas, WP Rocket reste mon choix par défaut malgré son prix (59 dollars par an pour une licence single, environ 55 euros) parce que sa configuration par défaut ne casse quasiment jamais un site WooCommerce ou un formulaire dynamique, contrairement à des plugins gratuits mal maintenus.

Sur taxijulien.com, l’activation du cache de page seul (sans toucher au cache d’objet) a fait tomber le TTFB de 480 à 210 ms sur les pages non connectées. Le cache d’objet Redis, activé une semaine plus tard une fois le plugin de réservation défaillant supprimé, a réduit le temps de génération des pages avec formulaire de réservation de 900 ms à 140 ms.

Les plugins : le poids mort qu’on n’audite jamais

Dans ma pratique, le plugin qui casse la performance n’est presque jamais celui qu’on soupçonne. C’est rarement le plugin de sécurité ou de SEO, toujours bien identifiés et souvent bien codés. Ce sont les plugins installés pour une fonctionnalité ponctuelle, jamais retirés, qui continuent de charger leur JavaScript et d’exécuter leurs hooks sur chaque page, y compris celles où ils ne servent à rien.

Sur les neuf plugins actifs de taxijulien.com, j’en ai désactivé quatre : un plugin de popup jamais réellement utilisé, un second gestionnaire de formulaires en doublon avec Contact Form 7 déjà en place, un plugin d’A/B testing abandonné, et le plugin de réservation défaillant repéré par Query Monitor. Résultat : 34 requêtes HTTP en moins par page, et le nombre de hooks WordPress exécutés à chaque chargement a chuté de 340 à 190 selon Query Monitor.

La règle que j’applique chez mes clients : un plugin qui n’a pas reçu de mise à jour depuis plus de dix-huit mois est un candidat direct à la suppression, sauf preuve du contraire. Et deux plugins qui font la même chose (deux plugins de formulaire, deux plugins de cache, deux plugins de sécurité) ne doivent jamais cohabiter, autant pour la performance que pour la sécurité.

Les images et le JavaScript qu’on charge sans réfléchir

Après le cache et les plugins, l’image hero non optimisée reste la cause la plus fréquente d’un mauvais LCP. Sur taxijulien.com, l’image de fond de la page d’accueil pesait 1,4 Mo en JPEG. Une conversion en WebP avec un plugin de compression d’image (Imagify ou ShortPixel selon les cas) l’a fait descendre à 140 Ko sans perte visible, ce qui a fait gagner 1,1 seconde sur le LCP mobile mesuré via PageSpeed Insights.

Trois réglages suffisent la plupart du temps : conversion automatique en WebP ou AVIF à l’upload, chargement différé (loading="lazy") pour toutes les images sous la ligne de flottaison, et dimensions explicites en width et height pour éviter le décalage visuel que mesure le CLS. Pour le JavaScript, je passe systématiquement les scripts non critiques (widgets tiers, chat, analytics) en chargement différé via l’option correspondante dans LiteSpeed Cache ou Autoptimize, ce qui libère le thread principal plus tôt et améliore l’INP.

Le seuil que je vise reste celui des Core Web Vitals sur le terrain : LCP sous 2,5 secondes, INP sous 200 millisecondes, selon les définitions officielles de web.dev. Sur taxijulien.com après ces trois réglages, le LCP mobile mesuré est passé de 3,9 à 1,8 seconde. Ce n’est pas le 1,2 seconde que je tiens sur mes livraisons Astro, mais c’est largement dans la zone verte de Google.

Le CDN et la base de données : le dernier kilomètre

Le CDN gratuit de Cloudflare distribue les fichiers statiques (images, CSS, JS) depuis plus de 330 centres de données selon la documentation officielle du plan gratuit, ce qui réduit la latence pour les visiteurs hors de la région où est hébergé le site. Le plan gratuit limite les règles de cache personnalisées à trois, ce qui suffit largement pour un site vitrine ou un site métier : une règle pour les assets statiques, une pour exclure les pages de compte et de panier, une de secours.

Dernier poste, souvent négligé : la base de données elle-même. Une table wp_options qui grossit avec des entrées orphelines laissées par des plugins désinstallés ralentit chaque requête, même avec du cache actif. Un nettoyage via WP-Optimize (suppression des révisions d’articles au-delà de trois versions, purge des transients expirés, des commentaires en spam) fait généralement gagner 30 à 80 millisecondes de traitement serveur sur un site qui tourne depuis plus de deux ans sans entretien.

Cinq leviers, dans l’ordre : PHP et hébergement, cache à trois couches, audit des plugins, images et JS différé, CDN et base de données. Sur taxijulien.com, l’ensemble a fait passer le score Lighthouse mobile de 44 à 89 en trois jours de travail facturés 1 400 euros HT, sans toucher au thème ni au design. C’est la réponse directe à qui me demande s’il faut tout refaire : non, sauf si le plafond de verre est architectural. Si après ces cinq étapes le TTFB reste au-dessus de 500 ms malgré un bon hébergeur et PHP 8.3, ou si le thème repose sur un page builder qui régénère 300 Ko de CSS incompressible par page, alors le problème n’est plus un réglage, c’est la stack elle-même, et une migration vers une architecture comme Astro devient plus rentable qu’une heure de tuning supplémentaire.

Ce qu’il faut retenir

• WordPress se répare dans 80% des cas sans refonte : PHP et hébergement d’abord, cache ensuite, plugins et images en troisième position, base de données en dernier
• La version PHP recommandée en 2026 est 8.3 minimum selon Make WordPress Core, avec support documenté jusqu’à 8.5 sur WordPress 7.0
• Un seul plugin de cache à la fois : LiteSpeed Cache (gratuit, 7 millions d’installations actives) si l’hébergeur le permet, WP Rocket sinon
• Un plugin sans mise à jour depuis 18 mois est un candidat direct à la suppression, surtout s’il fait doublon avec un autre
• Les images non optimisées restent la cause la plus fréquente d’un mauvais LCP : conversion WebP/AVIF et lazy loading suffisent dans la majorité des cas
• Sur taxijulien.com, ces cinq leviers ont fait passer le Lighthouse mobile de 44 à 89 en trois jours, facturés 1 400 euros HT
• La migration vers une stack statique ne devient la bonne réponse que si le TTFB reste haut malgré un hébergeur correct, ou si le thème génère un poids de CSS incompressible