Notre méthode ne se résume pas à une plaquette : voici les fondamentaux que nous appliquons sur chaque mission.
Pourquoi un Drupal est-il souvent lent par défaut?
Drupal est un CMS extrêmement puissant — flexibilité, modèles de contenu, multilinguisme natif, gouvernance fine — mais cette puissance a un coût par défaut: à l'installation, un Drupal exécute des dizaines de hooks à chaque page, charge l'intégralité du registry de modules, génère des requêtes SQL multiples sur le système d'entités, et empile les couches de cache sans configuration optimale. Ajoutez à ça l'accumulation typique d'un site en production depuis 3 à 5 ans: modules contrib installés puis oubliés, hooks custom écrits sans benchmark, vues (Views) avec des sous-requêtes coûteuses, thèmes héritant de libraries jQuery inutiles en D10+. Le résultat: un TTFB d'1,5 s, un LCP de 5 s, un Lighthouse mobile à 38. La bonne nouvelle, c'est que la majorité de ces freins se règle sans réécriture — par audit, configuration et chirurgie ciblée.
Le triptyque Drupal: cache, BDD, modules
Trois leviers concentrent 80 % des gains perf sur Drupal. (1) Le cache: Drupal propose 4 couches (Internal Page Cache pour les anonymes, Dynamic Page Cache pour les authentifiés, BigPipe pour le streaming progressif, et le backend de cache pour les objets via Redis/Memcached). Une configuration mal faite — cache contexts trop larges, tags non invalidés, BigPipe désactivé — peut diviser par 5 les performances. (2) La BDD: Drupal est verbeux côté SQL. Un site sans index sur les colonnes clés des entités custom, ou avec des vues mal optimisées, génère des centaines de requêtes par page. L'activation du slow query log MySQL pendant 24 h révèle systématiquement les coupables. (3) Les modules contrib: chaque module ajoute des hooks, des routes, des permissions, parfois du JS. Un audit révèle quasi toujours 30 à 50 % de modules désactivables ou remplaçables par une approche plus légère.
Notre stack de mesure et d'optimisation
Côté mesure, nous combinons trois outils complémentaires: XHProf ou Blackfire pour le profiling PHP (identification des fonctions et hooks coûteux), New Relic ou Datadog pour le monitoring production (TTFB, throughput, erreurs), et le couple Lighthouse + CrUX pour les Core Web Vitals (lab + utilisateurs réels). Côté optimisation, nous appliquons une chaîne éprouvée: configuration cache Drupal (toutes les couches), Redis pour l'object cache, MySQL tuning (innodb_buffer_pool sizing, query cache), aggregation CSS/JS via core ou Advagg, BigPipe activé partout où c'est pertinent, images via image styles + AVIF/WebP, CDN (Cloudflare ou Fastly) avec règles de cache par type de contenu, et purges automatiques au déploiement. Pour les sites multilingues ou multisite, nous ajoutons un audit des contextes de cache et des configurations Languages spécifiques.
Pourquoi nos objectifs de performance restent mesurables
Nous fixons des objectifs clairs sur les templates ciblés, typiquement viser un Lighthouse mobile > 90 et un TTFB resserré lorsque l'hébergement et les dépendances le permettent. Cette approche fonctionne parce que l'audit préalable identifie précisément les leviers atteignables compte tenu des contraintes (hébergement, modules indispensables, intégrations tierces). Si une contrainte rend un seuil irréaliste, nous le documentons en amont et co-validons un objectif réaliste avec votre équipe. Nous mesurons avant/après sur Lighthouse en lab et sur CrUX (utilisateurs réels) avec un délai de 28 jours, et configurons un monitoring continu pour détecter toute régression. Le brief de transfert à votre équipe technique permet de pérenniser les gains — un site Drupal optimisé reste rapide à condition d'auditer chaque nouveau module contrib et chaque hook custom avant déploiement.