Optimisation performance hébergement WordPress

La réputation de WordPress d'être lent est méritée quand il est mal hébergé, mais un site WordPress correctement tuné peut servir des centaines de milliers de pageviews par jour depuis un VPS à 7-15 €/mois. La différence est dans la configuration, pas dans le budget.

La baseline d'hébergement

WordPress sur mutualisé sera lent quoi que vous fassiez — vous partagez CPU et I/O avec des centaines de sites. Passez sur un VPS :

Jusqu'à 10K pageviews/mois : 1 vCPU / 1 Go (Basic)
10-100K : 2 vCPU / 2 Go (Advanced)
100K-1M : 2 vCPU / 4 Go (Professional)

La stack : LEMP, pas LAMP

Apache fonctionne, mais Nginx + PHP-FPM (LEMP) surpasse systématiquement Apache + mod_php pour WordPress. Raison : Nginx est event-driven (un thread gère des milliers de connexions concurrentes), Apache spawn des processus par connexion.

Tuning PHP-FPM

Pour un VPS 2 Go dédié WordPress, éditez /etc/php/8.3/fpm/pool.d/www.conf :

pm = dynamic
pm.max_children = 25
pm.start_servers = 5
pm.min_spare_servers = 3
pm.max_spare_servers = 8
pm.max_requests = 500

Chaque enfant utilise 30-50 Mo. max_children × Mo doit tenir confortablement, en laissant de la place à MySQL et Nginx.

OPcache

OPcache cache le bytecode PHP compilé en mémoire, éliminant le coût de recompilation à chaque requête. Dans php.ini :

opcache.enable=1
opcache.memory_consumption=256
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=20000
opcache.validate_timestamps=0

Avec validate_timestamps=0 OPcache ne vérifie pas si les fichiers ont changé — le plus rapide, mais flushez manuellement après deploys.

Cache objet avec Redis

WordPress fait des centaines de queries DB par page. La plupart sont cachables :

sudo apt install redis-server php8.3-redis

Installez le plugin Redis Object Cache. Configurez via wp-config.php :

define('WP_REDIS_HOST', '127.0.0.1');
define('WP_REDIS_PORT', 6379);
define('WP_CACHE_KEY_SALT', 'votresite.com');

Le cache objet réduit typiquement le temps de génération de page de 40-70%. C'est la plus grosse optimisation pour les pages dynamiques.

Cache de page

Pour les visiteurs anonymes (la grande majorité du trafic), générez le HTML une fois et servez-le depuis le disque :

FastCGI cache (niveau Nginx) : performance maximale, bypass PHP entièrement
WP Super Cache ou W3 Total Cache : plugin, plus simple à configurer

Tuning base de données

Pour 2 Go de RAM, dans 50-server.cnf :

innodb_buffer_pool_size = 512M
innodb_log_file_size = 64M
innodb_flush_log_at_trx_commit = 2
innodb_flush_method = O_DIRECT
query_cache_type = 0

CDN

Les assets statiques (images, CSS, JS) doivent être servis depuis un CDN. Cloudflare Free est le défaut. Bunny.net est une alternative simple. Pour la souveraineté, KeyCDN et Bunny sont basés UE.

Optimisation images

Les images sont généralement le plus gros payload. Format WebP avec fallback JPEG. Plugins comme ShortPixel ou Imagify génèrent WebP automatiquement. Résultat : 30-60% de réduction de bytes sans perte visible de qualité.

Discipline plugins

Chaque plugin actif est un overhead potentiel. Audit trimestriel :

Désactivez ce que vous n'utilisez pas
Remplacez 3 plugins par 1 quand possible (Rank Math vs Yoast + redirect + breadcrumbs)
Surveillez les plugins qui chargent des assets sur toutes les pages

Mesure

Vous ne pouvez pas optimiser ce que vous ne mesurez pas :

Query Monitor : queries lentes, hooks par requête
Lighthouse : Core Web Vitals
WebPageTest : timing depuis diverses localisations

Cible : TTFB <200ms, LCP <2,5s, CLS <0,1.

WordPressPerformanceNginxPHP-FPMRedis