MediaWiki performance : cache, base de données, index, CDN — checklist 2026
Un wiki lent, c’est souvent le même scénario : le serveur PHP travaille trop, la base de données est sollicitée pour des choses qui devraient être en cache, et les visiteurs re-téléchargent les mêmes assets à chaque page. Bonne nouvelle : MediaWiki offre plusieurs niveaux d’optimisation, et vous pouvez obtenir un gros gain sans tout refondre.
Si vous partez de zéro côté hébergement, commencez par un déploiement propre (HTTPS, volumes, DB) : Installer MediaWiki avec Docker Compose (prod).
1) Comprendre les 3 gros postes de latence
Dans la plupart des wikis, la lenteur vient d’un (ou plusieurs) de ces points :
- PHP recompilé trop souvent (OPcache absent ou mal dimensionné).
- Rendu MediaWiki coûteux (parser, pages populaires) non amorti par le cache.
- Base de données trop sollicitée (index manquants, buffer insuffisant, cache en base mal choisi).
L’approche la plus efficace est de traiter dans cet ordre : PHP → caches MediaWiki → cache HTTP → base de données → assets.
2) OPcache : le gain “facile” côté PHP
MediaWiki recommande explicitement un cache de bytecode PHP (OPcache). Sans lui, chaque requête paie un coût inutile.
À viser en priorité :
- OPcache activé (et dimensionné)
- timestamps en production adaptés à votre rythme de déploiement
- PHP-FPM correctement réglé (workers)
Sur un environnement géré, l’important est de mesurer : CPU moyen, pic de requêtes, et temps de réponse avant/après.
3) Activer l’object cache (c’est là que MediaWiki “décolle”)
Le réglage central s’appelle $wgMainCacheType. Par défaut, il est souvent désactivé, ce qui force MediaWiki à s’appuyer davantage sur la base.
Bon choix de backend (règle simple) :
- 1 serveur : APCu peut suffire pour démarrer.
- plusieurs serveurs / besoin de cohérence : Memcached (classique) ou Redis.
MediaWiki indique aussi que Memcached + OPcache donne parmi les gains les plus significatifs sur des instances actives.
Pour aller plus loin, vous pouvez compléter avec un reverse proxy (section suivante) via une infra propre : Héberger MediaWiki sur adgents.cloud.
Attention : sessions et multi-process
Selon votre configuration, stocker certaines données en cache local peut créer des comportements incohérents (sessions qui sautent). Si vous observez des déconnexions, utilisez un store de sessions plus robuste (centralisé).
4) Cache HTTP (reverse proxy) : jackpot pour les wikis orientés lecture
Si votre wiki est surtout consulté (documentation, knowledge base), un cache HTTP devant MediaWiki peut devenir votre meilleur allié :
- Varnish (référence)
- ou cache Nginx côté FastCGI
Le principe : servir du HTML déjà généré pour les pages publiques, et laisser passer ce qui doit rester dynamique (API, pages admin, utilisateurs connectés).
Bénéfices typiques : latence perçue très faible, et baisse nette de charge PHP/DB.
Pour une mise en prod propre (HTTPS, redirections, cache, sauvegardes), l’option la plus simple est un déploiement managé : MediaWiki sur adgents.cloud.
5) Base de données : buffer, index, et erreurs classiques
Quand le cache est bien réglé, la base se calme. Mais si elle reste le goulot, vérifiez :
- InnoDB activé et correctement dimensionné (buffer pool)
- index adaptés aux requêtes réelles
- éviter d’utiliser la base comme object cache si vous avez une alternative (ça peut être plus lent)
Un conseil pragmatique : regardez d’abord les requêtes lentes, puis corrigez au cas par cas (index / réglages).
6) Assets & CDN : arrêter de re-télécharger le même contenu
Pour les images, CSS et JS :
- Cache-Control / expires cohérents
- compression
- CDN si vous avez un trafic significatif ou des utilisateurs géographiquement dispersés
C’est souvent un gain “gratuit” sur le ressenti, surtout sur mobile.
7) Checklist (à dérouler dans l’ordre)
- OPcache activé et dimensionné
- Object cache configuré (APCu/Memcached/Redis) via $wgMainCacheType
- Parser cache et cache directory sur stockage rapide
- Cache HTTP (Varnish/Nginx) pour les pages publiques
- Base de données : buffer + index + suivi requêtes lentes
- Assets : headers + CDN
Conclusion : une perf durable = mesure + itérations
La performance d’un wiki ne se “fait” pas une fois : elle s’entretient. Mais en appliquant ces étapes, vous passez généralement d’un wiki “qui rame” à une expérience fluide, sans surdimensionner.
Si vous voulez une mise en production simple (déploiement en 1 clic, sauvegardes automatiques, scaling CPU/RAM, stop/start), testez adgents.cloud et la page dédiée : Héberger MediaWiki.
Vidéo (FR)
Pour comprendre l’intérêt d’un reverse proxy (et quand ça vaut le coup), cette vidéo en français est une bonne introduction : 
