Drupal lent : 15 causes fréquentes + correctifs (cache, Twig, DB, CDN)
Un site Drupal peut devenir lent pour plein de raisons : cache mal réglé, base de données sous pression, vues trop coûteuses, images trop lourdes, ou simplement un hébergement qui ne suit pas. La bonne nouvelle : dans la majorité des cas, on peut gagner beaucoup avec une méthode de diagnostic simple et quelques réglages structurés.
Pour démarrer sur des bases saines côté infra, vous pouvez aussi consulter : Installer Drupal avec Docker Compose (prod) — et si vous cherchez une solution clé en main, jetez un œil à l’application Drupal sur adgents.cloud.
Avant de corriger : identifiez où ça bloque (en 10 minutes)
Avant de toucher aux réglages, cherchez à savoir si le problème est plutôt frontend (poids des pages) ou backend (temps serveur).
- TTFB élevé (ex: > 800 ms) : PHP/DB/cache/infrastructure.
- LCP élevé mais TTFB correct : images/CSS/JS/polices.
- Lenteur uniquement connecté : cache dynamique, pages personnalisées, permissions, blocs, Views.
Outils utiles : Lighthouse / PageSpeed Insights, WebPageTest, et côté serveur vos logs (Nginx/Apache + PHP-FPM).
1) Le cache Drupal est désactivé (ou vidangé trop souvent)
C’est la cause la plus fréquente : en production, Drupal doit pouvoir réutiliser ce qu’il calcule.
À faire :
- Vérifier la configuration performance dans l’admin Drupal.
- Éviter les actions qui vident le cache en boucle (certains déploiements, modules ou hooks mal contrôlés).
Si vous ne l’avez pas encore fait, commencez par sécuriser l’exploitation (updates, WAF, etc.) ici : Drupal en production : sécurité (guide 2026) — et gardez un environnement de préprod pour tester les changements sans stress.
2) Vous confondez “cache page” et “cache de rendu”
Drupal ne cache pas seulement des pages entières : il cache aussi des composants (blocs, fragments).
Correctif :
- S’assurer que les blocs, menus, et composants lourds utilisent correctement les mécanismes de cache Drupal (contextes / tags / max-age).
- Réduire la personnalisation inutile sur des pages très visitées (ex: 10 blocs “dynamiques” partout).
3) Twig est en mode dev (cache templates désactivé)
Un thème qui recompile les templates en permanence peut pénaliser le CPU.
Correctif :
- En production, activer le cache Twig et éviter les réglages “développement”.
- Garder les options dev uniquement sur un environnement dédié (très recommandé si vous déployez via Docker).
4) Les Views sont trop coûteuses
Les Views peuvent générer des requêtes lourdes (tri, jointures, conditions, relations).
Correctifs rapides :
- Limiter le nombre d’items affichés et paginer proprement.
- Éviter les tris sur des champs non indexés.
- Mettre en cache la View quand c’est possible (et pas seulement le rendu final).
5) La base de données manque d’index (ou souffre de requêtes lentes)
Quand la DB rame, tout le site rame : pages, admin, cron.
Correctif :
- Activer/consulter les slow queries côté MySQL/MariaDB/PostgreSQL.
- Ajouter les index pertinents (en priorité : champs de tri/filtre réellement utilisés).
Astuce : si votre infra est sous-dimensionnée, une montée en CPU/RAM peut suffire à stabiliser les pics — adgents.cloud permet d’ajuster ça facilement (et de stopper l’instance quand vous n’en avez pas besoin).
6) Le cache est stocké en base de données (et ça coûte cher)
Sur certains sites, laisser les caches dans la DB devient un goulot d’étranglement.
Correctif :
- Utiliser un backend de cache en mémoire (ex: Redis) quand ça a du sens.
- Garder la DB pour ce qu’elle fait le mieux : les données métier.
7) Reverse proxy / cache HTTP absent (ou mal configuré)
Pour les pages publiques, un cache HTTP (reverse proxy) peut faire gagner énormément sur le TTFB.
Correctif :
- Mettre un reverse proxy (ex: Varnish ou un cache CDN) devant l’app.
- Vérifier les en-têtes (Cache-Control) et la cohérence de l’expiration.
8) Agrégation/minification CSS/JS non activée
Un front trop bavard (beaucoup de fichiers) augmente les requêtes et ralentit le rendu.
Correctif :
- Activer l’agrégation/minification en production.
- Éviter d’injecter des scripts tiers inutiles (tags marketing, widgets).
9) Images lourdes (et pas de formats modernes)
Les images sont souvent le premier facteur du LCP.
Correctifs :
- Servir des images à la bonne taille.
- Utiliser WebP/AVIF quand possible.
- Activer le lazy-loading sur les images non critiques.
10) Pas de CDN pour les assets statiques
Un CDN réduit la latence et protège mieux vos serveurs lors des pics.
Correctif :
- Mettre les images, CSS et JS derrière un CDN (Cloudflare, Fastly, etc.).
- Vérifier que la cache navigateur est bien configurée sur les assets versionnés.
11) Trop de modules activés (ou modules gourmands)
Chaque module ajoute du code, des services, parfois des requêtes et du rendu.
Correctif :
- Désactiver/supprimer les modules inutilisés.
- Auditer les modules qui ajoutent des traitements sur chaque requête (tracking, règles, champs calculés).
12) Cron Drupal trop lourd, trop fréquent, ou mal planifié
Un cron qui sature CPU/DB peut rendre le site lent “par vagues”.
Correctif :
- Planifier les tâches lourdes hors heures de pointe.
- Surveiller la durée des exécutions et isoler les tâches coûteuses (indexations, imports).
13) PHP-FPM mal dimensionné (process trop nombreux ou pas assez)
Si PHP-FPM est mal réglé, vous aurez soit de la file d’attente (trop peu de workers), soit de l’out-of-memory (trop).
Correctif :
- Ajuster pm.max_children / pm.* selon la RAM disponible et la charge.
- Surveiller les temps de réponse et la consommation mémoire réelle.
14) Cache navigateur / en-têtes HTTP oubliés
Sans cache navigateur, les visiteurs re-téléchargent trop de fichiers statiques.
Correctif :
- Paramétrer des en-têtes cohérents pour les assets statiques.
- Versionner les fichiers statiques pour pouvoir augmenter l’expiration sans risque.
15) Pas de monitoring (et donc pas de vérité)
Sans mesure, on “optimise” à l’aveugle.
Correctif :
- Surveiller TTFB, erreurs, temps DB, saturation CPU/RAM.
- Mettre des alertes simples (pics 5xx, latence, disque).
Une vidéo (FR) pour compléter
Si vous développez sur Drupal et que vous jonglez avec les caches, cette vidéo est pratique (et courte) : 
.
Lancez-vous avec Drupal.
Envie de vous lancer avec Drupal ? Créez votre site web en quelques clics.
Drupal
La solution pour projets complexes
Hébergement : le point qui change tout quand vous avez déjà “optimisé”
Parfois, tout est “bien configuré” mais l’infrastructure est simplement trop juste (CPU/RAM/disque), ou pas assez flexible.
Sur adgents.cloud, vous pouvez :
- déployer Drupal rapidement,
- ajuster CPU/RAM quand la charge monte,
- automatiser des sauvegardes (jusqu’à 1/h) avec rétention longue,
- stopper/redémarrer vos instances selon vos besoins (facturation à l’heure).
Si vous voulez un point de départ concret : Héberger Drupal sur adgents.cloud.
Résumé (actions à fort impact)
- Vérifier cache Drupal + cache Twig en production
- Traquer les Views et requêtes lentes
- Mettre un backend de cache en mémoire + reverse proxy si utile
- Optimiser images + activer CDN
- Mettre du monitoring, sinon vous reviendrez au hasard
