Le dernier rapport Core Web Vitals Technology Report (juillet 2025) ne fait pas de cadeau :
- Duda (Website Builder SaaS) domine avec 84,96 % de sites au vert.
- Wix progresse fortement (73,37 %).
- WordPress, pourtant utilisé par 43 % des sites dans le monde, stagne à 44,34 % — dernier du classement, avec la plus faible amélioration mensuelle (+0,90 %).
Beaucoup en concluent que « WordPress est lent ».
Mais ce n’est pas le CMS qui est en cause. C’est l’écosystème qu’on lui impose.
Le vrai problème : la gouvernance technique, pas le noyau
WordPress n’est pas un SaaS verrouillé comme Duda ou Wix.
Il est ouvert, extensible, décentralisé — ce qui est une force… à condition de maîtriser les conséquences.
Dans les faits, les sites WordPress que j’audite (TPE, consultants, artisans) souffrent systématiquement des mêmes travers :
- 18 à 25 plugins actifs, souvent redondants (ex. : 2 outils de formulaire, 3 plugins SEO, un page builder + thème « tout-en-un »).
- Thèmes multipurpose non customisés (génériques non personnalisés), qui embarquent des dizaines de scripts, styles et polices inutilisés.
- Hébergement mutualisé bas de gamme, sans cache objet, sans CDN, parfois sans HTTP/2.
- Polices Google chargées en externe (pas de self-host / pas de preload), Widgets sociaux embarqués sans proxy ni lazy-loading , Scripts de tracking chargés sans différé / async (Meta Pixel, GA4, Tag Manager…)
Résultat ?
- INP entre 350 et 450 ms (échec selon les seuils Google).
- LCP > 3 s.
- CLS instable sur mobile (surtout à cause d’éléments injectés tardivement).
Pourtant, ces sites n’ont rien de complexe : vitrines, blogs, petites boutiques simples.
La bonne nouvelle : la performance est récupérable — rapidement
Sur les quatre derniers audits que j’ai menés, des interventions légères (moins de 8h par site) ont permis de récupérer 40 à 60 % de performance en 5 actions simples :
- Réduire la dette plugin
- Désactiver 8 à 12 plugins non essentiels
- Fusionner leurs fonctionnalités avec des blocs natifs Gutenberg, CSS minimal, ou code léger (mu-plugins)
- Remplacer les plugins lourds (page builders, sliders, formulaires premium) par des alternatives natives
- Désencombrer le frontend
- Supprimer les assets non critiques (CSS/JS inutiles par page)
- Activer lazy-loading natif (loading= »lazy »)
- Donner une priorité de rendu à l’image principale (fetchpriority= »high » + decoding= »async »)
- Optimiser les polices
- Charger les polices en local (éviter Google Fonts externes)
- Utiliser font-display: swap
- Limiter à 2 familles max et 3 graisses maximum
- Charger les polices en preload sélectif
- Améliorer le cache
- Installer un plugin léger (Cache : LiteSpeed Cache / FlyingPress / WP Rocket)
- Activer Object Cache (Redis ou Memcached)
- Mettre en cache les fragments dynamiques (panier WooCommerce, filtres)
- Changer d’hébergement si nécessaire
- Passer sur un hébergeur performant (latence basse + CPU récent)
- Recommandations fiables : o2switch (budget), Hostinger (LiteSpeed), Kinsta ou Rocket.net (premium)
Résultat après 7–10 jours (données CrUX stabilisées) :
- INP < 100 ms
- LCP < 1,8 s
- CLS < 0,05
| Core Web Vital | Objectif recommandé | Ce que ça mesure |
|---|---|---|
| INP (Interaction to Next Paint) | < 100 ms | Réactivité du site lors des interactions (clics, formulaires, menus) |
| LCP (Largest Contentful Paint) | < 1,8 s | Temps d’affichage du contenu principal d’une page |
| CLS (Cumulative Layout Shift) | < 0,05 | Stabilité visuelle (pas de décalage de blocs/images pendant le chargement) |
Ces scores sont mesurés en données réelles utilisateurs (field data) par Chrome UX Report (CrUX), pas juste via Lighthouse.
CDN ou pas CDN ? Une approche pragmatique
L’usage d’un CDN comme Cloudflare ou BunnyCDN peut améliorer les performances d’un site, mais il n’est pas obligatoire. Lorsqu’un site cible un public local (France, Belgique, Suisse, Canada francophone) et qu’il repose sur un hébergement performant (ex. LiteSpeed chez o2switch), il est tout à fait possible d’obtenir de très bons Core Web Vitals sans CDN.
Un CDN devient utile principalement dans trois cas :
- Trafic international ou multi-pays
- Très gros volume d’images ou de fichiers statiques
- Sécurité renforcée (WAF, DDoS, règles avancées)
Cependant, un CDN peut parfois créer plus de problèmes qu’il n’en résout :
- Cache trop agressif : erreurs de mise à jour
- Conflits avec WordPress (API REST, AJAX, WooCommerce)
- Temps perdu dans le multi-cache (plugin + serveur + CDN)
L’approche la plus efficace reste simple : d’abord optimiser le site à la source, ensuite seulement envisager un CDN si nécessaire.
Priorités avant d’ajouter un CDN :
- Optimisation des polices (local + preload)
- Réduction du JS externe
- Lazy loading natif des médias
- Cache serveur + HTML propre
- Compression Brotli + HTTP/3 (déjà dispo sans CDN selon hébergeur)
Pourquoi ça compte — au-delà du SEO
On parle souvent de Core Web Vitals comme un critère Google.
Mais INP, LCP, CLS sont avant tout des métriques UX :
- Un INP élevé = frustration pour un utilisateur dyspraxique (trouble de la coordination motrice et de la planification des gestes) ou malvoyant qui clique et n’obtient pas de feedback visuel.
- Un LCP lent = abandon sur mobile, surtout en zone rurale ou avec un forfait limité.
- Un CLS instable = erreur de clic, confusion, exclusion cognitive.
La performance web, c’est de l’accessibilité.
Et WordPress, justement, reste le CMS le plus adapté pour construire des expériences inclusives — à condition de ne pas le laisser se noyer sous la dette technique.
La performance, ça se voit. Même quand on dit le contraire
Si le site répond en moins de 100 ms, l’utilisateur a l’impression que ça marche.
Un site qui réagit lentement après un clic ? S’il attend 300 ms ou plus, il pense que c’est cassé. Il part.
Ce n’est pas un problème de « score Google ». C’est un problème de première impression.
WordPress n’est pas condamné à être lent. Il est condamné à être mal configuré quand on le traite comme une boîte magique « installe-et-oublie ».
Le fossé n’est pas entre Duda et WordPress. Il est entre ceux qui considèrent la performance comme un luxe… et ceux qui la traitent comme une exigence éthique.
Et dans ce match, WordPress peut gagner — à chaque fois.
Sources :
Search Engine Journal WordPress versus Everyone
Juillet 2025 – Core Web Vitals CWV par CMS (Source : HTTP Archive + CrUX)
- Duda : 84,96 %
- Wix : 73,37 %
- Squarespace : 68,93 %
- Drupal : 60,54 %
- Joomla : 54,78 %
- WordPress : 44,34 %
