Drupal vs WordPress : ce que révèlent les Core Web Vitals de près de 2,9 millions de sites réels

Une comparaison fondée sur des données réelles, pas sur des tests de laboratoire

La plupart des comparatifs de performance entre Drupal et WordPress reposent sur des tests de deux installations de démonstration, avec des thèmes choisis à la main. Ce type de mesure ne dit rien de la réalité du terrain. L'analyse publiée par l'agence Gspikes adopte une autre approche : elle exploite le Chrome UX Report (CrUX, la base de données de Google qui enregistre les Core Web Vitals mesurés auprès des vrais utilisateurs de Chrome), agrégé chaque mois par CMS via le HTTP Archive.

L'échantillon relève quasiment du recensement : en juillet 2026, les données mobiles couvraient 92 822 sites Drupal et 2 762 568 sites WordPress, soit près de 2,9 millions de sites au total. La série remonte à janvier 2020, soit 79 relevés mensuels consécutifs.

Les chiffres clés : un écart de 15 points, jamais démenti en 79 mois

Les Core Web Vitals (CWV) sont les trois métriques d'expérience utilisateur mesurées sur le terrain par Google : le LCP (Largest Contentful Paint, vitesse d'affichage du contenu principal, bon si ≤ 2,5 s), le CLS (Cumulative Layout Shift, stabilité visuelle de la page, bon si ≤ 0,1) et l'INP (Interaction to Next Paint, réactivité aux interactions, bon si ≤ 200 ms). Un site « passe » lorsque les trois métriques sont bonnes pour au moins 75 % des visites réelles. Depuis la mise à jour Page Experience de juin 2021, elles constituent un signal de classement confirmé, quoique modeste, pour Google.

• En juillet 2026 sur mobile, 64,5 % des sites Drupal passent les trois Core Web Vitals, contre 49,5 % des sites WordPress : un écart de 15 points.
• Drupal devance WordPress sur chacun des 79 relevés mensuels depuis janvier 2020 ; l'écart n'est jamais descendu sous 11,3 points ni monté au-dessus de 20,9 points.
• Drupal dépasse aussi la moyenne de l'ensemble du web (53,2 %) de 11 points, tandis que WordPress se situe 4 points en dessous.
• Sur desktop, la hiérarchie est identique : 65,0 % pour Drupal contre 53,6 % pour WordPress.

Point important : les deux plateformes ont énormément progressé. Drupal est passé de 27,4 % de sites conformes en janvier 2020 à 64,5 %, WordPress de 13,9 % à 49,5 %. Le web entier est devenu plus rapide, mais le classement n'a jamais changé.

Où se joue vraiment l'écart : le chargement, pas l'interactivité

Le détail par métrique dissipe le mystère. Sur le CLS (88,2 % contre 87,1 %) et l'INP (90,0 % contre 91,0 %, où WordPress est même légèrement devant), les deux écosystèmes sont au coude à coude : la stabilité visuelle dépend surtout de la qualité du thème, et aucun des deux CMS n'embarque par défaut assez de JavaScript pour dégrader la réactivité.

Tout l'écart se concentre sur le LCP : 75,6 % pour Drupal contre 56,6 % pour WordPress, soit 19 points. Et derrière le LCP, le CrUX suit également le TTFB (Time to First Byte, le temps de réponse pur du serveur, avant tout travail côté navigateur) : 45,5 % des sites Drupal obtiennent un bon TTFB contre 24,4 % des sites WordPress. C'est le plus gros écart de toutes les métriques : la course se joue avant même que le premier pixel ne s'affiche. Autrement dit, un site WordPress a environ deux fois moins de chances de répondre rapidement côté serveur.

La nuance essentielle : on compare des parcs de sites, pas des moteurs

L'analyse a le mérite d'expliciter sa limite : ces données ne prouvent pas que le code de Drupal est intrinsèquement plus rapide que celui de WordPress. Le CrUX mesure des sites déployés, et les deux parcs ne se ressemblent pas. WordPress équipe environ 43 % du web, un parc qui inclut des millions de sites sur hébergement mutualisé à bas coût, des blogs abandonnés et des installations chargées de dizaines d'extensions non auditées. Les quelque 93 000 sites Drupal mesurés penchent fortement vers des sites construits et hébergés par des professionnels — administrations, universités, grandes entreprises — car c'est ce public qui choisit Drupal. Une partie de l'écart relève donc d'un effet de sélection : les sites dotés de budgets d'ingénierie sont plus rapides, quelle que soit la plateforme.

Mais cette explication a ses limites, pour deux raisons documentées. D'abord, l'écart persiste en haut du marché : lorsque le HTTP Archive filtre la comparaison sur les sites à fort trafic — où les deux plateformes sont gérées professionnellement — l'avance de Drupal demeure. Ensuite, l'architecture n'est pas neutre : le cœur de Drupal embarque nativement le cache de rendu, le cache de page dynamique et BigPipe (une technique d'envoi progressif de la page), si bien qu'une installation Drupal standard sert les requêtes répétées depuis le cache avant même que PHP ne s'exécute. Une installation WordPress standard, elle, exécute toute sa chaîne d'extensions à chaque requête non mise en cache et délègue le cache de page à des plugins ou à l'hébergeur. À l'échelle d'un parc, la performance activée par défaut l'emporte sur la performance en option — et le TTFB est précisément là où cela se voit.

Les leviers d'optimisation, plateforme par plateforme

L'analyse propose une grille de lecture utile : chaque requête traverse quatre étages — hébergement et edge, environnement serveur, configuration du CMS, front-end. L'écart de 21 points sur le TTFB se situe sur les deux étages du bas, ce qui signifie que beaucoup de budgets performance sont dépensés au mauvais endroit : l'optimisation des images ne rattrapera jamais un premier octet lent.

Côté Drupal : ne pas casser ce que le cœur offre déjà

• Conserver le Dynamic Page Cache et BigPipe activés.
• Maintenir des tags de cache cohérents dans le code sur mesure, pour ne pas invalider le cache à tort.
• Placer un CDN (réseau de diffusion de contenu) devant le site et dimensionner l'hébergement en fonction du trafic réel.

Selon l'analyse, un site Drupal avec un mauvais TTFB souffre presque toujours d'un cache contourné par un module mal conçu ou d'un serveur d'origine sous-dimensionné.

Côté WordPress : reconstruire l'étage serveur en priorité

• Un hébergement sérieux avec cache de page au niveau serveur.
• Un plugin de cache pleine page correctement configuré pour être réellement sollicité.
• Un cache objet (Redis) et PHP 8.3 ou plus récent.
• Un véritable audit des extensions : chaque plugin actif s'exécute à chaque requête non cachée, et le faible taux de bons TTFB du parc WordPress est en grande partie un problème de nombre d'extensions.

Le travail front-end (images AVIF, CSS critique, chargement des polices) vient après que le premier octet est rapide, pas à sa place.

Ce que cela implique pour un choix de plateforme

Les Core Web Vitals restent un facteur de classement modeste : le contenu et les liens décident encore de l'essentiel du référencement. En revanche, ils constituent un facteur de conversion sans réserve : un chargement plus lent coûte mesurablement du chiffre d'affaires. Pour un site organisationnel riche en contenu, les données de terrain indiquent que le résultat médian sur Drupal est un site conforme aux CWV, et le résultat médian sur WordPress un site non conforme — avec la réserve que le budget d'ingénierie, et pas seulement la plateforme, explique une partie de cet écart. Un site WordPress bien construit passe les Core Web Vitals sans difficulté ; c'est la moyenne du parc qui n'y parvient pas.