Guides Pratiques

Alléger la charge du serveur WordPress avec le cache objet côté serveur (Redis, Memcached)

  • 14 min de lecture
  • L'équipe Hostragons
Alléger la charge du serveur WordPress avec le cache objet côté serveur (Redis, Memcached)

Le cache côté serveur consiste à stocker temporairement les requêtes répétitives de la base de données WordPress dans des systèmes en mémoire comme Redis ou Memcached, pour réduire la charge sur MySQL ou MariaDB. Bien configuré, il diminue le nombre de requêtes, améliore le TTFB, réduit l’utilisation CPU et offre des réponses plus rapides, surtout sur les sites à fort trafic. En résumé : WordPress sert les données via la RAM plutôt que d’interroger la base de données à chaque requête.

WordPress étant un CMS dynamique, chaque affichage de page peut générer de nombreuses requêtes pour le thème, les extensions, les menus, les options, les sessions utilisateurs, les produits, les commentaires et le contenu. Une simple page d’entreprise peut générer 40-80 requêtes, tandis qu’un site avec WooCommerce, un système de membres ou multilingue peut atteindre 150-300 requêtes par page. Quand le trafic augmente, le goulot d’étranglement est généralement la base de données, pas PHP. C’est là que Redis et Memcached interviennent.

Ce guide décrypte les différences Redis/Memcached, les cas d’usage pour chaque, le fonctionnement du cache objet, les étapes d’installation, les métriques de mesure et les erreurs fréquentes. Si votre site WordPress est lent, que le back-office rame ou que la charge explose lors des campagnes, vous trouverez ici une feuille de route pratique. Pour optimiser votre infrastructure, consultez aussi Forfaits d'hébergement WordPress et pour les gros projets Solutions de serveurs VPS.

Qu’est-ce que le cache côté serveur ?

Le cache côté serveur stocke les données au niveau du serveur, et non du navigateur. Cette couche comprend le cache de page, l’OPcache, le cache CDN edge, le cache des requêtes SQL et le cache objet. Redis et Memcached sont principalement utilisés pour le cache objet persistant.

Dans WordPress, le cache objet retient en RAM les objets précédemment calculés ou récupérés depuis la base de données : paramètres du site, menus, résultats de requêtes, variations de produits, métadonnées utilisateurs, données temporaires, etc. La RAM est bien plus rapide que le disque. Ainsi, Redis ou Memcached répondent instantanément aux requêtes répétées, évitant un accès coûteux à la base de données.

Attention : le cache côté serveur ne transforme pas miraculeusement un site mal optimisé. Des plugins lourds, des requêtes mal écrites, une table wp_options surchargée, un panier WooCommerce mal géré ou des tâches cron mal configurées pourront toujours ralentir votre site. Mais un cache objet Redis/Memcached bien intégré fait une différence majeure sur une infrastructure WordPress saine.

Pourquoi la charge de base de données WordPress augmente-t-elle ?

La principale cause est la production dynamique de contenu, qui génère des requêtes à chaque visite, scan de bot ou action en back-office. Quand le trafic explose, les mêmes requêtes se répètent des centaines de fois, saturant le serveur SQL.

Sources de charge les plus fréquentes

  • Transactions WooCommerce : panier, paiement, stock, variations produits, nécessitent des données actualisées en permanence.
  • Thèmes et constructeurs lourds : shortcodes imbriqués, widgets dynamiques multiplient les requêtes.
  • Trop d’extensions : chaque plugin apporte ses propres tables et requêtes, ajoutant à la complexité.
  • Table wp_options surchargée : les options autoload élevées sont chargées à chaque requête.
  • Ressources serveur insuffisantes : RAM limitée, CPU sous-dimensionné, disque lent aggravent les files d’attente SQL.
  • Trafic de bots ou spam : Les requêtes non humaines sollicitent aussi la base.

Par exemple : un site WordPress avec 20 000 pages vues par jour et 120 requêtes par page produit 2,4 millions de requêtes quotidiennes. Si 40 % sont répétitives, le cache objet peut éviter des centaines de milliers de requêtes SQL, soulageant drastiquement le CPU et l’I/O pendant les pics.

Comment Redis et Memcached fonctionnent-ils dans WordPress ?

Redis et Memcached ne servent pas à accélérer les fichiers de thème : ils gèrent le cache objet. WordPress possède un cache objet éphémère en natif, mais celui-ci disparaît à chaque requête. Avec Redis ou Memcached, les objets sont stockés entre les requêtes et deviennent persistants.

Principe de fonctionnement de Redis

Redis est une base en mémoire clé/valeur, qui gère non seulement des chaînes simples, mais aussi listes, sets, hash et sorted sets. Dans WordPress, Redis stocke les options du site, résultats de requêtes, transients et données d’extensions en RAM. Il offre des options de persistance : certains objets survivent à un redémarrage, mais le principal objectif reste la rapidité, pas la conservation longue durée.

Principe de fonctionnement de Memcached

Memcached est également un cache clé/valeur en mémoire, mais plus simple. Très rapide et efficace pour des scénarios de cache distribués et peu complexes. Avec le bon plugin WordPress, il sert les requêtes répétées directement depuis la RAM. Il est moins flexible que Redis : pas de structures avancées ni persistance.

Redis ou Memcached ? Tableau comparatif

Les deux réduisent la charge SQL. Le choix dépend de la structure du trafic, des ressources, de la simplicité de gestion et de l’évolutivité.

Redis ou Memcached ? Tableau comparatif
CritèreRedisMemcached
Modèle de donnéesStructures avancéesClé-valeur simple
Compatibilité WordPressTrès répandu, nombreux pluginsCompatible, mais écosystème limité
PersistanceOptions RDB/AOFNon persistant
PerformanceUltra-rapide, flexibleUltra-rapide, simple
Facilité de gestionParamétrage avancé, monitoringSimplifié
Recommandé pourWooCommerce, membres, gros sites dynamiquesBlogs simples, cache distribué léger

En pratique, Redis est souvent le meilleur choix pour WordPress moderne : WooCommerce, LMS, forums, réservations, membres… Redis se distingue par la gestion et l’écosystème. Memcached reste pertinent sur des projets simples ou nécessitant un cache distribué rapide sans complexité.

Quand le cache côté serveur devient-il indispensable pour WordPress ?

Un petit site WordPress n’a pas besoin d’un cache objet dès le début. Mais certains signaux montrent qu’il est temps d’y penser :

Signaux de performance à surveiller

  • TTFB supérieur à 600 ms sur plusieurs pages.
  • Back-office lent lors des transitions de page.
  • CPU MySQL qui grimpe avec le trafic.
  • Retard sur les pages panier/paiement WooCommerce.
  • Augmentation des temps de réponse lors du crawl Googlebot.
  • Alertes limites ressources ou connexions sur le panneau d’hébergement.

Par exemple, un site éditorial peut être rapide en cache page sur la home, mais lent en back-office, sur la recherche, les filtres ou pour les utilisateurs connectés. Le cache page ne suffit pas : le cache objet devient crucial. Le cache côté serveur améliore donc aussi bien la performance visible que l’efficacité interne de WordPress.

Préparation avant installation : mesurer avant tout

Avant d’installer un cache, il faut mesurer l’état actuel. Sinon, impossible de savoir d’où vient le gain, quelles options fonctionnent ou quels problèmes persistent. Un pro commence par établir des valeurs de référence, active Redis/Memcached, puis refait les mêmes tests.

Métriques à mesurer au départ

  • TTFB : Temps jusqu’au premier octet, mesurable via WebPageTest, GTmetrix ou les outils développeur du navigateur.
  • Nombre de requêtes SQL : Query Monitor permet d’analyser le nombre de requêtes par page.
  • Requêtes lentes : Le slow query log de MySQL révèle les points de blocage.
  • Utilisation RAM : Définir combien de mémoire réserver à Redis/Memcached.
  • Cache hit ratio : Pourcentage de requêtes servies depuis le cache : 70 % ou plus sur un site bien optimisé.

Il ne suffit pas de tester la home : analysez aussi page de blog, catégorie, fiche produit, panier, paiement, recherche, et back-office. La performance WordPress ne se résume pas à un score de page.

Installer le cache objet Redis sur WordPress

L’installation Redis dépend des droits serveur, du type d’hébergement et du panneau de gestion. Sur un hébergement mutualisé, Redis doit être offert par le prestataire. Sur VPS ou serveur dédié, vous pouvez l’installer comme service système. Sur Hostragons, pour Redis, voyez Caractéristiques de l'hébergement WordPress ou Serveur VPS géré.

Plan d’installation Redis étape par étape

  • 1. Sauvegardez : Faites une sauvegarde des fichiers et de la base avant tout changement de cache.
  • 2. Vérifiez le support serveur : Assurez-vous que Redis est actif, que l’extension PHP Redis est installée et que le port est sécurisé.
  • 3. Installez le plugin WordPress : Utilisez un plugin fiable et maintenu, comme Redis Object Cache.
  • 4. Activez la connexion : Testez la connexion via le plugin et vérifiez la création du fichier object-cache.php.
  • 5. Vérifiez wp-config : Configurez le salt de cache, l’index de base et le timeout si besoin.
  • 6. Testez : Vérifiez la performance sur le back-office, le front, le panier et pour les utilisateurs connectés.
  • 7. Surveillez : Suivez le hit ratio, la mémoire utilisée et les clés évincées.

Définir une limite RAM pour Redis est crucial. Sur un VPS de 2 Go, laisser Redis utiliser toute la RAM peut priver PHP/MySQL de ressources. Commencez à 128-256 Mo, augmentez selon le trafic WooCommerce (512 Mo et plus si nécessaire), en vous basant sur les métriques réelles.

Installer le cache objet Memcached sur WordPress

Memcached s’installe aussi comme service serveur, avec intégration WordPress via un plugin. Il est privilégié pour un cache rapide, simple et peu complexe. Sur des architectures multi-serveurs, il peut être distribué, mais attention à la compatibilité plugin WordPress et la maintenance.

Plan d’installation Memcached étape par étape

  • 1. Vérifiez le service serveur : Memcached doit tourner, et l’extension PHP memcached doit être active.
  • 2. Sécurisez l’accès : Le service ne doit pas être accessible via une IP publique. Préférez une connexion locale ou réseau privé.
  • 3. Choisissez un plugin WordPress : Utilisez un plugin maintenu, compatible avec object-cache drop-in.
  • 4. Définissez le quota mémoire : Ajustez la mémoire selon la taille du site et le trafic.
  • 5. Testez sur des pages réelles : Vérifiez le comportement pour les utilisateurs connectés et les pages dynamiques.

La simplicité de Memcached est un atout, mais il offre moins de monitoring et de gestion que Redis sur des scénarios WordPress complexes. Pensez aussi à l’entretien, pas seulement à la vitesse.

Stratégie de durée, purge et invalidation du cache

La question clé du cache : quand et comment actualiser les données ? Un cache trop agressif risque d’afficher des contenus obsolètes ; un cache trop court diminue le gain de performance. WordPress invalide automatiquement beaucoup de caches objets, mais certains plugins ou développements personnalisés peuvent perturber ce processus.

Conseils pour une stratégie saine

  • Assurez-vous que les clés de cache sont bien purgées lors de la mise à jour du contenu.
  • Excluez le panier, paiement et « Mon compte » WooCommerce du cache page.
  • Évitez de purger complètement le cache objet trop fréquemment : cela ralentit le warm-up.
  • Ne modifiez pas les règles de cache sur le site live sans test préalable sur staging.
  • Sur les sites multilingues, vérifiez qu’il n’y a pas de collision entre les clés de langue.

Exemple : un site d’actualité doit afficher la home, les catégories et les tags à jour lors d’une nouvelle publication. Même si Redis accélère les requêtes SQL, la logique de purge doit être cohérente entre le cache objet, le cache page et le CDN. Pour planifier ensemble CDN, SSL et publication sécurisée, consultez solutions de certificats SSL et Gestion de domaine.

Utilisation de Redis et Memcached sur WooCommerce

WooCommerce possède une structure de base de données plus complexe qu’un blog : produits, variations, stocks, coupons, commandes, sessions clients, paniers… changent en permanence. Le cache objet apporte donc un gain précieux, mais demande une vigilance accrue.

Redis est généralement le choix privilégié sur WooCommerce : il améliore la performance lors du listing produit, du filtrage et en back-office. Mais un mauvais cache sur les pages panier/paiement peut causer de graves problèmes d’expérience ou de commandes. Adaptez les règles de cache objet et page en conséquence.

Paramètres pratiques WooCommerce

  • Excluez le panier, paiement et « Mon compte » du cache page.
  • Vérifiez la purge du cache après modification de stock.
  • Sur les boutiques à nombreuses variations, surveillez la mémoire Redis.
  • N’empêchez pas inutilement les requêtes Ajax admin via le cache.
  • Avant les campagnes, faites un warm-up et testez la charge.

Avant des périodes comme Black Friday, Noël ou lors de campagnes publicitaires, activer le cache ne suffit pas : testez avec des scénarios réels, vérifiez les limites de connexions SQL et augmentez temporairement les ressources serveur. Pour ces cas, voyez Hébergement pour sites web à fort trafic.

Sécurité et configuration serveur : points d’attention

Redis et Memcached sont des outils de performance, mais mal configurés, ils posent des risques de sécurité. Règle majeure : ne jamais exposer ces services à internet sans protection. Les ports Redis/Memcached doivent être accessibles uniquement depuis le serveur local, un réseau privé ou via un accès sécurisé.

Checklist sécurité essentielle

  • Ne laissez pas le port Redis par défaut (6379) ouvert à internet.
  • Fermez le port Memcached (11211) aux connexions externes.
  • Configurez mot de passe, adresse bind et firewall si besoin.
  • Mettez à jour les services.
  • Sur les environnements mutualisés, utilisez un salt de clé de cache pour éviter les collisions inter-sites.
  • Préparez un plan de sauvegarde et de restauration serveur.

Le cache objet ne remplace pas la base de données : si les objets en cache Redis disparaissent, WordPress doit pouvoir les régénérer. Considérez Redis comme un accélérateur, pas comme un stockage définitif.

Comment mesurer le succès ?

Après installation, comparez les performances avant/après. Au-delà du score de vitesse de page, analysez aussi l’utilisation des ressources serveur.

Indicateurs clés à suivre

  • Chute du TTFB : Par exemple, passer de 850 ms à 350 ms améliore nettement l’expérience utilisateur.
  • Diminution du nombre de requêtes : Vérifiez avec Query Monitor que les requêtes répétitives sont réduites.
  • Cache hit ratio : Un taux de 70-90 % est considéré comme sain sur WordPress.
  • CPU MySQL : Attendez-vous à des graphiques plus stables en période de charge.
  • Logs d’erreurs : Surveillez les erreurs de connexion, timeout ou de sérialisation.

Sur un site bien configuré, Redis n’apporte pas un gain immédiat lors des premières visites : il faut quelques minutes pour « chauffer » le cache. La vraie amélioration arrive lors des requêtes répétées. Testez donc sur plusieurs sessions et à différents moments.

Erreurs fréquentes

Le cache côté serveur est puissant, mais mal utilisé, il peut manquer son but. Les erreurs les plus courantes en WordPress viennent souvent d’un manque de mesure et de plugins incompatibles.

  • Tout mettre en cache : Les données dynamiques (utilisateurs, paiement) doivent être exclues.
  • Considérer la purge comme solution : Trop de flush ralentit le site, ne l’accélère pas.
  • RAM insuffisante : Trop peu de mémoire cause l’éviction fréquente des clés.
  • Plugins incompatibles : Utiliser plusieurs plugins cache objet peut provoquer des conflits.
  • Ignorer la sécurité : Des ports ouverts Redis/Memcached sont un risque majeur.
  • Négliger l’optimisation SQL : Index, nettoyage de table et analyse de requêtes restent essentiels.

Pour éviter ces pièges, avancez par petites étapes, mesurez à chaque changement et gardez un plan de retour en cas de problème. L’optimisation ne se résume pas à un plugin : pensez hébergement, version PHP, base de données, thème, extensions et sécurité ensemble.

Conclusion : un WordPress plus rapide, une base de données allégée

Le cache côté serveur via Redis et Memcached est l’un des moyens les plus efficaces pour réduire la charge SQL sur WordPress. Redis offre flexibilité et puissance pour les scénarios modernes, Memcached reste pertinent pour un cache simple et rapide. Avec la bonne installation, des mesures précises et une stratégie de purge adaptée, vous réduirez le TTFB, allégerez la charge MySQL et stabiliserez votre site.

Si votre site WordPress prend de l’ampleur, si le trafic WooCommerce augmente ou si le back-office ralentit, commencez par mesurer les performances, puis planifiez la couche de cache adaptée. Pour booster votre WordPress sur Hostragons, découvrez Hébergement WordPress, serveur VPS, Enregistrement de domaine et certificat SSL : notre équipe vous guidera vers la solution la plus adaptée.

FAQ – Questions fréquentes

Est-ce que Redis accélère systématiquement mon site WordPress ?

Redis accélère les requêtes répétées via la RAM sur la plupart des sites dynamiques. Mais si vos plugins sont mal écrits, que vous avez des appels API externes lents ou un thème mal codé, Redis ne résout pas tout. Les meilleurs résultats viennent d’une mesure précise, d’une optimisation SQL et d’un hébergement adapté.

Memcached ou Redis : lequel est le plus rapide ?

Les deux sont très rapides : le choix dépend de la configuration. Memcached excelle en cache clé-valeur simple. Redis est plus flexible grâce à ses structures avancées, sa persistance et son vaste écosystème WordPress.

Avec Redis, ai-je encore besoin du cache page ?

Oui. Redis gère le cache objet ; le cache page est une couche séparée. Pour une performance optimale, combinez Redis (cache objet), cache page, OPcache et CDN. Prévoyez des exceptions précises sur les pages dynamiques comme panier/paiement.

Redis ou Memcached remplacent-ils la base de données ?

Non. Ce sont des caches temporaires : la source des données reste MySQL ou MariaDB. Si le cache est purgé, WordPress régénère les données via la base.

Puis-je utiliser Redis sur un hébergement mutualisé ?

Tout dépend du prestataire : certains packages WordPress incluent Redis, d’autres non pour des raisons de sécurité ou de ressources. Pour un contrôle total, privilégiez un VPS ou un serveur managé.

Partagez cet article :

L'équipe Hostragons

Des guides actualisés de notre équipe d'experts sur l'hébergement, les serveurs et les noms de domaine. Trouvons ensemble la solution idéale pour votre projet.

Contactez-nous