Performance WordPress : votre site est lent, trouvez la cause avant de toucher à quoi que ce soit

WordPress lent, que faire dans les cinq premières minutes

Avant d'ouvrir l'administration, deux mesures, qui disent si le temps se perd sur le serveur ou dans le navigateur.

# 1. La page telle que la reçoit un visiteur (cache compris)
curl -o /dev/null -s -w "TTFB : %{time_starttransfer} s\n" https://votre-site.fr/

# 2. La même page avec un paramètre jamais vu : la plupart des caches de page
#    la considèrent comme une nouvelle adresse et laissent PHP la fabriquer
curl -o /dev/null -s -w "TTFB : %{time_starttransfer} s\n" "https://votre-site.fr/?diag=48213"

Lancez chaque commande trois fois et gardez la valeur médiane, en changeant le nombre du paramètre à chaque essai. Trois lectures possibles :

• Les deux passent sous 600 ms, le seuil de Santé du site présenté plus bas. Le serveur n'est pas en cause : la lenteur ressentie vient du poids de la page ou du JavaScript, passez directement aux images et aux scripts.
• La première est rapide, la seconde lente. Le cache fait son travail et masque une génération PHP coûteuse. Le visiteur anonyme est servi vite, mais l'administration, le panier WooCommerce et les pages non encore en cache rament. La cause est dans les extensions ou la base de données.
• Les deux sont lentes. Soit il n'y a pas de cache de page, soit il ne répond pas pour cette adresse. Commencez par là, c'est la correction au meilleur rapport effort/résultat de toute la page.

Dans un navigateur, l'onglet Réseau affiche la même mesure : document HTML, section Timing, ligne Waiting for server response.

Ce que le scan gratuit montre, et ce qu'il ne mesure pas

Le résultat gratuit affiche le score global, les six sous-scores, le temps de réponse, le poids du HTML et les cinq corrections les plus graves avec la valeur mesurée. Pour LCP, INP et CLS, voyez le guide Core Web Vitals WordPress.

1. Le serveur : le temps avant le premier octet

Le symptôme. Toutes les pages mettent le même temps à « démarrer », quelle que soit leur taille, et l'administration est lente elle aussi. La seconde commande curl ci-dessus dépasse la seconde.

Les seuils. Google considère un TTFB comme bon à 0,8 s ou moins et mauvais au-delà de 1,8 s, mesuré au 75^e centile des visiteurs (web.dev). WordPress est plus exigeant : depuis la version 6.1, l'outil Santé du site considère un temps de réponse comme bon sous 600 ms (developer.wordpress.org). Notre moteur reprend ce seuil de 600 ms.

Ce que le scan en montre. Une mesure unique depuis notre serveur, DNS, connexion chiffrée et redirections comprises : analysez l'URL finale plutôt qu'une adresse qui redirige, et relancez avant de conclure sur un pic.

Les gestes, du moins cher au plus cher :

1. La version de PHP. Outils › Santé du site › Informations › Serveur l'affiche. WordPress recommande PHP 8.3 ou plus (wordpress.org), et PHP 8.2 ne reçoit plus de correctifs de sécurité après le 31 décembre 2026 (php.net). Le changement se fait dans le panneau de l'hébergeur. Testez d'abord sur une copie du site si vous avez de vieilles extensions : c'est avec elles que les montées de version cassent.
2. OPcache, qui garde le code PHP compilé en mémoire. Il est actif chez la plupart des hébergeurs sérieux ; posez la question au support plutôt que de publier un phpinfo.php.
3. Trouver ce qui coûte. Query Monitor, sur une page lente et en étant connecté, classe les requêtes SQL par extension ou thème, signale les lentes et liste les appels HTTP sortants. Le cas que je rencontre le plus souvent : une extension qui interroge une API externe à chaque page (flux Instagram, compteur de partages, contrôle de licence).
4. Un cache d'objets persistant si l'hébergement propose Redis : Redis Object Cache garde en mémoire les résultats de requêtes, ce qui aide surtout ce qui échappe au cache de page (administration, boutique, membres connectés). Sans serveur Redis, elle ne sert à rien.

2. Le cache de page : présent n'est pas actif

Le symptôme. Les deux mesures curl donnent le même délai, élevé. Sans cache de page, WordPress exécute PHP et interroge la base de données à chaque visite pour reconstruire une page qui n'a pas changé depuis la veille.

Le vérifier vous-même. Une extension installée ne prouve pas qu'un cache répond ; les en-têtes, si :

curl -sI https://votre-site.fr/ | grep -iE "x-litespeed-cache|x-cache|cf-cache-status|x-proxy-cache|x-fastcgi-cache|^age:"

Lancez-la deux fois de suite. x-litespeed-cache: hit, x-cache: HIT ou un en-tête age qui augmente : la page sort du cache. cf-cache-status: DYNAMIC veut dire que Cloudflare transmet la page sans la garder, ce qui est son comportement par défaut pour le HTML. WP Rocket, lui, signe généralement les pages mises en cache par un commentaire en bas du code source.

Le geste. Un seul cache de page, choisi selon le serveur :

• Hébergement LiteSpeed : LiteSpeed Cache, gratuit. Son cache de page ne fonctionne qu'avec un serveur LiteSpeed ; ailleurs, il ne met rien en cache.
• Apache ou nginx : WP Rocket (payant) active le cache dès l'activation. En gratuit, WP Super Cache ou le module de cache de WP-Optimize.
• Hébergeur qui fournit son propre cache (Varnish, cache nginx) : n'ajoutez pas de cache de page par-dessus, deux caches qui se purgent chacun à leur rythme finissent par servir des pages périmées.

Sur une boutique, le panier, la commande et le compte client ne doivent jamais être mis en cache. WooCommerce signale ces pages aux extensions de cache, qui respectent ce signal ; une règle de cache serveur écrite à la main ne le connaît pas.

Ce que le scan en montre. wp_cache cherche une extension de cache chargée par la page (WP Rocket, LiteSpeed Cache, WP Super Cache, W3 Total Cache, WP Fastest Cache…), un en-tête de cache (LiteSpeed, Varnish, Cloudflare hors DYNAMIC, x-fastcgi-cache…) ou un commentaire HTML. Rien trouvé : fail, −15 dans la dimension WordPress. Un cache serveur muet ne se devine pas ; sur nginx, add_header X-FastCGI-Cache $upstream_cache_status; le rend visible, pour nous comme pour vous.

Deux lignes voisines. Sans gzip ni Brotli, compression coûte 18 points et se règle chez l'hébergeur. cache demande un Cache-Control d'au moins un jour sur la page HTML : sur un site qui publie souvent, un délai court reste un choix raisonnable, et ce warning ne vaut que 5 points. La durée longue, c'est pour les images, les CSS et les JS.

3. Les images : format, taille, et l'image du haut

Le symptôme. La page répond vite mais s'affiche par morceaux, surtout sur mobile. Dans les outils de développement, onglet Réseau filtré sur les images, la colonne Type affiche jpeg et png, et la colonne Taille des centaines de Ko pour des vignettes.

Ce que WordPress fait seul, et ce qu'il ne fait pas. WordPress accepte les images WebP depuis la version 5.8, mais ne convertit pas vos JPEG : il produit les tailles intermédiaires dans le format du fichier envoyé (make.wordpress.org). L'AVIF est accepté depuis la 6.5, à condition que la bibliothèque d'images du serveur le gère, ce que Santé du site › Informations › Gestion des médias vous dit (make.wordpress.org).

Les gestes.

• Pour les nouvelles images : l'extension Modern Image Formats, publiée par l'équipe Performance de WordPress, génère du WebP ou de l'AVIF à l'envoi. Elle ne touche pas aux images déjà en place tant qu'elles ne sont pas régénérées (wordpress.org).
• Pour la médiathèque existante : Imagify, ShortPixel ou le module d'images de WP-Optimize compressent et convertissent en masse. Réglez la compression, lancez l'optimisation groupée, laissez tourner.
• Pour l'image du haut de page : ne la chargez surtout pas en différé. Depuis la version 6.3, WordPress évite le chargement différé sur les images probablement visibles à l'ouverture et ajoute fetchpriority="high" à celle qu'il pense être la plus grande (make.wordpress.org). Mais une extension d'optimisation réglée sur « toutes les images » défait ce travail. Dans l'analyse publiée par Google sur des pages WordPress, la page médiane affichait un LCP (75^e centile) de 3 495 ms sans chargement différé, contre 3 768 ms avec (web.dev). Dans WP Rocket, l'option Optimize critical images exclut automatiquement l'image LCP et les images visibles à l'ouverture (documentation WP Rocket) ; ailleurs, renseignez le champ d'exclusion avec le nom du fichier ou la classe de l'image.
• Pour les dimensions : WordPress écrit width, height et srcset sur les images insérées par l'éditeur. Quand ils manquent, c'est un thème ou un constructeur qui écrit sa propre balise avec une URL brute : la page saute au chargement (voir le guide Core Web Vitals) et le mobile télécharge l'image pleine taille.

Ce que le scan en montre. Quatre vérifications, calculées sur les balises <img> de la page analysée :

Le moteur reconnaît le WebP par l'extension du fichier, par une source <picture> ou par les CDN d'images courants. Si votre extension sert le WebP par réécriture serveur en gardant l'URL en .jpg, aucun outil externe ne le voit dans le HTML : vérifiez la colonne Type du navigateur, ou passez l'extension en mode <picture>. Et le seuil de 60 % laisse toute la place d'exclure l'image du haut.

4. CSS, JavaScript et constructeurs de pages

Le symptôme. Écran blanc, puis tout apparaît d'un coup : ce sont des ressources qui bloquent l'affichage. Ou la page s'affiche mais un menu met une demi-seconde à s'ouvrir : c'est du JavaScript qui occupe le navigateur. Dans les deux cas, le chiffre qui tranche est dans PageSpeed Insights : le Total Blocking Time et la liste des ressources bloquantes. Notre scan ne mesure pas l'exécution du JavaScript ; il compte ce qui est déclaré dans le HTML.

Ce que le scan en montre.

Les gestes, dans cet ordre : retirer, puis décharger, puis différer.

1. Retirer. Quand la ligne third_party passe en warning, le rapport nomme les domaines. Chacun coûte une résolution DNS, une connexion et du temps d'exécution. Deux outils de mesure d'audience qui font la même chose, un outil de cartes de chaleur installé pour une étude finie depuis un an, un widget de discussion chargé sur toutes les pages : ce sont les gains les plus nets et les moins risqués de cette section.
2. Décharger page par page. Une extension de formulaire charge souvent son CSS et son JavaScript partout, alors que le formulaire n'est que sur la page Contact. Asset CleanUp (gratuit) ou Perfmatters (payant) affichent ce que chaque page charge et permettent de désactiver le reste.
3. Différer. Dans WP Rocket, onglet File Optimization : Delay JavaScript execution retarde les scripts jusqu'à la première interaction, Remove Unused CSS remplace les feuilles de style par le CSS réellement utilisé, injecté en ligne (documentation : JavaScript, CSS). Ce sont les réglages les plus efficaces et les plus susceptibles de casser le menu mobile, un slider ou le bandeau cookies : activez-les un par un et parcourez le site sur mobile. Le CSS injecté fait monter la ligne inline_css du rapport ; c'est un compromis connu, pas une régression.

Les constructeurs de pages. Elementor, Divi ou WPBakery produisent beaucoup de balises imbriquées et chargent leur propre CSS et JavaScript. Leurs options de chargement allégé méritent un essai sur une copie du site, mais un site entièrement bâti sur un constructeur lourd plafonne : en sortir est un chantier de refonte à planifier, pas un réglage du samedi.

Les petites lignes. Le script des émojis se retire avec remove_action( 'wp_head', 'print_emoji_detection_script', 7 );, les navigateurs actuels n'en ont pas besoin. Heartbeat côté visiteurs est presque toujours chargé par une extension : trouvez laquelle avant de le couper. Trois points chacune.

5. Les extensions : trouver la coupable sans tout casser

Le symptôme. La page forcée à passer par PHP reste lente, l'administration rame, et le problème est apparu après une installation ou une mise à jour.

Le nombre compte moins que le contenu. Trente extensions légères pèsent moins qu'une seule qui interroge une API à chaque page. Le scan compte les extensions visibles dans le HTML (wp_plugins : jusqu'à 8, pass ; 9 à 18, −8 ; 19 et plus, −15) et signale Jetpack, WPBakery, Slider Revolution, LayerSlider et Essential Grid (−3 chacune), ainsi que les thèmes Avada, Enfold, BeTheme, Bridge et The7 (−5). Il ne voit pas celles qui ne chargent rien côté visiteur, souvent les plus coûteuses côté serveur.

1. Query Monitor d'abord. Sur une page lente, les panneaux des requêtes par composant et des appels HTTP désignent souvent la coupable sans rien désactiver.
2. Sinon, par moitiés, sur une copie du site (la plupart des hébergeurs proposent une préproduction) : désactivez la moitié des extensions, mesurez avec la même commande curl, recommencez sur la moitié fautive. Pour une quarantaine d'extensions, six ou sept tours suffisent.
3. Remplacez ou supprimez. Désactiver ne suffit pas toujours : certaines laissent derrière elles des tâches planifiées et des options en base.

6. La base de données, quand le cache ne suffit pas

Le symptôme. Le cache de page est actif, mais l'administration, la recherche interne, le panier et toute page pas encore en cache restent lents. Aucun outil externe ne voit la base, notre scan non plus.

Les options chargées à chaque page. WordPress charge d'un bloc, à chaque requête, les options marquées pour le chargement automatique, et des extensions supprimées depuis longtemps y laissent parfois des centaines de Ko. Depuis la version 6.6, Santé du site signale un total supérieur à 800 Ko (make.wordpress.org). Pour mesurer en WP-CLI (adaptez le préfixe wp_ à votre installation) :

wp option list --autoload=on --format=total_bytes
wp db query "SELECT option_name, LENGTH(option_value) AS octets FROM wp_options WHERE autoload IN ('yes','on','auto-on','auto') ORDER BY octets DESC LIMIT 15;"

Une grosse option au nom d'une extension que vous n'utilisez plus se supprime, après sauvegarde, avec wp option delete nom_de_l_option. Celle d'une extension active ne se touche pas : c'est une question pour son support.

Révisions et transients. define( 'WP_POST_REVISIONS', 5 ); dans wp-config.php limite le nombre de révisions conservées par contenu (developer.wordpress.org) ; WP-Optimize nettoie les anciennes révisions et les transients expirés. Honnêtement, les révisions ralentissent rarement un site. Les options chargées à chaque page, souvent.

Les tâches planifiées. WP-Cron se déclenche pendant les visites. Sur un site qui en accumule, define( 'DISABLE_WP_CRON', true ); et une vraie tâche cron serveur qui appelle wp-cron.php à intervalle fixe lissent la charge ; protégez-la par un verrou (flock) pour que deux exécutions ne s'empilent pas. Le scan mentionne WP-Cron à titre d'information, sans pénalité, parce que ce réglage ne se lit pas de l'extérieur.

7. L'hébergement, en dernier

Changer d'hébergeur est le geste le plus cher, et celui qu'on fait trop tôt. Il se justifie quand les étapes précédentes sont faites et que les mesures le montrent :

• sur une copie du site, avec un thème par défaut et les extensions désactivées, la page forcée à passer par PHP reste lente ;
• le TTFB varie fortement selon l'heure de la journée, signe d'un serveur partagé saturé ;
• l'offre ne propose ni PHP récent, ni cache serveur, ni Redis.

Avant de migrer, demandez au support les limites de votre offre (processus PHP simultanés, mémoire) : une boutique qui bute sur ces limites ira souvent mieux avec l'offre supérieure du même hébergeur, sans déménagement. Et un CDN comme Cloudflare rapproche les fichiers statiques de vos visiteurs, mais n'accélère pas la fabrication des pages par PHP tant que le HTML lui-même n'est pas mis en cache.

Amélioration des performances WordPress : la matrice impact / effort

Un rapport rend souvent une quinzaine de lignes rouges ou orange. Les traiter dans l'ordre d'affichage, c'est passer un samedi sur des détails. Rangez-les dans quatre cases ; l'axe « effort » dépend de votre site, ajustez-le.

Après chaque correction, relancez l'analyse sur la même URL. Un réglage qui fait baisser le TTFB peut désactiver le chargement différé des images ; un différé de JavaScript peut casser le menu mobile. Une mesure avant, une mesure après, une correction à la fois.

Questions fréquentes