Core Web Vitals : le verdict des chiffres
Depuis mai 2021, Google intègre les Core Web Vitals (CWV) dans son algorithme de classement via le signal "Page Experience". Ce ne sont pas des métriques abstraites : elles mesurent ce que l'utilisateur ressent réellement — le temps avant que la page affiche quelque chose, le temps avant qu'il puisse interagir, et la stabilité visuelle pendant le chargement.
Les trois métriques sont :
- LCP — Largest Contentful Paint : temps d'affichage du plus grand élément visible. Objectif : ≤ 2,5s
- INP — Interaction to Next Paint : réactivité aux interactions. Objectif : ≤ 200ms
- CLS — Cumulative Layout Shift : stabilité visuelle (pas de saut de mise en page). Objectif : ≤ 0,1
Voici où se situent en moyenne les sites WordPress vs les sites en code natif en 2026, d'après les données du Chrome User Experience Report (CrUX) :
Score PageSpeed Insights (mobile) — moyennes secteur 2026
Ces chiffres ne sont pas anecdotiques. Google a clairement énoncé que les sites qui atteignent les seuils "Good" sur les trois CWV bénéficient d'un boost de classement — et que ceux qui restent dans le rouge sont pénalisés. Pour deux sites à contenu équivalent, celui avec les meilleurs CWV classera plus haut.
Chaque tranche de 100ms de LCP supplémentaire correspond à une augmentation de 10 à 20% du taux de rebond sur mobile (source : Google/Deloitte, 2024). Moins de temps sur le site = moins de conversions = moins de signaux comportementaux positifs pour Google = classement dégradé. C'est un cercle vicieux direct entre performance et visibilité SEO.
Les 5 problèmes SEO structurels de WordPress
WordPress peut être optimisé — mais ses problèmes de performance sont architecturaux, pas simplement des mauvais réglages. Comprendre pourquoi permet de comprendre les limites réelles de l'optimisation.
La génération dynamique PHP à chaque requête
Chaque visite d'une page WordPress déclenche une chaîne complète : PHP → base de données MySQL → construction du HTML → envoi au navigateur. Même avec du cache, le premier visiteur d'une URL (ou après invalidation du cache) subit la totalité de cette latence. Un site en code natif pré-génère ses pages à la compilation : le navigateur reçoit le HTML final instantanément, sans aucun traitement serveur.
L'accumulation de plugins qui se marchent dessus
Un site WordPress moyen en production a 17 plugins actifs. Chaque plugin ajoute du CSS et du JavaScript chargés sur toutes les pages, même quand ils ne sont pas utiles. Un plugin de formulaire de contact charge ses scripts sur la page d'accueil. Un plugin de galerie photos alourdit la page de tarifs. Résultat : 60 à 120 requêtes HTTP par page, pour un poids total de 3 à 6 Mo — sans images.
jQuery omniprésent et bloquant
WordPress charge jQuery (87 Ko minifié) sur chacune de ses pages par défaut, même si aucun plugin ne l'utilise. jQuery est une ressource bloquante au rendu : elle retarde l'affichage de la page le temps d'être téléchargée et parsée. Les navigateurs modernes n'ont plus besoin de jQuery — les sites en code natif s'en passent entièrement. Ce seul élément pèse 0,2 à 0,4 seconde de LCP supplémentaire sur mobile 4G.
Les thèmes : CSS de 500 Ko pour des styles jamais utilisés
Les thèmes WordPress populaires (Divi, Avada, Astra) chargent des feuilles de styles qui couvrent tous leurs composants — même ceux que vous n'utilisez pas. Divi charge 1,2 Mo de CSS de base. Ces ressources non utilisées bloquent le rendu et gonflent le poids de page sans aucune valeur. Un site en code natif ne charge que le CSS strictement nécessaire à la page affichée.
Les images mal optimisées par défaut
WordPress génère des formats d'images multiples (JPG, PNG) mais ne force pas le format WebP/AVIF sur tous les hébergeurs. Les images ne sont pas nativement lazy-loadées dans les versions antérieures à WP 5.5. Et les page builders comme Elementor insèrent des images inline dans des styles CSS, rendant leur optimisation impossible par les outils classiques.
Optimiser un site WordPress pour les Core Web Vitals ressemble à améliorer l'aérodynamisme d'un camion de déménagement : vous pouvez gagner quelques secondes, mais vous ne dépasserez jamais une berline sportive bien conçue dès le départ.
Le problème de sécurité comme facteur SEO indirect
WordPress est la cible de 90% des attaques de CMS sur le web (WP Scan, 2025). Un site piraté — redirections malveillantes, injection de spam dans les pages — est délisté par Google sous 48 heures. La restauration d'un site WordPress compromis prend en moyenne 4 à 12 jours. Pendant cette période, votre site disparaît des résultats. Les sites en code natif sans CMS exposé réduisent drastiquement cette surface d'attaque.
Code natif : ce qui change concrètement
Le terme "code natif" désigne tout site dont les pages sont rendues sans CMS dynamique : HTML/CSS/JavaScript écrit à la main ou généré par un framework moderne comme Next.js, Astro ou Nuxt en mode statique. Ces sites éliminent chacun des problèmes structurels de WordPress listés ci-dessus.
Le Static Site Generation (SSG) avec Next.js
Next.js en mode SSG (Static Site Generation) génère toutes les pages à la compilation, pas à la requête. La page d'accueil, les pages de services, les articles de blog — tout est pré-calculé et servi directement depuis un CDN. Le temps de chargement ne dépend plus de la puissance du serveur ni de la base de données : il dépend seulement de la bande passante réseau.
Comparaison temps de chargement réel (mobile 4G, Paris)
Le TTFB (Time to First Byte) de 0,06 seconde en Next.js/Vercel vs 1,2 seconde en WordPress standard n'est pas une optimisation marginale : c'est une différence d'ordre de grandeur. Google mesure le TTFB pour évaluer la réactivité du serveur, et un TTFB supérieur à 0,8s est un signal négatif explicite dans PageSpeed Insights.
L'impact direct sur le SEO
Les gains de performance en code natif ont des effets en cascade sur plusieurs signaux SEO :
Meilleur crawl budget
Google alloue un budget de crawl à chaque site. Un site lent force le Googlebot à espacer ses visites pour ne pas surcharger le serveur. Un site rapide est crawlé plus fréquemment : vos nouveaux contenus et pages sont indexés en heures, pas en jours.
Taux de rebond réduit
Un site qui s'affiche en moins de 2 secondes retient en moyenne 40% de visiteurs supplémentaires sur mobile vs un site à 4 secondes. Ce comportement (temps passé sur le site, pages vues, retour aux résultats) est un signal indirect que Google mesure pour évaluer la satisfaction des utilisateurs.
Stabilité du CLS = meilleure indexation
Un CLS à 0 (aucun saut visuel) signifie que les polices, images et publicités sont correctement dimensionnées avant le rendu. Google AI Overviews favorisent les pages avec CLS faible pour leurs extraits, car elles garantissent une expérience cohérente sur tous les appareils.
Mobile-first sans compromis
Google indexe en mobile-first depuis 2019. Un site Next.js avec un CSS écrit pour mobile d'abord (< 50 Ko, pas de jQuery, images WebP natives) obtient des scores identiques sur desktop et mobile. WordPress optimisé pour desktop et "adapté" pour mobile via un thème responsive garde toujours un écart de 15 à 25 points entre les deux.
Tableau comparatif WordPress vs code natif
| Critère | WordPress | Code natif (Next.js) |
|---|---|---|
| Score PageSpeed mobile (moy.) | 42 / 100 | 87 / 100 |
| LCP moyen (mobile) | 4,8s | 1,3s |
| TTFB | 0,8 – 2s | 0,04 – 0,1s |
| Poids de page moyen | 3,5 Mo | 0,4 Mo |
| Requêtes HTTP par page | 65 – 120 | 8 – 20 |
| jQuery | Chargé par défaut | Absent |
| Génération de page | Dynamique (PHP + MySQL) | Statique pré-générée |
| Surface d'attaque sécurité | Élevée (plugins, PHP, BDD) | Minimale (fichiers statiques) |
| Core Web Vitals "Good" (% de sites) | 34% | 82% |
| Schéma markup natif | Plugin requis (Yoast, etc.) | Intégré dans le code |
| Coût d'hébergement mensuel | 15 – 80 € (mutualisé/VPS) | 0 – 20 € (Vercel/Netlify) |
| Maintenance mensuelle (mises à jour) | 2 – 4h/mois | 0 – 0,5h/mois |
Le tableau est sans appel sur la performance pure. Mais il serait malhonnête de ne pas mentionner l'avantage réel de WordPress : la facilité de mise à jour du contenu. WordPress dispose d'un back-office clé en main accessible à un non-développeur. Un site en code natif nécessite soit un développeur pour modifier le contenu, soit un headless CMS (Sanity, Contentful) branché dessus — ce qui ajoute une couche de complexité.
C'est pourquoi l'approche rang1 sur nos refontes de site couple un front-end Next.js ultra-performant avec un CMS headless simple d'utilisation : vous gardez la facilité d'édition sans payer le coût de performance de WordPress.
Quand migrer vers du code natif est rentable
Tout le monde ne doit pas migrer. Voici les signaux qui indiquent qu'une refonte vers du code natif est la bonne décision — et ceux qui suggèrent qu'une optimisation WordPress suffit.
Migrez vers du code natif si :
Votre score PageSpeed mobile est inférieur à 55/100
En dessous de 55, vous êtes dans la zone rouge des Core Web Vitals. Google vous pénalise par rapport à vos concurrents qui ont des scores supérieurs. L'optimisation WordPress vous emmènera peut-être à 65-70, mais jamais à 85+. Si vos concurrents directs ont des sites modernes et rapides, la pénalité de performance peut représenter 2 à 5 positions de classement perdues sur vos mots-clés cibles. Notre audit SEO gratuit mesure et compare votre score à celui de vos 3 principaux concurrents.
Votre trafic organique stagne malgré du bon contenu
Si vous publiez régulièrement du contenu de qualité (externalisé ou non) et que votre trafic ne progresse pas, la performance technique est souvent le frein. Google ne peut pas récompenser du bon contenu sur un site qui peine à s'afficher. L'association contenu SEO + performance technique est la combinaison gagnante.
Votre taux de rebond mobile dépasse 65%
Un taux de rebond mobile élevé sur un site WordPress lent est presque toujours un problème de performance. Les utilisateurs mobile abandonnent les sites qui prennent plus de 3 secondes à charger dans 53% des cas (Google, 2024). Si votre Analytics montre un écart fort desktop/mobile en taux de rebond, la performance est la cause la plus probable.
Vous dépensez plus de 30€/mois en hébergement WordPress
Un site Next.js sur Vercel coûte 0 à 20 €/mois pour la quasi-totalité des TPE/PME. Si vous payez actuellement un hébergement WordPress mutualisé à 30-80 €/mois, la refonte peut s'autofinancer partiellement via les économies d'hébergement sur 3 ans, en plus des gains SEO. Notre page tarifs détaille le calcul complet.
Votre site a été piraté une fois ou plus
Un site WordPress piraté une fois a 60% de chances d'être piraté à nouveau dans les 12 mois suivants. Chaque incident peut entraîner un délistage Google partiel ou total, avec des semaines de récupération. Le coût d'une refonte est inférieur au coût d'une crise de sécurité sérieuse (intervention urgente, perte de trafic, réputation). La checklist de refonte SEO couvre spécifiquement les étapes de migration sécurisée.
Restez sur WordPress si :
- Votre site est un blog personnel ou une boutique e-commerce complexe avec WooCommerce — les besoins fonctionnels justifient le CMS
- Votre score PageSpeed est déjà supérieur à 70/100 sur mobile et vos Core Web Vitals sont dans le jaune
- Vous avez un développeur dédié qui maintient et optimise le site régulièrement
- Votre budget est inférieur à 2 000 € — une refonte complète n'est pas rentable à ce stade
Dans ce cas, concentrez-vous sur l'optimisation du contenu (15 actions SEO concrètes) et les actions techniques qui restent accessibles sur WordPress : activation du cache, CDN, compression des images, désactivation des plugins inutiles.
Questions fréquentes
Core Web Vitals au vert dès le premier jour
Nos refontes Next.js garantissent un score PageSpeed mobile ≥ 85/100, un LCP ≤ 1,5s et un CLS à 0. SEO natif, schémas complets, hébergement CDN inclus. Devis gratuit en 48h.