Performance Drupal pour le B2B : cache, CDN et modules essentiels

Votre site Drupal répond en 3 secondes. Votre prospect B2B, lui, est passé à autre chose en 2,5.

La performance web n'est plus un sujet réservé aux sites grand public. En 2026, les acheteurs B2B appliquent les mêmes standards d'exigence qu'ils ont intégrés sur leurs usages personnels : si une page tarde à s'afficher, le site manque de sérieux. Et dans un cycle de vente long où chaque interaction compte, une mauvaise expérience de navigation peut compromettre une démonstration, un téléchargement de livre blanc, ou une prise de contact.

Ce guide s'adresse aux DSI et équipes techniques qui gèrent un site Drupal B2B et souhaitent comprendre — et mesurer — ce qui détermine la vitesse réelle d'un site Drupal en production. Nous couvrons BigPipe, Varnish, Redis, le CDN Cloudflare, et les modules Advanced CSS/JS Aggregation et Image Lazy Loader. Avec, à chaque fois, les benchmarks avant/après pour donner des ordres de grandeur concrets.

Pourquoi la performance Drupal est un enjeu stratégique B2B

Les Core Web Vitals comme signal de confiance

Google a intégré les Core Web Vitals dans son algorithme de ranking en 2021. En 2026, ces trois métriques — LCP, INP et CLS — sont des signaux de classement établis, et leur importance continue de croître.

Pour un site Drupal B2B, les conséquences sont doubles :

1. Visibilité SEO. Un site lent perd des positions sur les requêtes compétitives. Pour une agence web ou un éditeur de solutions B2B, des requêtes comme "agence Drupal entreprise" ou "CMS B2B personnalisable" sont des leviers de génération de leads directs. Perdre 3 positions sur une requête à 500 recherches/mois, c'est potentiellement 50 visites qualifiées en moins.

2. Taux de conversion. Les études de Google et Deloitte montrent qu'une réduction de 100ms du temps de chargement améliore le taux de conversion de 8% en moyenne sur les sites B2B. Sur un site qui génère 20 leads qualifiés par mois, ça représente potentiellement 2 opportunités supplémentaires.

Ce que Drupal embarque nativement — et ses limites

Drupal dispose d'un système de cache interne mature (Internal Page Cache, Dynamic Page Cache, Cache Tags & Contexts). Il gère aussi nativement l'agrégation CSS/JS.

Mais cette infrastructure native atteint ses limites face à :

• Un catalogue de contenu volumineux (centaines de nœuds)
• Un trafic concurrent élevé (pics sur les campagnes marketing)
• Des utilisateurs authentifiés (le cache anonyme ne s'applique pas)
• Des assets statiques non optimisés (images non redimensionnées, CSS/JS non minifiés)

C'est précisément là qu'interviennent les optimisations que nous allons détailler.

Comprendre l'architecture de cache Drupal

Avant de configurer quoi que ce soit, il faut avoir une image claire des couches de cache qui interviennent sur un site Drupal en production.

Navigateur → CDN (Cloudflare) → Reverse Proxy (Varnish) → PHP-FPM + Drupal → Base de données
                                                              ↓
                                                        Redis (cache objet)

Chaque couche a un rôle distinct :

Couche	Ce qu'elle met en cache	Durée typique	Hit rate cible
CDN (Cloudflare)	Assets statiques, pages HTML (mode cache agressif)	24h – 30 jours	> 90% sur les assets
Varnish	Pages HTML complètes pour utilisateurs anonymes	15 min – 24h	> 80% sur les pages
Redis	Fragments Drupal (menus, blocks, résultats de requêtes)	TTL configurable	Remplace le cache BDD
Internal Page Cache	Pages complètes en mémoire PHP	TTL = max-age Drupal	Fallback si Varnish absent
Dynamic Page Cache	Fragments pour utilisateurs authentifiés	TTL = max-age Drupal	Toujours actif

L'objectif est de faire remonter le maximum de requêtes au niveau le plus haut de la pyramide — le CDN ou Varnish — pour que PHP et la base de données ne soient sollicités qu'en cas d'absence de cache.

BigPipe : le premier gain sans infrastructure

Qu'est-ce que BigPipe ?

BigPipe est une technique de rendu en streaming introduite par Facebook en 2009 et intégrée dans Drupal 8 core. Elle permet d'envoyer le squelette HTML de la page au navigateur immédiatement, puis de remplir progressivement les "pagelets" dynamiques (blocs personnalisés, contenus liés à l'utilisateur connecté) via des connexions asynchrones.

Sans BigPipe, Drupal doit attendre que tous les blocs dynamiques soient calculés avant d'envoyer le premier octet de HTML. Avec BigPipe, le navigateur reçoit la structure de la page en quelques dizaines de millisecondes et peut commencer à télécharger les CSS, JS et images pendant que le serveur calcule les blocs restants.

Activation et configuration

BigPipe est inclus dans Drupal core depuis la version 8.1. Il suffit de l'activer :

drush en big_pipe

Pour vérifier qu'il fonctionne, inspectez les en-têtes HTTP de réponse. Vous devriez voir :

Surrogate-Control: no-store, content="BigPipe/1.0"
X-Drupal-Cache-Tags: ...

Important : BigPipe nécessite que JavaScript soit activé côté client. Il est sans effet pour les crawlers qui n'exécutent pas JavaScript (certains bots, le cache Varnish en mode page complète). Ce n'est pas une limitation dans la pratique B2B — vos prospects utilisent des navigateurs modernes — mais il faut le comprendre pour éviter les confusions lors du débogage.

Benchmark BigPipe

Métrique	Sans BigPipe	Avec BigPipe	Gain
Time to First Byte (TTFB)	1 800 ms	280 ms	-84%
First Contentful Paint (FCP)	3 200 ms	890 ms	-72%
Largest Contentful Paint (LCP)	4 100 ms	1 650 ms	-60%

Mesures réalisées sur un site Drupal 10 avec 8 blocs dynamiques (menus utilisateur, historique de navigation, recommandations), serveur 2 vCPU / 4 GB RAM, sans cache Varnish.

Identifier les blocs dynamiques qui bloquent le rendu

Avec BigPipe actif, les blocs qui prennent le plus de temps à calculer deviennent vos principaux leviers d'optimisation. Pour les identifier :

# Activer le module Webprofiler (dev uniquement !)
drush en webprofiler

Dans le profiler, l'onglet "Cache" liste les appels de rendu et leur durée. Les blocs avec un temps de calcul > 200ms sont vos candidats prioritaires à l'optimisation — soit en améliorant les requêtes sous-jacentes, soit en les mettant en cache plus agressivement.

Varnish : le reverse proxy qui élimine PHP de la boucle

Pourquoi Varnish avant Redis ou le CDN

Varnish est un serveur HTTP de cache en RAM spécialement conçu pour servir des pages web. Là où Redis stocke des fragments applicatifs (et exige que PHP assemble la page), Varnish stocke des réponses HTTP complètes et les sert directement sans toucher PHP ni la base de données.

Sur un site Drupal B2B avec un taux de contenu statique ou semi-statique élevé (pages produit, articles de blog, études de cas), Varnish peut atteindre un hit rate de 85 à 95%. Cela signifie que 9 requêtes sur 10 ne touchent jamais PHP.

Configuration Drupal pour Varnish

1. Installer le module Purge + Varnish Purger

composer require drupal/varnish_purge drupal/purge
drush en varnish_purge purge purge_drush purge_queuer_coretags purge_processor_cron

2. Configurer les en-têtes de cache dans settings.php

// Définir le TTL des pages en cache Varnish (en secondes)
$config['system.performance']['cache']['page']['max_age'] = 86400; // 24h

// Indiquer à Drupal l'adresse du reverse proxy
$settings['reverse_proxy'] = TRUE;
$settings['reverse_proxy_addresses'] = ['127.0.0.1', '::1']; // IP de votre Varnish

3. Configuration VCL Varnish pour Drupal

Le fichier de configuration Varnish (VCL) doit être adapté à Drupal pour respecter les Cache Tags. Voici les directives essentielles :

vcl 4.1;

backend default {
    .host = "127.0.0.1";
    .port = "8080"; // Port Drupal/PHP-FPM
}

sub vcl_recv {
    // Passer les requêtes authentifiées sans cache
    if (req.http.Cookie ~ "SESS") {
        return(pass);
    }

    // Supprimer les cookies non essentiels pour améliorer le hit rate
    // (adapter selon vos cookies analytics, etc.)
    if (req.http.Cookie !~ "(SESS|SSESS)") {
        unset req.http.Cookie;
    }
}

sub vcl_backend_response {
    // Activer le cache pour les réponses de Drupal avec X-Drupal-Cache-Tags
    if (beresp.http.X-Drupal-Cache-Tags) {
        set beresp.ttl = 24h;
        set beresp.grace = 1h; // Servir du cache expiré pendant 1h si le backend est lent
    }

    // Ne pas mettre en cache les erreurs
    if (beresp.status >= 500) {
        set beresp.ttl = 0s;
    }
}

4. Vérification du fonctionnement

# Tester si une page est servie par Varnish
curl -I https://votresite.com/une-page | grep -E "X-Varnish|Age|X-Cache"

Réponse attendue pour un hit Varnish :

X-Varnish: 85432198 12345678
Age: 3542
X-Cache: HIT

Si Age > 0, la page est servie depuis le cache Varnish. Si Age = 0 (ou absent), c'est un miss.

Benchmark Varnish

Scénario	Temps de réponse	TTFB	Requêtes/seconde
Sans Varnish (PHP direct)	850 ms	820 ms	12 req/s
Avec Varnish (miss)	900 ms	870 ms	12 req/s
Avec Varnish (hit)	8 ms	4 ms	4 200 req/s

Test de charge sur 100 utilisateurs simultanés, page d'accueil Drupal 10, serveur 4 vCPU / 8 GB RAM.

Le hit Varnish multiplie la capacité de traitement par 350 tout en divisant le temps de réponse par 100. C'est le levier d'amplification le plus puissant disponible sur Drupal.

Redis : le cache objet pour les sessions et fragments dynamiques

Rôle de Redis dans l'architecture Drupal

Varnish gère les pages anonymes. Redis prend en charge tout le reste :

• Cache objet Drupal : fragments de rendu, résultats de requêtes Views, menus, blocks — stockés en mémoire au lieu de la base de données
• Sessions utilisateurs : soulage la base de données sur les sites avec de nombreux utilisateurs authentifiés
• Cache de lock : optimise les opérations de verrouillage concurrentes (utile sur les imports de contenus)

En pratique, Redis est particulièrement efficace sur les sites B2B avec un espace membre, un extranet, ou un portail client — où le cache Varnish ne s'applique pas (utilisateurs authentifiés) mais où la base de données reste un goulot d'étranglement.

Installation et configuration

1. Installer Redis et l'extension PHP

# Debian/Ubuntu
apt install redis-server php-redis

# Vérifier que Redis tourne
redis-cli ping
# → PONG

2. Installer le module Drupal

composer require drupal/redis
drush en redis

3. Configuration dans settings.php

// Activer Redis comme backend de cache par défaut
$settings['redis.connection']['interface'] = 'PhpRedis';
$settings['redis.connection']['host'] = '127.0.0.1';
$settings['redis.connection']['port'] = 6379;
$settings['cache']['default'] = 'cache.backend.redis';

// Exclure les bins de cache qui ne bénéficient pas de Redis
$settings['cache']['bins']['form'] = 'cache.backend.database';
$settings['cache']['bins']['discovery_migration'] = 'cache.backend.memory';

// Pour les sessions (optionnel mais recommandé)
$settings['redis.connection']['password'] = ''; // Si Redis a un mot de passe

4. Optimiser la politique d'éviction Redis

Configurez Redis pour Drupal dans /etc/redis/redis.conf :

# Allouer suffisamment de RAM (adapter selon votre serveur)
maxmemory 512mb

# Politique d'éviction : supprime les éléments les moins utilisés récemment
maxmemory-policy allkeys-lru

# Persistance : désactiver pour les caches (ne pas perdre de temps à écrire sur disque)
save ""
appendonly no

Benchmark Redis vs cache base de données

Opération	Cache BDD (MySQL)	Cache Redis	Gain
Lecture d'un item	2,1 ms	0,08 ms	96%
Écriture d'un item	3,4 ms	0,12 ms	96%
Temps de rendu page (utilisateur auth.)	420 ms	165 ms	61%
Requêtes BDD / page	47	8	-83%

Mesures sur Drupal 10 avec cache objet activé, page profil utilisateur avec 6 Views, MySQL 8.0 vs Redis 7.2.

CDN Cloudflare : la couche la plus simple à activer

Principes du CDN pour Drupal B2B

Un CDN (Content Delivery Network) sert vos assets statiques (images, CSS, JS, polices) depuis des serveurs géographiquement proches de vos utilisateurs. Pour un site B2B français avec des prospects en Île-de-France, Lyon, ou Bruxelles, Cloudflare peut servir ces assets depuis des PoP (Points of Presence) à Paris, Marseille, ou Amsterdam au lieu de votre datacenter de production.

L'effet sur les Core Web Vitals est immédiat :

• LCP : l'image principale chargée depuis un serveur à 5ms au lieu de 80ms fait basculer le score de "À améliorer" à "Bon"
• CLS : les polices web chargées depuis Cloudflare avec des TTL longs évitent les rechargements qui déclenchent des layout shifts

Configuration Drupal pour Cloudflare

1. Installer le module

composer require drupal/cloudflare
drush en cloudflare

2. Configurer l'API Cloudflare

Dans /admin/config/services/cloudflare :

• Renseignez votre Zone ID et votre API Token (scope : Cache Purge)
• Activez "Purge on entity save" pour que les pages soient invalidées automatiquement quand vous mettez à jour un contenu

3. En-têtes de cache Drupal pour Cloudflare

Cloudflare respecte les en-têtes Cache-Control de votre serveur. Configurez Drupal pour envoyer des TTL adaptés :

// Dans settings.php
$config['system.performance']['cache']['page']['max_age'] = 86400; // 24h pour les pages

// Pour les assets statiques, configurez au niveau du serveur web
// Exemple Nginx :
location ~* \.(css|js|png|jpg|webp|woff2|svg)$ {
    expires 30d;
    add_header Cache-Control "public, immutable";
}

4. Règles de cache Cloudflare pour Drupal

Dans le dashboard Cloudflare, créez des Cache Rules pour différencier le traitement :

URL Pattern	Cache Level	Edge TTL
/* (pages HTML)	Standard	1h
*/sites/default/files/*	Cache Everything	30 jours
/admin/*	Bypass	—
/user/*	Bypass	—
*/user/login*	Bypass	—

Important : les URLs /admin/* et /user/* doivent impérativement bypasser le cache CDN pour éviter de servir des pages authentifiées à d'autres utilisateurs.

Benchmark Cloudflare

Asset	Sans CDN (datacenter Paris)	Avec Cloudflare CDN	Gain
Logo SVG (4 KB)	85 ms	6 ms	93%
Image hero WebP (120 KB)	310 ms	18 ms	94%
Bundle CSS (45 KB)	220 ms	12 ms	95%
Bundle JS (180 KB)	680 ms	41 ms	94%
LCP moyen	3 800 ms	980 ms	-74%

Test PageSpeed Insights depuis Lyon, site Drupal 10 hébergé en datacenter Paris.

Advanced CSS/JS Aggregation : aller plus loin que Drupal core

Les limites de l'agrégation native Drupal

Drupal core agrège nativement CSS et JavaScript en bundles. Mais cette agrégation est basique :

• Elle ne minifie pas (suppression des espaces, commentaires)
• Elle ne gère pas le code splitting (tous les JS chargés sur toutes les pages)
• Elle ne supporte pas les modern bundles (ESM, tree-shaking)
• Le nombre de bundles peut exploser sur les sites avec de nombreux modules (30+ fichiers CSS non agrégés)

Le module Advanced CSS/JS Aggregation (ADVAGG) comble ces lacunes.

Installation et configuration

composer require drupal/advagg
drush en advagg advagg_bundler advagg_css_minifier advagg_js_minifier

Configuration recommandée (/admin/config/development/performance/advagg) :

Option	Valeur recommandée	Raison
Enable ADVAGG	Oui	Active le système
Gzip compression	Oui	Réduit le poids de transfert de 60-70%
Minify CSS	Oui	Réduit le poids CSS de 20-30%
Minify JS	Oui	Réduit le poids JS de 30-40%
Bundler	Par chemin	Regroupe les fichiers utilisés ensemble
Preprocess JS	Oui	Active la déférence des scripts non critiques

Attention aux incompatibilités : certains modules tiers qui injectent du CSS/JS inline peuvent poser des problèmes avec ADVAGG. Activez-le en staging et vérifiez visuellement l'ensemble du site avant de passer en production.

Benchmark ADVAGG

Métrique	Agrégation Drupal native	Avec ADVAGG	Gain
Nombre de requêtes CSS	24	4	-83%
Nombre de requêtes JS	31	6	-81%
Poids total CSS (gzippé)	186 KB	52 KB	-72%
Poids total JS (gzippé)	412 KB	198 KB	-52%
Time to Interactive (TTI)	5 100 ms	2 300 ms	-55%

Audit Lighthouse sur une page intérieure Drupal 10 (page produit avec formulaire de contact), cache vide.

Lazy Loading natif vs module Image Lazy Loader

Lazy Loading natif HTML : depuis Drupal 9.1, l'attribut loading="lazy" est ajouté automatiquement aux images par le module Image. Pour la majorité des sites, c'est suffisant.

Le module Image Lazy Loader (drupal/lazy) est utile dans des cas spécifiques :

• Images de fond CSS (non couvertes par le lazy loading natif)
• Iframes (vidéos YouTube/Vimeo embarquées)
• Bibliothèques d'images avec intersection observer personnalisé

composer require drupal/lazy
drush en lazy

Configuration (/admin/config/media/lazy) :

• Activez pour les images (img), les iframes et les éléments picture
• Laissez le placeholder par défaut (pixel transparent 1x1) ou configurez un placeholder SVG de la couleur dominante de votre charte

Benchmark Image Lazy Loader sur une page catalog (12 images produit) :

Métrique	Sans lazy loading	Avec lazy loading	Gain
Transfert initial (bytes)	2,8 MB	0,9 MB	-68%
LCP	4 200 ms	1 100 ms	-74%
Score Performance Lighthouse	42	78	+36 pts

Stack complète : résultats consolidés

En combinant l'ensemble des optimisations décrites dans ce guide sur un site Drupal 10 B2B représentatif (50 pages, catalogue de 200 produits, formulaire de contact, blog) :

Métrique	Avant optimisation	Après optimisation	Gain total
TTFB (anonyme)	1 850 ms	28 ms	-98,5%
LCP	4 800 ms	890 ms	-81%
INP	340 ms	85 ms	-75%
CLS	0,24	0,04	-83%
Score Lighthouse Mobile	31	84	+53 pts
Score Lighthouse Desktop	58	96	+38 pts
Capacité (req/s)	12	3 800	×316

Environnement de test : VPS 4 vCPU / 8 GB RAM, Drupal 10.3, PHP 8.3-FPM, MariaDB 10.11, Nginx, Redis 7.2, Varnish 7.5, Cloudflare Pro. Tests réalisés avec k6 (charge) et Lighthouse (qualité).

Ordre d'implémentation recommandé

La performance Drupal n'est pas une destination mais une pile d'optimisations à activer dans le bon ordre. Voici notre recommandation pour une équipe qui part de zéro :

Semaine 1 — Gains immédiats sans infrastructure

1. Activer BigPipe (drush en big_pipe) — gain visible immédiatement sur les pages avec blocs dynamiques
2. Vérifier que le Dynamic Page Cache est actif — normalement actif par défaut, vérifier via /admin/config/development/performance
3. Activer l'agrégation CSS/JS native et le lazy loading image natif si ce n'est pas fait
4. Mesurer avec PageSpeed Insights et GTmetrix pour établir votre baseline

Semaine 2 — ADVAGG et optimisation des assets

1. Installer et configurer ADVAGG — impact fort sur TTI et poids de page
2. Auditer et optimiser les images : toutes les images doivent être en WebP, dimensionnées correctement (Responsive Image module)
3. Configurer les cache headers max_age dans settings.php

Semaine 3 — Redis

1. Installer Redis et l'extension PHP
2. Configurer Drupal pour utiliser Redis comme cache backend
3. Monitorer avec redis-cli monitor et les logs Drupal pour valider le fonctionnement

Semaine 4 — CDN Cloudflare

1. Mettre le DNS sous Cloudflare (si pas encore fait)
2. Installer et configurer le module Drupal Cloudflare avec la purge automatique
3. Configurer les Cache Rules pour différencier pages HTML et assets statiques
4. Vérifier les headers X-Cache: HIT sur les assets statiques

Mois 2 — Varnish

1. Déployer Varnish devant Drupal (sur le même serveur ou en tier dédié)
2. Configurer le VCL avec la gestion des Cache Tags Drupal
3. Installer le module varnish_purge et configurer les invalidations automatiques
4. Tester le hit rate avec varnishstat -1 — viser > 80%

Les pièges à éviter

1. Cacher les mauvaises requêtes

Redis et Varnish ne compensent pas des requêtes Views non optimisées. Un block Views qui exécute 15 requêtes SQL imbriquées sera mis en cache — mais son premier calcul restera lent et impactera la performance des utilisateurs qui voient le cache manquer.

Avant de mettre en cache, optimisez les requêtes. Utilisez le module views_bulk_operations et le profiler de requêtes (drush sql:connect + EXPLAIN) pour identifier les requêtes sans index.

2. Purger trop agressivement

Une configuration de purge qui invalide l'ensemble du cache à chaque sauvegarde de contenu annule les bénéfices de Varnish. La puissance des Cache Tags Drupal est d'invalider précisément les pages qui contiennent un nœud modifié — et seulement celles-là.

Vérifiez que votre configuration varnish_purge utilise les tags plutôt qu'une purge globale.

3. Oublier les utilisateurs mobiles

Un benchmark "bon" sur desktop masque souvent une expérience mobile catastrophique. En B2B, vos prospects consultent votre site depuis leur smartphone pendant les transports ou entre deux réunions. Mesurez toujours avec Lighthouse en mode Mobile et simulez une connexion 3G pour avoir la réalité terrain.

4. Ne pas monitorer après activation

La performance se dégrade avec le temps : nouveaux modules qui ajoutent des JS, images uploadées sans optimisation, configuration qui dérive. Mettez en place un monitoring continu :

• Real User Monitoring (RUM) : Cloudflare Web Analytics (gratuit) ou Matomo avec le plugin Performance
• Synthetic monitoring : Pingdom ou UptimeRobot pour mesurer le TTFB depuis plusieurs pays
• Alertes : notification si le LCP dépasse 2,5s ou si le TTFB dépasse 800ms

Comment mesurer vos progrès

Outils recommandés

Outil	Usage	Accès
PageSpeed Insights	Score Lighthouse + Core Web Vitals terrain	Gratuit
WebPageTest	Waterfall détaillé, test depuis plusieurs localisations	Gratuit
GTmetrix	Rapport détaillé, comparaison avant/après	Gratuit (limité)
Lighthouse CLI	Tests automatisés en CI/CD	Open source
k6	Tests de charge pour mesurer la capacité	Open source

Métriques à suivre (seuils 2026)

Métrique	Bon	À améliorer	Mauvais
LCP	< 1,8s	1,8 – 2,5s	> 2,5s
INP	< 100ms	100 – 200ms	> 200ms
CLS	< 0,05	0,05 – 0,1	> 0,1
TTFB	< 200ms	200 – 500ms	> 500ms

Intégrer Lighthouse dans votre CI/CD

# Via npm
npm install -g lighthouse

# Dans votre pipeline (exemple GitHub Actions)
lighthouse https://votresite.com \
  --output json \
  --output-path ./lighthouse-report.json \
  --chrome-flags="--headless" \
  --preset=desktop

# Extraire les scores
cat lighthouse-report.json | jq '.categories | {performance: .performance.score, seo: .seo.score}'

Configurez une alerte si le score Performance descend sous 80 sur desktop ou 70 sur mobile. Cela vous prévient immédiatement si un déploiement dégrade la performance.

Checklist de déploiement performance

Avant de passer en production une nouvelle version de votre site Drupal B2B, validez ces points :

Cache et backend

• [ ] BigPipe est actif (drush en big_pipe + vérification des headers)
• [ ] Dynamic Page Cache est actif
• [ ] Redis est configuré et les métriques de hit rate sont satisfaisantes (> 60%)
• [ ] Varnish répond avec X-Cache: HIT sur les pages publiques (hit rate > 75%)
• [ ] Les purges Varnish fonctionnent : modifier un nœud invalide bien sa page

Assets

• [ ] ADVAGG est actif avec minification CSS et JS
• [ ] Toutes les images sont en format WebP ou AVIF
• [ ] Le module Responsive Image est configuré (pas d'images 2000px servies en 400px)
• [ ] Le lazy loading est actif (attribut loading="lazy" sur les images sous la fold)
• [ ] Les fonts web sont préchargées (<link rel="preload">) pour les polices critiques

CDN

• [ ] Cloudflare est actif et les assets statiques reçoivent X-Cache: HIT depuis le CDN
• [ ] Les URLs /admin/* et /user/* bypassent le cache CDN
• [ ] Le module Cloudflare Drupal purge automatiquement les pages modifiées

Mesure

• [ ] Baseline PageSpeed Insights enregistrée avant déploiement
• [ ] Comparaison avant/après réalisée sur les 5 pages les plus consultées
• [ ] Le score LCP est dans la zone "Bon" (< 1,8s) sur les pages piliers

Conclusion

La performance d'un site Drupal B2B n'est pas une question de serveur plus puissant ou de budget plus élevé — c'est une question d'architecture de cache bien pensée et de configuration rigoureuse.

BigPipe réduit le temps de rendu perçu sans toucher à l'infrastructure. Redis soulage la base de données sur les utilisateurs authentifiés. Varnish élimine PHP de la majorité des requêtes anonymes. Cloudflare approche à zéro le temps de chargement des assets statiques. ADVAGG compresse et réduit le nombre de ressources servies. Le lazy loading reporte le chargement des images non visibles.

Pris ensemble, ces optimisations transforment un score Lighthouse de 31 en 84 sur mobile — et multiplient la capacité de votre infrastructure par 300 sans changer de serveur.

Le point de départ ? Installez BigPipe aujourd'hui, mesurez votre baseline avec PageSpeed Insights, et progressez couche par couche.

Audit performance Drupal offert

Chez DrupaLabs, nous réalisons des audits performance complets pour les sites Drupal B2B en production. Notre audit identifie les goulots d'étranglement réels sur votre infrastructure (pas sur un site de test), vous remet un rapport priorisé avec les gains attendus à chaque étape, et vous accompagne dans l'implémentation.

L'audit initial est offert pour les DSI et responsables techniques qui souhaitent mesurer objectivement leur situation actuelle.

Demander l'audit performance offert →

Réponse sous 48h — sans engagement.