Core Web Vitals sur Drupal : diagnostic et corrections qui marchent
Les Core Web Vitals sont l’un des rares sujets où le SEO et l’expérience utilisateur disent exactement la même chose : un site lent perd des positions et des visiteurs. Drupal peut être remarquablement rapide — le cache de pages de core est excellent — mais la plupart des sites Drupal que j’audite laissent des points énormes sur la table. Mon ancien site personnel en était l’exemple parfait : 58 feuilles de style bloquantes pour une seule page. Voici la méthode que j’applique en mission.
D’abord : mesurer au bon endroit
- Les données terrain priment. Google classe sur les données réelles des utilisateurs Chrome (CrUX), visibles dans Search Console (rapport « Signaux Web essentiels ») et PageSpeed Insights. Lighthouse en local est un outil de diagnostic, pas la note finale.
- Les trois métriques qui comptent : LCP (chargement de l’élément principal, < 2,5 s), INP (réactivité aux interactions, < 200 ms), CLS (stabilité visuelle, < 0,1).
- Diagnostiquez par gabarit (accueil, article, listing), pas page par page : sur un CMS, les problèmes sont structurels.
LCP : les suspects habituels côté Drupal
- Cache mal exploité. Page cache pour les anonymes, Dynamic Page Cache pour les connectés, et surtout des
cache tags propres dans vos blocs custom — un
#cache max-age: 0oublié dans un bloc peut désactiver le cache de toutes les pages qui l’affichent. C’est le bug de performance le plus coûteux et le plus courant. - L’agrégation CSS/JS désactivée (souvent « temporairement », depuis deux ans). Core sait agréger et minifier : activez, vérifiez, oubliez.
- L’image LCP maltraitée. Utilisez les styles d’images responsives, servez du WebP (core le fait depuis
Drupal 10), dimensionnez correctement — et surtout : pas de lazy loading sur l’image principale. Drupal met
loading="lazy"par défaut sur les images de contenu ; l’image du hero doit être eneageravecfetchpriority="high". - Les fonts tierces. Auto-hébergez, sous-ensemble,
font-display: swap, préchargez la police du titre. Unfonts.googleapis.combloquant dans le<head>se paie cash sur le LCP. - Le TTFB d’hébergement. Si le HTML met 800 ms à sortir, rien côté front ne vous sauvera. Cache HTTP devant Drupal (Varnish, CDN) pour les anonymes.
INP : la métrique qui a remplacé le confort
L’INP mesure la réactivité de toutes les interactions. Sur Drupal, les coupables classiques :
- L’empilement de bibliothèques : jQuery + plugins d’un autre âge + trois trackers. Chaque script tiers est une taxe sur le thread principal — le tag manager « temporaire » du marketing en tête.
- Des handlers lourds attachés à tout le document.
once()et la délégation d’événements existent pour ça. - Le remède structurel : charger moins de JavaScript. Les
librariesde Drupal permettent un chargement par composant — servez le JS du carrousel uniquement là où il y a un carrousel.
CLS : la stabilité, c’est de la discipline
- Dimensions explicites sur toutes les images et iframes (width/height ou aspect-ratio) — les styles d’images de Drupal les fournissent, ne les supprimez pas au thème.
- Réservez l’espace des zones dynamiques : pubs, embeds, bannières de consentement (la bannière cookies qui pousse toute la page est un classique).
- Fonts avec fallback métrique (
size-adjust) pour éviter le saut au swap.
La checklist de sortie
Dans l’ordre où je les traite en audit : cache tags et page cache vérifiés → agrégation activée → image LCP en eager + WebP + dimensionnée → fonts auto-hébergées et préchargées → inventaire JS tiers (supprimer avant d’optimiser) → dimensions partout → re-mesure CrUX à 28 jours (le rapport terrain est une moyenne glissante : la patience fait partie de la méthode).
Rien d’exotique : de la discipline, appliquée dans le bon ordre. C’est précisément ce qu’un audit SEO technique livre — le diagnostic chiffré, et les corrections implémentées.