Joomla lent : optimiser performances (cache, images, PHP, base de données) — guide 2026
Un site Joomla lent, ce n’est presque jamais une seule cause : c’est un empilement de petites lenteurs côté serveur (TTFB), base de données, extensions, images et cache. La bonne nouvelle : on peut souvent gagner 30 à 80% sur le ressenti utilisateur sans tout refondre.
Si vous cherchez une option simple à opérer (sans passer vos soirées à maintenir serveur + cache + sauvegardes), regardez l’application Joomla sur adgents.cloud : déploiement en 1 clic, scaling CPU/RAM à la demande, backups automatiques (jusqu’à 1/h selon l’offre), et start/stop (compute non facturé à l’arrêt).
1) D’abord : mesurer où ça bloque (TTFB vs assets)
Avant d’optimiser, vous devez savoir si vous êtes lent :
- avant d’envoyer le HTML (TTFB élevé) → problème serveur/PHP/DB/cache
- après (assets lourds) → images, JS/CSS, polices, CDN
Outils utiles :
- PageSpeed Insights (indicateurs terrain + labo)
- GTmetrix / WebPageTest (waterfall, poids des fichiers)
- DevTools Chrome → onglet Network (time to first byte, cache-control)
Cible réaliste
- Page d’accueil : < 2 Mo
- Images : WebP/AVIF si possible, et dimensions adaptées
- TTFB : idéalement < 400–800 ms (selon contexte)
2) Les gains rapides dans Joomla (sans toucher au serveur)
Activer correctement le cache Joomla
Dans l’administration : Système → Configuration globale → Système :
- Cache : Activé
- Mode cache : Conservateur (souvent le meilleur choix)
- Durée du cache : à ajuster (ex: 15–60 min pour un site vitrine)
Astuce : sur un site avec pages publiques + zone connectée, évitez de casser l’expérience en mettant tout en cache “agressif” sans exclure les pages dynamiques.
Activer la compression Gzip (si votre serveur le supporte)
Toujours dans la configuration globale : activez Compression Gzip. Ça réduit le poids transféré, surtout sur HTML/CSS/JS.
Désactiver ce qui ralentit en prod
- Mode debug : off
- Journalisation trop verbeuse : à limiter
- Plugins non utilisés : à désactiver (voire désinstaller)
Pour poser une base propre côté déploiement (HTTPS, volumes, DB persistante), vous pouvez aussi partir du guide : Installer Joomla avec Docker Compose (prod) : HTTPS, DB, volumes.
3) Images : 80% des sites lents se jouent ici
Sur beaucoup de Joomla, le problème n’est pas PHP : ce sont des images trop lourdes et trop nombreuses.
Convertir en WebP et réduire les dimensions
- Exportez en WebP (qualité 70–85 en général)
- Servez une image à la bonne taille (pas 4000px pour une vignette 600px)
- Utilisez un lazy-load propre pour les images sous la ligne de flottaison
Simplifier les polices
- 1 à 2 familles max
- 2 graisses max
- Préférez le self-hosting si vous voulez éviter des allers-retours externes
4) JS/CSS : réduire les requêtes et le blocage du rendu
Objectif : limiter les fichiers, et éviter qu’un gros JS bloque le rendu.
Actions concrètes :
- Minifier et regrouper (selon template/extension)
- Différer certains scripts non critiques
- Supprimer les bibliothèques chargées deux fois (souvent via extensions)
Une règle simple : si une extension ajoute 10 scripts pour une micro-fonction, elle coûte cher en performance.
5) Cache serveur : Redis / reverse proxy / LiteSpeed (quand le TTFB est haut)
Quand le TTFB est élevé, vous avez besoin de cache côté serveur. Deux approches courantes :
- Cache objet / cache application : Redis comme gestionnaire de cache
- Cache page : reverse proxy (ou serveur web avec cache de page)
Redis comme gestionnaire de cache Joomla
Passer de “cache fichier” à Redis améliore souvent la réactivité, car on stocke en mémoire. En pratique :
- Mode cache : Conservateur
- Gestionnaire de cache : Redis
Cache de page (quand c’est possible)
Si votre site est majoritairement public (site vitrine, blog), un cache de page peut être spectaculaire. Selon votre infra :
- LiteSpeed + plugin de cache
- Reverse proxy type Varnish
Le point clé : bien gérer les exclusions (pages panier/compte, formulaires, etc.).
6) PHP : version, OPcache, limites mémoire
Un Joomla moderne a besoin d’un PHP moderne. Les gains de perfs entre versions peuvent être importants.
À vérifier côté serveur :
- PHP à jour (version supportée par votre Joomla)
- OPcache activé
- Mémoire PHP suffisante (sinon, vous compensez par du swap et ça devient lent)
Si vous hébergez vous-même, c’est un point à contrôler dans votre configuration serveur (PHP-FPM / Nginx ou Apache).
7) Base de données : ce qui fait grimper le temps de réponse
Symptômes :
- back-office lent
- pages qui “saccadent” à chaque requête
- pics CPU lors de trafic modéré
Actions utiles :
- Garder MySQL/MariaDB à jour
- Activer un slow query log pour trouver les requêtes lourdes
- Nettoyer les tables qui gonflent (logs, sessions selon contexte)
- Vérifier l’indexation (souvent impactée par certaines extensions)
8) Extensions et template : réduire le poids fonctionnel
C’est fréquent : le site “tourne”, puis on ajoute 15 extensions, et la perf s’effondre.
Méthode simple :
- listez les extensions indispensables
- désactivez une à une pour mesurer l’impact
- remplacez celles qui chargent beaucoup de scripts
Et profitez-en pour sécuriser correctement l’ensemble (beaucoup de lenteurs viennent aussi de sites compromis ou surchargés) : Sécuriser Joomla : hardening, extensions, WAF, sauvegardes (2026).
9) CDN : utile surtout pour les images et les fichiers statiques
Un CDN aide à :
- rapprocher les assets des visiteurs
- réduire la charge serveur
- lisser les pics
Le meilleur ROI : images + fichiers statiques cacheables.
10) Et si vous voulez éviter l’ops : adgents.cloud
Si votre objectif est d’avoir un Joomla rapide sans passer votre temps sur l’exploitation :
- déployez l’application Joomla sur adgents.cloud
- dimensionnez CPU/RAM à la demande
- activez des sauvegardes automatiques (jusqu’à 1/h)
Pour votre environnement, c’est souvent plus simple que de maintenir serveur + reverse proxy + cache + supervision.
Tutoriel vidéo (FR) : vider le cache Joomla (utile en diagnostic)
Checklist finale (rapide)
- Cache Joomla activé (mode conservateur)
- Compression Gzip activée
- Images optimisées (WebP + dimensions adaptées + lazy-load)
- JS/CSS limités et différés quand possible
- OPcache activé + PHP à jour
- Redis et/ou cache de page si TTFB élevé
- Nettoyage extensions inutiles
- CDN pour les assets statiques
Si vous voulez, vous pouvez appliquer la même logique à d’autres CMS : par exemple Drupal lent : optimiser (cache, Twig, DB, CDN) donne une grille de lecture proche (diagnostic, cache, base de données, assets).
