Cache Drupal : le guide complet

La performance d'un site Drupal ne se joue pas uniquement sur la qualité du code ou la puissance du serveur. Elle se joue d'abord sur le cache. Drupal embarque l'une des architectures de cache les plus sophistiquées du marché des CMS, capable de servir une page complexe en quelques millisecondes plutôt qu'en plusieurs centaines. Bien comprise et bien configurée, cette mécanique transforme l'expérience utilisateur, allège la charge serveur et soutient directement votre référencement. Mal comprise, elle devient une source de bugs déroutants (contenus périmés, pages qui ne se rafraîchissent pas) et de tickets de support difficiles à diagnostiquer.

Ce guide passe en revue les couches de cache de Drupal, explique quand utiliser quoi, comment configurer le tout de façon optimale, comment fonctionne l'invalidation via les cache tags et comment brancher des solutions externes comme Varnish ou un CDN. Il se termine sur les outils de debug indispensables pour comprendre ce qui se passe réellement derrière chaque requête.

Les couches de cache de Drupal

Drupal n'a pas un cache, il en a plusieurs, empilés et complémentaires. Chacun intervient à un niveau différent du cycle de génération d'une page. Les comprendre individuellement est la condition pour les configurer correctement.

Internal Page Cache. C'est le cache le plus agressif et le plus rapide. Il stocke la page HTML complète et la sert telle quelle aux utilisateurs anonymes, sans rebooter Drupal. Une page servie depuis l'Internal Page Cache ne déclenche quasiment aucun traitement PHP. Le module concerné est page_cache. Il ne s'applique qu'aux visiteurs anonymes : dès qu'un utilisateur est connecté, ce cache est court-circuité.

Dynamic Page Cache. Conçu pour les pages qui contiennent des éléments personnalisés, il fonctionne pour les utilisateurs anonymes comme connectés. Le principe : Drupal met en cache la majorité de la page et ne recalcule que les fragments réellement dynamiques (le bloc « Bonjour, prénom », un panier, un menu personnalisé). Ces fragments dynamiques sont identifiés par des #cache placeholders. Le module concerné est dynamic_page_cache.

Render cache. En dessous des deux précédents, le render cache met en cache des éléments de rendu individuels : un bloc, une vue, un champ, un nœud rendu dans un teaser. C'est la brique fondamentale sur laquelle reposent les couches supérieures. Chaque élément de rendu déclare ses métadonnées de cache (tags, contexts, max-age), ce qui permet à Drupal de savoir précisément quand le réutiliser et quand le régénérer.

BigPipe. BigPipe ne stocke rien, il change la façon de livrer la page. Plutôt que d'attendre que tous les fragments dynamiques soient calculés avant d'envoyer quoi que ce soit, BigPipe envoie immédiatement la partie cachée de la page, puis injecte les fragments personnalisés au fur et à mesure de leur calcul. Le résultat perçu : une page qui s'affiche presque instantanément, les zones personnalisées se remplissant en streaming. C'est particulièrement efficace pour les utilisateurs connectés.

Quand utiliser quoi

Ces couches ne sont pas mutuellement exclusives, elles travaillent ensemble. La logique de répartition est cependant claire.

Pour un site majoritairement anonyme (site vitrine, média, documentation), l'Internal Page Cache fait l'essentiel du travail. Activez-le et assurez-vous qu'il fonctionne : une page servie depuis ce cache coûte presque zéro ressource. C'est le levier de performance numéro un pour ce type de site.

Pour un site avec beaucoup d'utilisateurs connectés (intranet, plateforme, espace membre), l'Internal Page Cache ne sert à rien puisqu'il ne couvre que les anonymes. Ce sont alors le Dynamic Page Cache et BigPipe qui prennent le relais. Le Dynamic Page Cache mutualise tout ce qui est commun entre les utilisateurs, BigPipe accélère la perception de chargement des parties personnalisées.

Pour les éléments réutilisés partout (un bloc d'actualités présent sur toutes les pages, une vue de produits en vedette), le render cache évite de recalculer le même fragment des dizaines de fois. C'est transparent dès lors que vos modules et vos thèmes déclarent correctement leurs métadonnées de cache.

En pratique, sur la plupart des projets, on active ces couches ensemble et on laisse Drupal arbitrer. Le travail d'expert consiste surtout à vérifier que rien ne casse la cacheabilité d'une page (un bloc mal codé peut, à lui seul, rendre toute une page non cacheable).

La configuration optimale

Drupal arrive avec une configuration de cache raisonnable par défaut, mais quelques réglages méritent attention pour un site en production.

Activez les modules de cache. Internal Page Cache et Dynamic Page Cache sont activables depuis l'interface ou en ligne de commande. BigPipe est inclus dans le core et activé par défaut sur le profil standard.

drush en page_cache dynamic_page_cache big_pipe -y

Configurez la durée de vie du cache pour les pages anonymes. Dans l'interface, sous Configuration puis Développement puis Performance, le réglage « Browser and proxy cache maximum age » définit le max-age envoyé aux navigateurs et aux proxies. Une valeur de 15 minutes à plusieurs heures convient à la plupart des sites de contenu. Plus elle est élevée, plus le cache est efficace, mais plus le rafraîchissement est lent (l'invalidation par cache tags, détaillée plus bas, compense ce compromis).

Agrégez le CSS et le JavaScript. Toujours dans Performance, activez l'agrégation des fichiers CSS et JS. Cela réduit le nombre de requêtes et améliore le temps de chargement perçu, un facteur que nous détaillons dans notre guide SEO technique Drupal puisqu'il pèse directement sur les Core Web Vitals.

Utilisez un backend de cache rapide en production. Par défaut, Drupal stocke ses caches en base de données. Pour un site à fort trafic, déporter le cache vers Redis ou Memcached réduit la charge sur la base et accélère les lectures. C'est une optimisation à envisager dès que le volume de pages cachées devient important.

Cache tags et invalidation

C'est ici que se joue l'élégance du système de cache de Drupal, et aussi la source de la plupart des incompréhensions.

Le problème fondamental du cache est l'invalidation : comment savoir quand une page cachée n'est plus à jour ? Drupal résout cela avec les cache tags. Chaque élément caché est étiqueté avec les identifiants des données dont il dépend. Un nœud rendu porte par exemple le tag node:42. Une vue qui liste des articles porte les tags de chacun des nœuds affichés.

Quand le nœud 42 est modifié, Drupal invalide tous les caches portant le tag node:42, où qu'ils soient : la page du nœud, la page d'accueil qui l'affiche en teaser, le fil RSS, le bloc d'articles récents. L'invalidation est ciblée et automatique. Vous n'avez pas à vider le cache manuellement à chaque modification de contenu, ce qui serait à la fois lourd et destructeur de performance.

À côté des cache tags, deux autres métadonnées complètent le tableau :

Cache contexts. Ils décrivent les variations d'une page selon le contexte de la requête : la langue (languages), l'utilisateur (user), les permissions (user.permissions), le thème, les paramètres d'URL. Un bloc qui affiche le nom de l'utilisateur déclare le contexte user, ce qui indique à Drupal de stocker une variante par utilisateur.

Cache max-age. La durée de vie maximale d'un élément, en secondes. La valeur Cache::PERMANENT signifie « garde jusqu'à invalidation par un tag ». La valeur 0 signifie « jamais cacheable ».

La règle d'or pour les développeurs : tout code custom qui génère du rendu doit déclarer ses métadonnées de cache. Un module qui oublie de poser ses cache tags produira soit des contenus périmés, soit des pages non cacheables qui plombent la performance. C'est l'un des points que nous auditons systématiquement, car un seul bloc mal codé peut neutraliser tout le bénéfice du cache sur une page entière.

Pour vider le cache manuellement pendant un déploiement ou un debug, drush reste l'outil de référence.

drush cache:rebuild

Les solutions externes : Varnish, CDN, Cloudflare

Le cache interne de Drupal est puissant, mais la requête doit tout de même atteindre votre serveur PHP. Pour les sites à fort trafic, on ajoute une couche de cache en amont, qui répond avant même que la requête n'arrive à Drupal.

Varnish. Un reverse proxy cache placé devant Drupal. Il intercepte les requêtes des utilisateurs anonymes et sert la page cachée sans solliciter PHP du tout. Le gain est spectaculaire sur un site de contenu : Varnish peut absorber des milliers de requêtes par seconde là où Drupal en servirait beaucoup moins. Le module purge couplé à varnish_purge permet de propager l'invalidation par cache tags jusqu'à Varnish, ce qui maintient la cohérence du contenu.

CDN et Cloudflare. Un CDN distribue le cache géographiquement, au plus près des visiteurs. Les ressources statiques (images, CSS, JS) en bénéficient immédiatement. Avec une configuration adaptée, les pages HTML elles-mêmes peuvent être cachées au niveau du CDN, là encore avec propagation des cache tags pour invalider proprement. Cloudflare, par exemple, supporte la purge par tags sur ses offres adaptées.

Ces solutions sont complémentaires du cache Drupal, pas concurrentes. La bonne architecture empile les couches : CDN ou Varnish en frontal pour les anonymes, cache Drupal interne pour tout le reste. Le maintien de cette chaîne dans le temps (vérifier que l'invalidation se propage bien à chaque couche après les mises à jour) fait partie intégrante d'une bonne maintenance Drupal.

Débugger le cache

Quand une page ne se rafraîchit pas ou ne se cache pas comme prévu, le diagnostic passe par les en-têtes HTTP que Drupal expose en environnement de développement.

X-Drupal-Cache. Indique le statut de l'Internal Page Cache pour la requête. La valeur HIT signifie que la page a été servie depuis le cache, MISS qu'elle a été générée puis mise en cache.

X-Drupal-Dynamic-Cache. Même logique pour le Dynamic Page Cache : HIT, MISS ou UNCACHEABLE si la page n'est pas cacheable du tout (souvent le symptôme d'un max-age à zéro posé quelque part dans le rendu).

Pour inspecter ces en-têtes rapidement, une simple requête en ligne de commande suffit.

curl -sI https://votre-site.example/page | grep -i x-drupal

Un MISS systématique sur une page qui devrait être cachée est le signal qu'un élément casse la cacheabilité. À l'inverse, un HIT sur une page qui affiche du contenu périmé indique une invalidation par cache tags défaillante. Activer les en-têtes de debug des cache tags (via le paramètre http.response.debug_cacheability_headers dans services.yml) expose les tags et contexts de chaque réponse, ce qui permet de remonter à la source du problème.

Le débogage du cache est souvent l'aspect le plus subtil d'un projet Drupal, parce qu'il croise le code custom, la configuration et l'infrastructure. C'est aussi l'un des plus rentables : chaque page correctement cachée est servie plus vite, consomme moins de serveur et satisfait davantage vos visiteurs comme les moteurs de recherche.

Votre site Drupal est lent ou affiche des contenus périmés sans explication évidente ? Le cache est presque toujours le premier endroit où regarder. Parlons de votre projet pour un diagnostic de performance et une configuration de cache adaptée à votre trafic.