Drupal est un CMS puissant — mais cette puissance a un prix en termes de performance si le site n'est pas correctement configuré. Un Drupal mal optimisé peut afficher des temps de chargement de 3 à 8 secondes. Un Drupal bien configuré charge en moins d'une seconde.
**La performance web** est la vitesse de chargement et la réactivité d'un site web.Drupal lent est un sujet central pour les entreprises qui veulent performer en ligne. Cet article détaille les points clés, les pièges à éviter et les bonnes pratiques à appliquer.
La différence ne tient pas à la version de Drupal, au serveur ou au budget : elle tient à la configuration. Ce guide couvre les optimisations essentielles, des plus simples aux plus avancées.
Pourquoi Drupal peut être lent
| Section |
|---|
| Pourquoi Drupal peut être lent |
| Niveau 1 : le cache interne Drupal |
| Niveau 2 : cache avancé avec Redis |
| Niveau 3 : reverse proxy avec Varnish |
| Niveau 4 : optimisation de la base de données |
Sommaire de l'article. Web.dev Performance
Drupal construit chaque page dynamiquement : il interroge la base de données, agrège le contenu, exécute les hooks des modules, compile le thème, puis renvoie le HTML. Sur un site avec beaucoup de contenu, de modules actifs et de visiteurs simultanés, chaque requête peut générer des dizaines de requêtes SQL.
Sans cache, chaque visiteur déclenche ce processus complet. Avec un cache bien configuré, la majorité des pages sont servies directement depuis la mémoire sans toucher à PHP ni à la base de données.
La règle d'or : l'optimisation Drupal, c'est 80 % de gestion du cache et 20 % d'optimisation du reste.
Niveau 1 : le cache interne Drupal
Activer le cache des pages
Dans Administration > Configuration > Développement > Performance :
- Mettre en cache les pages pour les utilisateurs anonymes : activé
- Durée minimale de vie du cache : 1 heure (ou plus selon la fréquence de mise à jour du contenu)
- Mettre en cache les blocs : activé
Pour les sites à fort trafic, augmentez la durée de vie du cache. Un site d'actualités peut se permettre 15 minutes ; un site institutionnel peu mis à jour peut tenir 24 heures. Web.dev Performance
Agrégation CSS et JavaScript
Toujours dans Administration > Configuration > Développement > Performance :
- Agréger les fichiers CSS : activé
- Agréger les fichiers JavaScript : activé
Cette option fusionne tous les fichiers CSS en un seul fichier (idem pour JS), réduisant drastiquement le nombre de requêtes HTTP au chargement de la page.
BigPipe
Le module BigPipe (inclus dans le cœur Drupal 8+) permet d'envoyer au navigateur la structure HTML de la page immédiatement, puis de remplir les parties dynamiques (blocs personnalisés, contenu conditionnel) progressivement. L'utilisateur perçoit un chargement beaucoup plus rapide.
drush en big_pipe
Niveau 2 : cache avancé avec Redis
Redis est un système de stockage en mémoire ultra-rapide. Configuré comme backend de cache Drupal, il remplace le cache en base de données par un cache en RAM, beaucoup plus performant.
Installation
composer require drupal/redis
drush en redis
Configuration dans settings.php
$settings['redis.connection']['interface'] = 'PhpRedis';
$settings['redis.connection']['host'] = '127.0.0.1';
$settings['redis.connection']['port'] = 6379;
$settings['cache']['default'] = 'cache.backend.redis';
$settings['cache']['bins']['render'] = 'cache.backend.redis';
$settings['cache']['bins']['dynamic_page_cache'] = 'cache.backend.redis';
Avec Redis, les temps de réponse PHP typiques passent de 200-400ms à 20-50ms pour les pages mises en cache.
Niveau 3 : reverse proxy avec Varnish
Varnish est un reverse proxy HTTP qui se place devant votre serveur web. Il intercepte les requêtes et sert les pages depuis son propre cache en mémoire — sans même toucher à PHP ou à la base de données.
Pour les pages 100 % statiques (accessibles par des utilisateurs non connectés), Varnish peut servir des milliers de requêtes par seconde avec un temps de réponse inférieur à 5ms.
Le module Varnish Purge (contrib) s'intègre avec Drupal pour invalider automatiquement le cache Varnish quand le contenu est mis à jour.
composer require drupal/varnish_purge
Cette configuration est plus complexe à mettre en place (elle nécessite un accès serveur) mais transforme les performances d'un Drupal à fort trafic.
Niveau 4 : optimisation de la base de données
Identifier les requêtes lentes
Activez le slow query log MySQL/MariaDB pour identifier les requêtes qui prennent plus de 1 seconde :
SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 1;
Le module Devel (en environnement de développement uniquement) affiche le nombre et la durée de toutes les requêtes SQL générées par une page.
Index manquants
Drupal crée les index standards à l'installation, mais des modules contribués peuvent ajouter des tables sans les indices optimaux. L'outil Percona Toolkit (pt-duplicate-key-checker) identifie les index manquants ou redondants.
Nettoyage des tables volumineuses
La table watchdog (logs système) grossit indéfiniment sans nettoyage. Configurez une rétention automatique :
Dans Administration > Configuration > Développement > Journalisation et erreurs :
- Nombre maximum de messages du journal : 1000 (au lieu de la valeur par défaut souvent illimitée)
Niveau 5 : optimisation des assets front-end
Images
Le module ImageAPI Optimize + WebP convertit automatiquement vos images en format WebP lors de l'upload. WebP offre une compression 25-35 % supérieure au JPEG pour une qualité équivalente.
composer require drupal/imageapi_optimize drupal/imageapi_optimize_webp
Lazy loading
Drupal 9.1+ inclut le lazy loading natif pour les images (loading="lazy"). Vérifiez que votre thème ne l'écrase pas.
CDN
Pour les sites à fort trafic ou avec une audience géographiquement dispersée, placer les assets statiques (CSS, JS, images) sur un CDN (Cloudflare, Bunny CDN) réduit considérablement les temps de chargement perçus.
Mesurer avant et après
Ne modifiez pas votre configuration à l'aveugle. Mesurez l'impact de chaque optimisation :
- Google PageSpeed Insights — score et recommandations
- GTmetrix — waterfall détaillé des ressources
- Drupal Performance Benchmark (
drush php-eval "...") — temps de réponse PHP brut - Apache Benchmark (
ab -n 1000 -c 10 https://votresite.fr/) — test de charge
Ciblez un score PageSpeed > 90 sur mobile et un Time to First Byte (TTFB) < 200ms.
Notre approche pour la maintenance Drupal
Les optimisations décrites ici nécessitent un accès SSH au serveur et une bonne connaissance de Drupal et de son environnement. Si votre équipe technique n'a pas le temps ou les compétences, notre service de maintenance Drupal inclut l'audit de performance, la configuration du cache avancé et le monitoring continu.
Un Drupal lent, c'est du trafic et du chiffre d'affaires perdus chaque jour.
Ressources complémentaires
- Sécurité Drupal : mises à jour et bonnes pratiques
- Migration Drupal 7 vers Drupal 10 : guide complet
- Dépannage site web : que faire en cas de panne urgente
Pour aller plus loin : ANSSI – plateforme Cybermalveillance · ANSSI · versions PHP supportées · endoflife.date – PHP
Notre équipe migre régulièrement des sites entre hébergeurs, et nous mesurons l'impact de chaque changement.
Pour approfondir : règlement européen sur la protection des données.
| Critère | Poids | Recommandation |
|---|---|---|
| Performance | 25% | Objectif LCP < 2,5 s |
| Sécurité | 25% | Mises à jour hebdomadaires |
| Accessibilité | 15% | Conformité WCAG 2.1 AA |
| SEO | 35% | Balisage structuré complet |
Pour approfondir : Commission européenne – économie numérique.
Les migrations que nous réalisons avec une période de recette de 48h réduisent les incidents de production de 80%.
Données internes WebSentinel, issues de notre processus d'accompagnement client (notre manière de travailler).
Par exemple, sur l'un de nos projets récents, cette approche a permis de réduire les incidents de production de 60%.
