Comment optimiser WordPress faire face aux pics de trafic sur un serveur VPS ou dédié

Le problème, ce n'est pas le trafic en soi ; la question est de savoir si la configuration de ton serveur peut le gérer sans ralentir considérablement ou sans tomber complètement en panne.

Ce guide traite de la configuration côté serveur qui détermine la capacité de ton site à gérer les pics de trafic. L'optimisation côté client (compression d'images, minification) est utile, mais c'est ta pile serveur qui fixe la limite maximale de trafic que ton site peut gérer. C'est ce dont nous allons parler ici.

Pourquoi WordPress à gérer les pics de trafic (et comment y remédier)

WordPress les pages de manière dynamique. Par défaut, chaque requête d'un visiteur déclenche l'exécution d'un script PHP qui interroge la base de données, assemble la page et l'envoie au navigateur. Un site recevant 1 000 requêtes simultanées, ça veut dire 1 000 processus PHP en cours et 1 000 requêtes à la base de données qui se produisent en même temps.

La solution consiste à servir des pages pré-générées à partir du cache plutôt que de les générer à chaque requête. Une WordPress correctement mise en cache et servie depuis la mémoire ne consomme qu'une fraction des ressources CPU et d'E/S d'une requête dynamique non mise en cache. La différence en termes de capacité de traitement des requêtes simultanées n'est pas minime ; elle est d'un ordre de grandeur supérieur.

Mise en cache des pages côté serveur

Mise en cache pleine page avec le cache NGINX

Le cache FastCGI NGINXstocke des pages HTML complètes sur le serveur et les sert directement, en contournant complètement PHP et la base de données pour les pages mises en cache. C'est la couche de mise en cache la plus efficace pour résister aux pics de trafic.

Pour WordPress hébergés sur l'infrastructure de serveurs VPS gérés ou de serveurs dédiés InMotion Hostingutilisant NGINX , le cache FastCGI peut être configuré au niveau du serveur. La UltraStack disponible dans les formules VPS gérés d'InMotion inclut un proxy NGINX avec mise en cache intégrée, qui gère cela sans configuration manuelle.

Plugins de mise en cache WordPress

Pour les sites où la mise en cache NGINX n'est pas configurée, W3 Total Cache et WP Super Cache sont les principales options. W3 Total Cache aux configurations au niveau du serveur, notamment Redis et Memcached. WP Super Cache génère des fichiers HTML statiques qu'Apache ou NGINX directement. Les deux réduisent considérablement la fréquence d'exécution de PHP.

Pour les sites hébergés chez InMotion, W3 Total Cache le plugin recommandé, car il est compatible avec la pile serveur d'InMotion. Configure-le pour utiliser la mise en cache optimisée sur disque ou la mise en cache d'objets Redis, selon ta formule d'abonnement.

Mise en cache d'objets Redis

Redis est un magasin de données en mémoire capable de mettre en cache les résultats des requêtes WordPress , ce qui réduit le nombre de requêtes à chaque chargement de page. Pour les sites dont le contenu sollicite fortement la base de données (grands catalogues de produits, boutiques WooCommerce, sites avec une forte activité de sessions utilisateur), Redis permet une amélioration significative du débit.

Installer Redis sur un VPS Ubuntu :

sudo apt install redis-server

sudo apt install redis-server

Configure les paramètres de base de Redis dans /etc/redis/redis.conf :

maxmemory 256mbmaxmemory-policy allkeys-lru

maxmemory 256mbmaxmemory-policy allkeys-lru

La politique « allkeys-lru » supprime les clés les moins récemment utilisées lorsque la mémoire est pleine, ce qui correspond au comportement attendu pour une application de mise en cache.

Installe le plugin Redis Object Cache dans WordPress, puis configure le fichier wp-config.php :

define('WP_REDIS_HOST', '127.0.0.1');define('WP_REDIS_PORT', 6379);

define('WP_REDIS_HOST', '127.0.0.1');define('WP_REDIS_PORT', 6379);

Active le cache d'objets depuis le tableau de bord du plugin Redis Object Cache. Vérifie qu'il est bien actif et que la connexion est établie avant d'activer la mise en cache.

Optimisation du pool PHP-FPM pour les pics de trafic

PHP-FPM gère un pool de processus PHP. Lors d'un pic de trafic, le nombre de requêtes PHP simultanées peut dépasser le nombre de processus disponibles dans le pool, ce qui entraîne la mise en file d'attente ou l'expiration des nouvelles requêtes. Optimiser le pool avant les pics de trafic prévus, c'est ce qui fait la différence entre un site qui gère le pic et un site qui s'effondre sous son poids.

Modifie la configuration du pool PHP-FPM (généralement /etc/php/8.2/fpm/pool.d/www.conf) :

pm = dynamicpm.max_children = 50pm.start_servers = 10pm.min_spare_servers = 10pm.max_spare_servers = 30

pm = dynamicpm.max_children = 50pm.start_servers = 10pm.min_spare_servers = 10pm.max_spare_servers = 30

pm.max_children définit le nombre maximal de processus PHP. Chaque processus consomme de la mémoire. À titre indicatif : sur un serveur doté de 4 Go de RAM, si tu alloues 1,5 Go aux processus PHP (à raison d'environ 50 Mo par processus), tu obtiendras 30 processus. Adapte cette valeur en fonction de la consommation réelle de mémoire PHP de ton serveur.

Pour les événements générant un pic de trafic prévisible (lancements de produits, campagnes promotionnelles), augmente temporairement la valeur de `pm.max_children`, surveille l'utilisation de la mémoire pendant l'événement, puis réduis-la une fois celui-ci terminé.

Configuration de MySQL pour un site WordPress à forte charge

La base de données WordPressest le deuxième goulot d'étranglement le plus fréquent après PHP en cas de charge importante. Deux paramètres ont le plus d'impact.

Le paramètre `max_connections` détermine le nombre de connexions simultanées à la base de données que MySQL accepte. La valeur par défaut est généralement 151. En cas de WordPress intense, cette limite peut être rapidement atteinte, ce qui entraîne des erreurs du type « trop de connexions ». Augmente cette valeur dans le fichier `/etc/mysql/mysql.conf.d/mysqld.cnf` :

max_connections = 500

max_connections = 500

Le paramètre `innodb_buffer_pool_size` détermine la quantité de données que MySQL conserve en mémoire. Les requêtes traitées à partir du pool de mémoire tampon ne nécessitent pas de lecture sur le disque, ce qui constitue le principal facteur de performance sous charge. Définis cette valeur à 70 % de la RAM disponible sur un serveur dédié à la base de données, ou entre 25 et 30 % sur un serveur d'applications partagé :

innodb_buffer_pool_size = 1 Go   # pour un serveur d'applications de 4 Go

innodb_buffer_pool_size = 1G   # for a 4GB application server

Intégration d'un CDN pour le déchargement des ressources statiques

Même une WordPress bien mise en cache génère un trafic important de ressources statiques (images, CSS, JavaScript) vers le serveur d'origine. Un CDN délègue la diffusion des fichiers statiques à des nœuds périphériques situés géographiquement près des visiteurs, ce qui réduit la charge du serveur d'origine tout en améliorant les performances perçues.

Pour WordPress, l'intégration d'un CDN consiste généralement soit à configurer Cloudflare amont de ton domaine, soit à utiliser un plugin WordPress . L'offre gratuite Cloudflarepropose des fonctionnalités CDN de base et une protection contre les attaques DDoS. Pour les sites en production gérant un trafic réel, les règles de mise en cache Cloudflaredoivent être configurées de manière à mettre en cache de manière intensive les ressources statiques et à contourner le cache pour les pages WordPress .

InMotion prend en charge l'intégration d'un CDN pour les formules de serveurs VPS et dédiés. L'essentiel est de configurer ton CDN de manière à respecter le comportement d'invalidation du cache WordPress, en particulier pour les sites utilisant WooCommerce ou proposant des fonctionnalités d'adhésion, où les pages spécifiques à une session ne doivent pas être mises en cache.

Nettoyage de la base de données avant les événements

Au fil du temps, WordPress dans la base de données des révisions d'articles, des options temporaires et des commentaires indésirables. Avant un événement générant un trafic important, nettoyer la base de données permet de réduire la taille des tables et d'améliorer les performances des requêtes.

• Supprimer les révisions des articles : utilise le plugin WP-Optimize ou exécute la commande directement dans MySQL.
• Effacer les fichiers temporaires expirés : WP-Optimize s'en charge aussi.
• Vider la file d'attente des commentaires indésirables.
• Après le nettoyage, exécute la commande OPTIMIZE TABLE sur les tables wp_posts et wp_options.

Il s'agit d'une maintenance, pas d'une optimisation de dernière minute. Intègre-la dans un planning trimestriel plutôt que de la considérer uniquement comme une préparation avant un événement.

À lire aussi : L'article « Optimise ton VPS pour WordPress » présente en détail WordPress optimisée d'InMotion.WordPress : site unique ou sites multiples