Vous avez installé WP Rocket. Votre score Lighthouse est passé de 35 à 52. Vous avez ajouté Autoptimize. 52 à 58. Vous avez installé Perfmatters. Maintenant, vous exécutez TROIS plugins de performance -- chacun ajoutant son propre JavaScript -- pour corriger les problèmes de performance causés par d'autres plugins ajoutant du JavaScript. Voyez l'ironie ?

Je me suis retrouvé exactement dans cette situation plus de fois que je ne voudrais l'admettre. Vous passez tout un week-end à affiner les paramètres de WP Rocket, générer du CSS critique, différer les scripts, charger les images en mode lazy, activer le préchargement, configurer un CDN. Vous relancez Lighthouse. 54. Peut-être 58 un bon jour. Vous vérifiez la concurrence -- ils sont assis à 90+. Vous vous demandez ce que vous faites de mal.

Voici le truc : vous ne faites rien de mal. Vous avez atteint le plafond de performance de WordPress. C'est réel, c'est bien documenté, et aucune combinaison de plugins de cache ne peut le franchir. Le problème n'est pas votre configuration. C'est l'architecture.

Cet article explique exactement pourquoi la mise en cache ne peut pas corriger les performances de WordPress, ce qui cause réellement vos faibles scores métrique par métrique, et comment nous avons migré un vrai client -- SleepDr -- d'un score Lighthouse de 35 à 94 en changeant complètement l'architecture.

Table des matières

WordPress Lighthouse Score Stuck at 50? Caching Plugins Can't Fix This

Le paradoxe du plugin de performance

Laissez-moi vous peindre un tableau que je vois tous les mois. Un propriétaire de site vous contacte parce que son site WordPress marque entre 35 et 55 sur Lighthouse. Il a déjà installé une combinaison de ces plugins :

  • WP Rocket ($59/an) -- mise en cache des pages, minification CSS/JS, chargement lazy
  • Autoptimize (gratuit) -- agrégation CSS/JS, CSS critique
  • Perfmatters ($24,95/an) -- gestionnaire de script, nettoyage de base de données
  • Asset CleanUp (gratuit) -- chargement conditionnel des ressources
  • Flying Scripts (gratuit) -- délai d'exécution du JavaScript

C'est cinq plugins dont le seul but est de faire fonctionner WordPress comme il le devrait prêt à l'emploi. Chacun ajoute sa propre surcharge d'exécution PHP. Chacun écrit ses propres règles dans .htaccess. Certains entrent en conflit les uns avec les autres de manière subtile qui ne font surface que sous une charge réelle.

Le meilleur scénario ? Vous obtenez de 35 à environ 65. J'ai vu des équipes passer 40+ heures à affiner ces plugins et leurs différentes interactions. C'est une semaine de temps de développeur -- facilement 4 000 $ à 8 000 $ de main-d'œuvre -- pour gagner 20-30 points Lighthouse et ne pas encore atteindre les seuils "bons" Core Web Vitals.

Et voici ce que personne ne dit : ces pages en cache n'aident que les visiteurs qui reviennent. Le premier coup ? Toujours lent. Un crawl de Googlebot ? Probablement un hit sur les pages non cachées. Votre trafic le plus important -- les nouveaux visiteurs de la recherche -- obtient la pire expérience.

CSS de blocage de rendu : la mise en cache le sert plus vite, pas plus petit

C'est le premier mur que vous allez frapper, et c'est celui que la plupart des gens ne comprennent pas.

Un thème WordPress typique charge entre 200 Ko et 800 Ko de CSS sur chaque page. Je n'exagère pas. Voici ce qui contribue :

  • Feuille de style de thème : 150-400 Ko (les thèmes Divi, Avada et Elementor sont les pires contrevenants)
  • Feuilles de style de plugin : 50-200 Ko (formulaires de contact, curseurs, partage social, plugins SEO)
  • Google Fonts : 30-100 Ko (chargeant souvent 3-5 épaisseurs de police que vous n'utilisez pas)
  • Bibliothèques d'icônes : 50-80 Ko (chargeant tout Font Awesome pour 6 icônes)

Voici la statistique critique : environ 70 % de ce CSS n'est pas utilisé sur une page donnée. Votre page d'accueil n'a pas besoin des styles du panier WooCommerce. Votre article de blog n'a pas besoin du CSS du formulaire de contact. Mais WordPress charge tout, partout, tout à la fois.

Que fait WP Rocket à ce sujet ? Il minifie le CSS (économise peut-être 10-15%), combine les fichiers pour réduire les requêtes HTTP et génère du CSS critique pour le contenu au-dessus du pli. C'est genuinely utile. Mais le navigateur télécharge toujours tous les 400 Ko+. Il analyse tout. Le CSS inutilisé contribue toujours aux retards FCP.

WP Rocket ne peut pas faire du tree-shake de votre CSS. Il ne peut pas déterminer quels styles sont nécessaires par page et supprimer le reste. Cela nécessiterait de comprendre la relation entre votre HTML et CSS au moment de la compilation -- ce que font exactement les frameworks modernes.

Comment Next.js + Tailwind résout réellement ce problème

Avec Next.js et Tailwind CSS, les styles inutilisés sont purgés au moment de la compilation. Pas reportés. Pas minifiés. Supprimés entièrement. Le processus de compilation scanne vos templates, identifie les classes utilitaires réellement utilisées et génère un fichier CSS contenant seulement ces styles.

Le résultat ? Charge utile CSS totale : 15-40 Ko pour un site entier. Pas par page -- pour tout le site. Ce n'est pas une amélioration marginale. C'est une différence d'ordre de grandeur.

/* WordPress: charge tout */
/* theme.min.css: 387 Ko */
/* elementor-frontend.min.css: 142 Ko */
/* woocommerce.min.css: 98 Ko */
/* contact-form-7.min.css: 12 Ko */
/* Total: 639 Ko CSS, ~70% inutilisé sur une page quelconque */

/* Next.js + Tailwind: construit uniquement ce qui est utilisé */
/* globals.css: 22 Ko (site entier) */
/* CSS par page: 0 Ko supplémentaire (tout est dans le bundle purgé) */

Bloat JavaScript : jQuery et la taxe Page Builder

C'est là que TBT -- Total Blocking Time -- se fait tuer. Et TBT représente 30 % de votre score de performance Lighthouse. Vous ne pouvez littéralement pas dépasser 70 avec un mauvais TBT.

WordPress expédie jQuery sur chaque page. C'est 87 Ko minifiés et compressés. Il s'exécute de manière synchrone sur le thread principal. Chaque chargement de page paie cette taxe, même si aucune fonctionnalité sur la page ne nécessite jQuery.

Mais jQuery n'est que l'entrée. Voici le budget JavaScript pour un site de page builder WordPress typique :

Source Taille (minifiée + gzippée) Temps du thread principal
jQuery + jQuery Migrate 87 Ko + 10 Ko 150-300 ms
Frontend Elementor 180-350 Ko 200-500 ms
WP Rocket (oui, vraiment) 15-25 Ko 30-60 ms
Plugin curseur 80-150 Ko 100-250 ms
Analytics + suivi 50-120 Ko 80-200 ms
Autres plugins 50-200 Ko 100-300 ms
Total 462 Ko - 855 Ko 660 ms - 1 610 ms

C'est 660 ms à 1,6 secondes de blocage du thread principal juste de l'exécution de JavaScript. Lighthouse veut TBT sous 200 ms pour un bon score. Sous 600 ms pour "besoins d'amélioration". Vous êtes déjà soufflé avant même que votre contenu réel ne se rende.

Que peuvent faire les plugins de mise en cache ? Ils peuvent minifier (économise 5-10%), différer l'exécution (aide FCP mais TBT reste le même car le travail se fait quand même) et retarder les scripts jusqu'à l'interaction de l'utilisateur (ce qui casse la fonctionnalité et crée une expérience gênante quand les utilisateurs cliquent sur quelque chose et rien ne se passe pendant 500 ms).

Next.js : zéro jQuery, fractionnement de code intelligent

Next.js ne charge pas jQuery. Point. Il n'y a pas d'équivalent. React gère la manipulation DOM et il est déjà dans le bundle pour l'interactivité. Mais voici le vrai gain : fractionnement de code automatique.

Chaque page ne charge que le JavaScript dont elle a besoin. Une page "À propos" statique pourrait expédier 30 Ko de JS au total. Votre page de formulaire de réservation interactif charge la bibliothèque de formulaires sur cette page seulement. Les importations dynamiques signifient que les composants lourds se chargent à la demande.

// Charge le calendrier de réservation uniquement quand ce composant est rendu
import dynamic from 'next/dynamic'

const BookingCalendar = dynamic(() => import('../components/BookingCalendar'), {
  loading: () => <div className="h-96 animate-pulse bg-gray-100 rounded" />,
  ssr: false // Ne pas inclure dans le bundle serveur
})

export default function BookingPage() {
  return (
    <main>
      <h1>Planifiez votre consultation</h1>
      <BookingCalendar />
    </main>
  )
}

Ce drapeau ssr: false signifie que le JavaScript du calendrier n'existe même pas dans le chargement de la page initiale. Les utilisateurs voient un espace réservé instantanément, puis le composant interactif s'hydrate. TBT reste minimal.

WordPress Lighthouse Score Stuck at 50? Caching Plugins Can't Fix This - architecture

Surcharge des requêtes de base de données : le problème de la première requête

Chaque chargement de page WordPress déclenche des requêtes de base de données. Pas quelques-unes. Beaucoup.

J'ai installé Query Monitor sur le site d'un client l'année dernière -- une configuration assez standard de WordPress + WooCommerce + Yoast. Voici ce qu'un seul chargement de page d'accueil a généré :

  • Noyau de WordPress : 8-12 requêtes (options, session utilisateur, règles de réécriture)
  • Yoast SEO : 15+ requêtes (données méta, paramètres de schéma, fil d'ariane)
  • WooCommerce : 20+ requêtes (données de produit, panier, session)
  • Options de thème : 10-15 requêtes (paramètres de personnaliseur, données de widget)
  • Rendu de menu : 5-8 requêtes (éléments de menu imbriqués, méta)
  • Widgets de barre latérale : 5-10 requêtes par widget

Total : 63-80 requêtes de base de données pour un seul chargement de page. Sur un hébergement partagé avec une base de données MySQL qui dessert également 200 autres sites ? Vous pouvez voir où cela mène.

La mise en cache de pages WP Rocket élimine cela -- pour les pages en cache. Mais les caches expirent. Les nouvelles pages ne sont pas en cache jusqu'à la première visite. Les pages du panier WooCommerce ne peuvent pas être en cache (elles sont dynamiques par utilisateur). Les utilisateurs administrateurs contournent le cache. Et Googlebot frappe souvent des pages qui sont tombées hors du cache.

Chaque requête non cachée paie la pénalité complète de la base de données.

Next.js ISR : HTML pré-rendu, zéro requêtes de base de données au moment de la requête

Avec Next.js utilisant Incremental Static Regeneration (ISR), les pages sont pré-rendues au HTML statique au moment de la compilation. Quand un utilisateur demande une page, le serveur renvoie un fichier HTML pré-construit. Aucune exécution PHP. Aucune requête de base de données. Aucun calcul.

// Ceci s'exécute au moment de la compilation, PAS au moment de la requête
export async function getStaticProps() {
  const posts = await fetchFromWordPressAPI('/wp-json/wp/v2/posts')
  
  return {
    props: { posts },
    revalidate: 3600 // Reconstruire cette page toutes les heures
  }
}

Le revalidate: 3600 signifie que la page se reconstruire en arrière-plan toutes les heures. Les utilisateurs obtiennent toujours du HTML statique instantané. Le contenu reste frais. Les requêtes de base de données se produisent une fois pendant la régénération, pas sur chaque demande de visiteur.

Quand nous faisons développement CMS headless, WordPress devient le backend de contenu -- les éditeurs utilisent toujours l'interface d'administration familière -- mais le frontend est complètement découplé. La base de données ne reçoit des requêtes que pendant les builds ou la revalidation, pas pendant les requêtes des utilisateurs.

Rendu côté serveur : le goulot d'étranglement structurel de PHP

Parlons de TTFB -- Time to First Byte. C'est le temps qu'il faut au serveur pour commencer à envoyer une réponse après une requête.

WordPress génère chaque page en exécutant PHP. Même un simple article de blog nécessite :

  1. Apache/Nginx reçoit la requête
  2. Le processus PHP se lance (ou est réutilisé depuis le pool)
  3. L'amorçage de WordPress charge (~50 fichiers)
  4. Les plugins actifs se chargent (chacun : lectures de fichier, requêtes de base de données, enregistrement des hooks)
  5. Les fonctions de thème se chargent
  6. La hiérarchie de template se résout
  7. Les requêtes de base de données s'exécutent
  8. Le template se rend en HTML
  9. Réponse envoyée

Sur un hébergement partagé (où la majorité des sites WordPress vivent -- SiteGround, Bluehost, GoDaddy), ce processus prend 2-4 secondes pour le TTFB seul. Avant que tout CSS, JavaScript ou image se charge. Votre utilisateur regarde un écran vide pendant 2+ secondes.

L'hébergement WordPress géré (Kinsta, WP Engine, Flywheel) réduit cela à 0,8-1,5 s TTFB. Meilleur. Toujours pas génial.

Next.js sur le réseau Edge de Vercel ? 50-200 ms TTFB. Ce n'est pas parce que Vercel a des serveurs magiques. C'est parce qu'il n'y a rien à calculer. Le HTML existe déjà. Le nœud edge le plus proche de l'utilisateur le sert directement. Pas de PHP. Pas de base de données. Pas de rendu de template.

L'écart de performance entre 2+ secondes TTFB et 100 ms TTFB n'est pas quelque chose que vous pouvez combler avec un plugin de mise en cache.

Comprendre votre répartition du score Lighthouse

Avant d'examiner l'étude de cas, comprenons ce que Lighthouse mesure réellement et pourquoi WordPress lutte avec chaque métrique :

Métrique Poids Ce qu'elle mesure Problème de WordPress Solution Next.js
TBT 30% Blocage du thread principal par JS jQuery + plugin JS = 600 ms+ Fractionnement de code = <50 ms
LCP 25% Le plus grand élément visible peint TTFB lent + CSS de blocage de rendu HTML pré-rendu + CSS purgé
CLS 25% Décalages visuels de mise en page Images lazy-loaded sans dimensions, annonces dynamiques next/image avec dimensionnement explicite
Speed Index 10% Complétude visuelle au fil du temps CSS lourd bloque le rendu CSS minimal, HTML instantané
FCP 10% Première peinture de contenu Ressources de blocage de rendu CSS critique en ligne, rien ne bloque

TBT seul avec 30% de poids signifie que si vous atteignez 1 200 ms+ de temps de blocage (courant sur WordPress), vous perdez près d'un tiers de votre score d'emblée. Aucune optimisation d'image ou mise en cache ne peut compenser.

Étude de cas : migration SleepDr -- WordPress vers Next.js

SleepDr est venu nous voir avec un problème que j'ai vu des douzaines de fois. C'est un cabinet de santé du sommeil avec un site WordPress construit sur un thème premium, exécutant WooCommerce pour la planification des rendez-vous, Yoast pour le SEO, Elementor pour la création de pages et -- vous l'aviez deviné -- WP Rocket, Autoptimize ET Perfmatters pour la performance.

Trois plugins de performance. Score Lighthouse : 35.

Voici les chiffres avant et après :

Métrique WordPress (Avant) Next.js (Après) Changement
FCP 4,2 s 1,1 s -74%
LCP 6,8 s 1,8 s -74%
CLS 0,28 0,01 -96%
TBT 1 200 ms 50 ms -96%
TTFB 2,1 s 0,3 s -86%
Score Lighthouse 35 94 +169%

Aucune combinaison de plugins de mise en cache ne pourrait atteindre ces résultats. L'architecture devait changer. Laissez-moi parcourir chaque métrique.

FCP : 4,2 s → 1,1 s (-74%)

Ce qui a causé le score de WordPress : Le site WordPress avait 2,1 s TTFB (hébergement partagé), suivi de 580 Ko de CSS de blocage de rendu d'Elementor, du thème, de WooCommerce et de six feuilles de style de plugin. Le navigateur ne pouvait rien peindre jusqu'à ce qu'il télécharge et analyse tout ce CSS. FCP n'a littéralement pas pu commencer avant 4+ secondes après le clic.

La correction Next.js : HTML pré-rendu servi depuis le edge de Vercel (TTFB 0,3 s). CSS critique en ligne dans le <head> -- environ 4 Ko. Le navigateur peint le contenu presque immédiatement après avoir reçu le HTML. CSS total pour le site entier : 28 Ko, chargé de manière asynchrone après la première peinture.

LCP : 6,8 s → 1,8 s (-74%)

Ce qui a causé le score de WordPress : Le plus grand élément contenu était une image de héros. Sur WordPress, elle s'est chargée via le chargement lazy d'Elementor (qui entrait en conflit avec le chargement lazy de WP Rocket -- oui, ils se battaient l'un l'autre). L'image était un PNG de 2,4 Mo servi sans conversion de format next-gen. LCP n'a pas pu se terminer jusqu'à ce que cette massive image finisse de télécharger sur une connexion TTFB lente.

La correction Next.js : next/image avec conversion automatique WebP/AVIF, srcset réactif et chargement prioritaire pour les images au-dessus du pli. L'image de héros est passée de 2,4 Mo PNG à 85 Ko AVIF. Elle a été priorisée dans la séquence de chargement -- pas de chargement lazy pour le contenu au-dessus du pli. Combiné avec le TTFB rapide, LCP s'est terminé en 1,8 s.

CLS : 0,28 → 0,01 (-96%)

Ce qui a causé le score de WordPress : Trois coupables. Premièrement, les images sans attributs de largeur/hauteur explicite (Elementor les dimensionnait dynamiquement via CSS, causant un reflux). Deuxièmement, une bannière de consentement aux cookies qui s'injectait dans le DOM après le chargement de la page, poussant le contenu vers le bas. Troisièmement, des web fonts chargées avec font-display: swap causant un reflux de texte visible. Un CLS de 0,28 est terrible -- Google considère que tout ce qui dépasse 0,1 est "pauvre".

La correction Next.js : next/image applique la largeur et la hauteur, réservant de l'espace avant le chargement des images. La bannière de cookies a été positionnée comme une superposition fixe au lieu de contenu en ligne. Les polices étaient auto-hébergées avec font-display: optional et préchargées. Le résultat : 0,01 CLS. Effectivement zéro décalage de mise en page.

TBT : 1 200 ms → 50 ms (-96%)

Ce qui a causé le score de WordPress : jQuery (87 Ko + 150 ms d'exécution). Frontend JS d'Elementor (280 Ko + 400 ms). Fragments de panier WooCommerce (35 Ko + 80 ms). JavaScript de trois plugins de performance (combiné 45 Ko + 90 ms). Analytics et suivi (60 Ko + 120 ms). Divers scripts de plugin (100 Ko + 200 ms). Total : plus d'une seconde de blocage du thread principal.

La correction Next.js : Zéro jQuery. Zéro JS de page builder. Importations dynamiques pour le widget de réservation de rendez-vous. Analytics chargé via next/script avec strategy="lazyOnload". JavaScript total sur la page d'accueil : 62 Ko. TBT : 50 ms. C'est une réduction de 96%.

TTFB : 2,1 s → 0,3 s (-86%)

Ce qui a causé le score de WordPress : SleepDr était sur l'hébergement partagé de SiteGround. Chaque requête non cachée déclenchait l'amorçage de WordPress, le chargement de plugins, 60+ requêtes de base de données et le rendu du template PHP. Même avec le cache de page WP Rocket, l'invalidation du cache se produisait fréquemment en raison de la dynamique du panier WooCommerce. TTFB moyen pour les utilisateurs réels : 2,1 secondes.

La correction Next.js : Pages statiques déployées sur le réseau global de edge de Vercel. ISR gère les mises à jour de contenu -- les pages se régénèrent en arrière-plan toutes les 30 minutes. Les requêtes des utilisateurs frappent toujours du HTML pré-construit au nœud edge le plus proche. TTFB est tombé à une moyenne de 0,3 s, avec certaines régions voyant sub-100 ms.

L'architecture qui corrige réellement la performance

La migration SleepDr utilisait ce que nous appelons le modèle WordPress headless. WordPress reste le CMS -- l'équipe de SleepDr se connecte toujours à wp-admin, écrit du contenu dans Gutenberg, gère ses types de rendez-vous dans WooCommerce. Rien n'a changé pour eux du côté de la gestion de contenu.

Mais le frontend est entièrement Next.js. Le processus de compilation tire le contenu de WordPress via l'API REST, génère des pages statiques et déploie sur Vercel. Les éditeurs de contenu publient dans WordPress, un webhook déclenche une revalidation, et la page mise à jour est en direct en moins de 30 secondes.

Pour les équipes envisageant une approche similaire, Astro est une autre option à évaluer -- en particulier pour les sites riches en contenu avec une interactivité minimale. Astro expédie zéro JavaScript par défaut, ce qui peut pousser les scores Lighthouse encore plus haut.

Le point clé : nous n'avons pas optimisé WordPress. Nous avons remplacé la partie qui était lente (le rendu PHP et la livraison du frontend) tout en gardant la partie qui fonctionne bien (la gestion de contenu).

Quand la migration a du sens (et quand ce n'est pas le cas)

Je ne vais pas vous dire que chaque site WordPress devrait migrer vers Next.js. C'est malhonnête. Voici mon évaluation honnête :

La migration a du sens quand :

  • Vos scores Lighthouse sont bloqués en dessous de 60 malgré les efforts d'optimisation
  • La performance a directement un impact sur les revenus (e-commerce, génération de leads, sites marketing SaaS)
  • Vous payez 200+ $/mois pour l'hébergement WordPress géré en essayant d'obtenir une vitesse acceptable
  • Votre équipe de développement est à l'aise avec React/JavaScript
  • Les classements SEO souffrent des défaillances Core Web Vitals

La migration n'a pas du sens quand :

  • Vous êtes un blog personnel ou un petit site vitrine (l'investissement ne sera pas rentable)
  • Votre équipe de contenu dépend fortement des plugins spécifiques à WordPress sans équivalent API
  • Vous êtes satisfait à 60-70 Lighthouse et vos Core Web Vitals passent
  • Votre budget est inférieur à 15 000 $ pour la migration

Pour les sites où la migration a du sens, l'investissement typique varie de 15 000 $ à 50 000 $+ selon la complexité, le nombre de templates et les fonctionnalités personnalisées. Nous avons détaillé notre approche et les structures de projet typiques sur notre page de tarification.

Le calcul du ROI est direct : si les mauvaises performances vous coûtent X en conversions perdues par mois, et que la migration coûte Y, vous connaissez votre période de récupération. Pour SleepDr, l'amélioration de la vitesse de la page a contribué à une augmentation de 34% des réservations de rendez-vous au cours du premier trimestre.

FAQ

WP Rocket peut-il vraiment ne pas corriger mon score WordPress Lighthouse ?

WP Rocket est genuinely l'un des meilleurs plugins de cache WordPress disponibles. Il fait tout ce qu'une couche de cache peut faire -- cache de page, minification, chargement lazy, intégration CDN, génération de CSS critique. Mais il opère dans les contraintes architecturales de WordPress. Si votre score est en dessous de 50, WP Rocket peut typiquement vous amener à 55-65. Pour dépasser 80 de manière cohérente, il faut supprimer le CSS de blocage de rendu, la dépendance jQuery et la surcharge de rendu PHP que WP Rocket ne peut simplement pas éliminer. Il optimise la livraison. Il ne peut pas restructurer l'architecture.

Quel score Lighthouse WordPress peut-il réalistically atteindre avec les plugins de mise en cache ?

Avec une configuration bien optimisée -- thème léger, plugins minimaux, WP Rocket complètement configuré, hébergement géré comme Kinsta ou WP Engine -- vous pouvez realistically atteindre 65-75 sur le Lighthouse mobile. Les scores de bureau seront plus élevés (80-90) parce que l'appareil de test a plus de puissance de traitement. Pour dépasser 80 sur mobile de manière cohérente, il faut soit une configuration WordPress extrêmement minimale (presque pas de plugins, thème personnalisé) soit un changement d'architecture. Les sites avec des page builders comme Elementor ou Divi maximisent généralement à 50-65.

Combien coûte la migration de WordPress vers Next.js ?

Les coûts varient considérablement en fonction de la complexité du site. Un site vitrine simple (5-15 pages, blog, formulaire de contact) coûte 15 000 $ - 25 000 $. Un site de complexité moyenne avec des types de publication personnalisés, plusieurs templates et des intégrations coûte 25 000 $ - 40 000 $. Le e-commerce ou les applications web complexes avec des comptes utilisateur, des données dynamiques et des intégrations tierces commencent à 40 000 $+. Ce sont les tarifs du marché 2025 pour les agences avec une expérience headless éprouvée. Vous pouvez nous contacter pour un devis spécifique basé sur votre site.

Est-ce que WordPress headless signifie que mon équipe de contenu doit apprendre de nouveaux outils ?

Non. C'est tout le point du modèle headless. Votre équipe de contenu continue d'utiliser wp-admin, Gutenberg, ACF ou quoi que ce soit d'habitude. Le seul changement visible est qu'ils pourraient avoir besoin d'attendre 30-60 secondes pour que les mises à jour de contenu apparaissent sur le site en direct (en raison de la revalidation ISR) au lieu de voir les changements instantanément. Certaines équipes trouvent cela à peine perceptible. L'expérience éditoriale reste pratiquement identique.

Quelle est la différence entre TBT et FCP, et pourquoi les deux importent-ils ?

FCP (First Contentful Paint) mesure quand l'utilisateur voit quelque chose -- n'importe quel contenu. TBT (Total Blocking Time) mesure combien de temps le thread principal est bloqué par l'exécution de JavaScript entre FCP et Time to Interactive. Vous pouvez avoir un FCP décent mais un terrible TBT, ce qui signifie que les utilisateurs voient le contenu rapidement mais ne peuvent pas y interagir. C'est courant sur les sites WordPress où le HTML s'affiche à partir du cache mais ensuite 800 Ko+ de JavaScript s'exécute. Les deux métriques importent parce qu'ensemble elles représentent 40% de votre score Lighthouse (TBT à 30%, FCP à 10%).

La migration vers Next.js va-t-elle nuire à mes classements SEO temporairement ?

Si c'est fait correctement, non. La clé est de maintenir les structures d'URL, d'implémenter des redirects 301 appropriés pour toute URL qui change, de préserver toutes les métadonnées et de s'assurer que le sitemap XML est correct. Nous voyons généralement une période de stabilisation de 1-2 semaines où les classements fluctuent légèrement, suivis d'améliorations alors que Google reconnaît les meilleurs Core Web Vitals. SleepDr n'a vu aucune baisse de classement pendant la migration et a gagné des positions en 6 semaines. Le risque vient de migrations négligentes -- redirects cassées, pages manquantes, structures d'URL modifiées sans redirects.

Puis-je utiliser Astro à la place de Next.js pour la migration ?

Absolutement. Astro est un excellent choix pour les sites riches en contenu avec une interactivité limitée. Astro expédie zéro JavaScript par défaut et n'hydrate que les composants interactifs -- ce qu'ils appellent "l'architecture d'îles". Pour un site comme un blog, un site de documentation ou un site marketing où le contenu est primaire, Astro peut atteindre des scores Lighthouse encore meilleurs que Next.js. Nous recommandons Next.js quand vous avez besoin d'une interactivité client-side significative (tableaux de bord, systèmes de réservation, e-commerce) et Astro quand le contenu est prédominant.

L'amélioration du score Lighthouse vaut-elle l'investissement ?

Cela dépend entièrement de ce que votre site fait. Pour un blog personnel, probablement pas. Pour une entreprise où le trafic de recherche organique génère des revenus, les mathématiques sont convaincantes. Google a confirmé Core Web Vitals comme facteur de classement. Les études de 2024-2025 montrent que chaque amélioration de 100 ms en LCP corrèle avec une augmentation de 1,1% du taux de conversion pour les sites e-commerce. Si votre site génère 50 000 $ / mois de revenus et qu'une amélioration de conversion de 10-15% ajoute 5 000 $ - 7 500 $ / mois, une migration de 30 000 $ se rembourse en 4-6 mois. Exécutez vos propres chiffres -- la réponse est toujours spécifique à votre entreprise.