Skip to Content
WordPressPartie 11 — Niveau expertPerformance & caching

Chapitre 11.2 — Performance & caching

⏱️ TL;DR — La performance WordPress se joue sur plusieurs couches de cache : page cache (HTML complet servi sans PHP), object cache persistant (Redis/Memcached — réutilise les requêtes entre requêtes), OPcache (bytecode PHP), CDN (assets/images). Plus l’optimisation des requêtes (éviter le N+1, autoload maîtrisé) et des images (formats modernes, tailles). Règle d’or : mesurer avant d’optimiser (Query Monitor, profilage) — on optimise le vrai goulot, pas au hasard.

🎯 Objectifs

  • Connaître les couches de cache et leur rôle.
  • Mettre en place un object cache persistant (Redis).
  • Optimiser requêtes, options (autoload) et images.
  • Mesurer avant/après (méthode).

1. Mesurer d’abord

On n’optimise pas à l’aveugle. Outils :

  • Query Monitor (ch. 4.5) : requêtes SQL (nombre, lentes, doublons/N+1), temps, mémoire, hooks, HTTP.
  • Profilage (Xdebug profiler, New Relic, Blackfire) pour le vrai chemin critique.
  • Métriques front (Core Web Vitals : LCP, CLS, INP) via Lighthouse/PageSpeed.

⚠️ Piège — optimiser au hasard. Installer 3 plugins de cache « pour aller plus vite » sans mesurer peut empirer (conflits, cache mal invalidé). Mesurez, trouvez le vrai goulot (souvent : requêtes lentes, autoload gonflé, images lourdes, appels HTTP bloquants), corrigez-le, re-mesurez.

2. Les couches de cache

CoucheCe qu’elle éviteOutil
Page cacheRegénérer tout le HTML (PHP+SQL) à chaque visitePlugin (WP Super Cache, W3TC…) ou cache serveur (Nginx FastCGI, Varnish) ou hébergeur managé
Object cache persistantRefaire les mêmes requêtes SQL/calculs entre requêtesRedis/Memcached + object-cache.php
OPcacheRecompiler le PHP à chaque requêteOPcache (PHP, activé côté serveur)
CDNServir assets/images depuis l’origineCloudflare, BunnyCDN…
Transients (ch. 5.7)Recalculer un résultat coûteux (applicatif)API transients (idéalement sur Redis)

Le page cache donne le plus gros gain sur des pages anonymes (identiques pour tous). L’object cache aide les pages dynamiques/connectées (admin, WooCommerce) où le page cache ne s’applique pas.

3. Object cache persistant (Redis)

Par défaut, l’object cache de WordPress ne dure qu’une requête (ch. 5.7). Brancher Redis (via un plugin object-cache.php) le rend persistant entre requêtes :

  • les résultats de WP_Query, métadonnées, options, transients survivent → moins de SQL.
  • gain majeur sur les sites dynamiques (WooCommerce, sites connectés) et à fort trafic.

C’est souvent l’optimisation la plus rentable après le page cache, surtout sur du e-commerce.

4. Optimiser les requêtes et l’autoload

  • N+1 (ch. 5.5) : une requête par élément dans une boucle → jointures/_embed/préchargement. Query Monitor révèle les doublons.
  • autoload gonflé (ch. 4.6/5.7) : des options volumineuses chargées à chaque requête. Auditer :
wp option list --autoload=on --fields=option_name,size_bytes --format=table | sort

Repérer les grosses options autoloadées inutiles (souvent laissées par des plugins désinstallés) et les nettoyer/passer en autoload='no'.

  • posts_per_page => -1 (ch. 5.5) : bannir sur de gros volumes.
  • Appels HTTP externes bloquants (API tierces) : mettre en cache (transient) et rendre non bloquant si possible.

5. Images et assets

  • Images : redimensionner/compresser avant upload (ch. 2.3), servir des formats modernes (WebP/AVIF), lazy-loading (natif), srcset (natif).
  • Assets : minifier/combiner CSS/JS avec prudence (ne pas casser les dépendances), différer le JS non critique, précharger les ressources critiques.
  • Ne charger que le nécessaire : enqueue conditionnel (ch. 6.4), éviter les plugins qui chargent leurs assets partout.
  • CDN pour les assets statiques et les images.

💡 Pour un dev React — Les principes vous parlent : cache à plusieurs niveaux (page = CDN/edge, object = Redis, transients = SWR applicatif), mesurer les Web Vitals, optimiser les images, code-splitting/défer du JS. La spécificité WordPress : beaucoup de lenteur vient des plugins (assets chargés partout, requêtes N+1, autoload). Un audit de perf (mesure → correctifs → preuve chiffrée) est une prestation nette et valorisée (Partie 13). Souvent, page cache + Redis + images optimisées + moins de plugins suffisent à transformer un site.

✏️ Exercices

  1. Quelle couche de cache aide le plus un site e-commerce connecté (où le page cache ne s’applique pas), et pourquoi ?
  2. Comment repérer une option qui plombe chaque requête ?
  3. Un site est lent ; on vous propose d’installer 3 plugins de cache. Que faites-vous d’abord ?

✅ Solution

  1. L’object cache persistant (Redis) : sur les pages dynamiques/connectées (panier, compte, admin WooCommerce), le page cache ne peut pas servir un HTML identique à tous ; Redis réduit le SQL en réutilisant requêtes/objets entre requêtes.
  2. Auditer l’autoload : wp option list --autoload=on (par taille) pour repérer les grosses options chargées à chaque requête (souvent des résidus de plugins désinstallés) et les nettoyer.
  3. Mesurer d’abord (Query Monitor, profilage, Web Vitals) pour identifier le vrai goulot, puis corriger cette cause précise et re-mesurer — plutôt qu’empiler des plugins de cache à l’aveugle (risque de conflits/invalidation).

🧠 Quiz de révision

1. Quelle est la règle d’or de l’optimisation ?

Mesurer avant d’optimiser (et re-mesurer après), pour corriger le vrai goulot.

2. Que fait un page cache ?

Il sert le HTML complet sans réexécuter PHP/SQL (gros gain sur les pages anonymes).

3. Qu’apporte un object cache persistant (Redis) ?

Il réutilise requêtes/objets entre requêtes → moins de SQL, utile sur les pages dynamiques/connectées.

4. Comment révéler les requêtes N+1 ?

Avec Query Monitor (requêtes dupliquées/lentes par page).

5. Première cause fréquente de lenteur applicative ?

Les plugins (assets chargés partout, N+1, autoload gonflé) et les images lourdes.

Chapitre suivant : Tests (PHPUnit, Jest, e2e).

Sécurité & hardeningTests (PHPUnit, Jest, e2e)