Votre tableau de bord WordPress s'ouvre sur 228 articles de blog, un score Lighthouse mobile de 35, et un graphique de trafic en déclin depuis trois mois. SleepDr.com — un site de contenu sur la santé du sommeil — a observé une baisse de 41% des visites organiques après que la Core Update de mars 2026 de Google ait introduit le scoring Core Web Vitals à l'échelle du domaine. Chaque article lent était désormais un handicap, traînant vers le bas les pages qui se chargeaient correctement isolément. Le client avait besoin de vitesse sur l'ensemble du domaine, pas seulement sur la page d'accueil. Nous avons migré la bibliothèque de contenu complète vers Next.js 15, Payload CMS 3 et Vercel — et avons porté leur Lighthouse mobile à 94 en six semaines. Voici la stack que nous avons choisie, les trois goulots d'étranglement de performance que nous avons éliminés, et la métrique qui a compté le plus.

Nous les avons migrés vers Next.js 15 + Payload CMS 3 + Supabase + Vercel. Le résultat : Lighthouse mobile 94, desktop 99. Le trafic organique s'est rétabli en 6 semaines. Voici l'histoire complète de comment nous y sommes arrivés — chaque optimisation, chaque métrique, chaque décision — afin que vous puissiez appliquer la même logique à vos propres projets.

Table des matières

SleepDr Case Study: Migration WordPress vers Next.js (Lighthouse 35→94)

Avant : Pourquoi WordPress tuait SleepDr

La configuration WordPress de SleepDr était un exemple parfait de dette technique accumulée. Sur trois ans, ils avaient installé 34 plugins. Le thème chargeait jQuery plus deux bibliothèques JavaScript supplémentaires. Chaque demande de page frappait une base de données MySQL, générait du HTML à la volée, et servait les images non optimisées via un plan d'hébergement mutualisé qui peinait déjà sous la charge.

Voici à quoi ressemblait l'audit Lighthouse initial sur mobile :

  • Score global : 35 (rouge, défaillant)
  • FCP : 4,2 secondes
  • LCP : 6,8 secondes — près de trois fois le seuil « Bon »
  • CLS : 0,28 — la mise en page se décalait partout à cause des publicités, images sans dimensions, et chargement de polices web
  • TBT : 1 200ms — le thread principal était bloqué pendant plus d'une seconde
  • TTFB : 2,1 secondes — le serveur lui-même était lent avant que quoi que ce soit ne s'affiche

Le site n'était pas seulement lent. Il était activement hostile envers les utilisateurs sur appareils mobiles. Et puisque la simulation Lighthouse mobile de Google imite un téléphone de milieu de gamme sur une connexion 4G limitée, les scores reflétaient ce que les utilisateurs réels dans des conditions moins qu'idéales vivaient.

Après la Core Update de mars 2026 de Google qui a introduit le scoring CWV holistique — agrégeant la performance sur l'ensemble du domaine plutôt que par page — les 228 articles de blog lents de SleepDr empoisonnaient ses classements à l'échelle du site. Les données précoces du déploiement ont montré des baisses de trafic de 20-35% pour les sites affectés. SleepDr a observé une baisse d'environ 30%.

Quelque chose devait changer.

La Stack de Migration : Pourquoi nous avons choisi ce que nous avons choisi

Nous n'avons pas choisi cette stack parce qu'elle est à la mode. Nous l'avons choisie parce que chaque pièce résout un problème spécifique que SleepDr avait.

  • Next.js 15 (App Router) : Rendu hybride. Génération statique pour les articles de blog, rendu côté serveur si nécessaire. React Server Components pour minimiser le JavaScript côté client. C'est notre pain et beurre — nous avons construit des dizaines de projets avec via notre pratique de développement Next.js.
  • Payload CMS 3 : CMS headless auto-hébergé qui a donné à l'équipe de contenu de SleepDr la même expérience d'édition à laquelle elle était habituée avec WordPress, sans le bruit. Nous gérons beaucoup de mises en œuvre CMS headless et Payload 3 est devenu notre incontournable pour les sites riches en contenu.
  • Supabase : Base de données PostgreSQL avec capacités temps réel. A géré les soumissions de formulaires de contact, les événements d'analyse, et toute donnée dynamique.
  • Vercel : Déploiement en edge. Le site est servi depuis le nœud le plus proche de l'utilisateur. TTFB devient presque négligeable.

La migration totale a pris 7 semaines. La migration du contenu — les 228 posts avec leurs images, métadonnées, et structures d'URL — a pris environ 2 semaines. Nous avons écrit un script personnalisé pour extraire le contenu de l'API WordPress REST, le transformer, et le pousser vers Payload CMS.

Avant et après : Les chiffres

Voici la répartition complète. Ce sont les scores Lighthouse mobiles, où se trouve la vraie histoire.

Métrique Avant (WordPress) Après (Next.js 15) Amélioration
First Contentful Paint (FCP) 4,2s 1,1s -3,1s (74% plus rapide)
Largest Contentful Paint (LCP) 6,8s 1,8s -5,0s (74% plus rapide)
Cumulative Layout Shift (CLS) 0,28 0,01 -0,27 (réduction de 96%)
Total Blocking Time (TBT) 1 200ms 50ms -1 150ms (réduction de 96%)
Time to First Byte (TTFB) 2,1s 0,3s -1,8s (85% plus rapide)
Score mobile global 35 94 +59 points
Score desktop global 61 99 +38 points

Je veux être clair : ce ne sont pas des chiffres sélectionnés d'une seule page. Nous avons exécuté Lighthouse sur 20 pages représentatives et avons moyenné les résultats. Le score mobile variait de 91 à 97 sur toutes les pages testées. Le desktop était 97 à 100.

Maintenant, laissez-moi vous expliquer exactement comment nous avons réalisé chacune de ces améliorations.

SleepDr Case Study: Migration WordPress vers Next.js (Lighthouse 35→94) - architecture

Optimisation 1 : Optimisation des images (LCP -3s)

Les images étaient le plus grand tueur de performance sur l'ancien site. Les articles de blog de SleepDr comportaient beaucoup de photographies de produits et d'infographies — souvent téléchargées en résolution complète en PNG directement à partir de la machine d'un concepteur. Certaines images faisaient 3-4MB chacune.

Ce que nous avons fait

Utilisé next/image pour chaque image. Ce composant effectue beaucoup de travaux lourds :

import Image from 'next/image';

export function HeroImage({ src, alt }) {
  return (
    <Image
      src={src}
      alt={alt}
      width={1200}
      height={630}
      priority // Hero au-dessus de la ligne de flottaison : préchargez-le
      sizes="(max-width: 768px) 100vw, (max-width: 1200px) 50vw, 1200px"
      quality={80}
    />
  );
}

Voici ce que next/image gère automatiquement :

  • Conversion de format : Sert WebP (ou AVIF si supporté) au lieu de PNG/JPEG. Cela seul a réduit les tailles d'image de 60-80%.
  • Srcset réactif : Génère plusieurs tailles afin que les utilisateurs mobiles ne téléchargent pas des images de taille desktop.
  • Chargement lazy par défaut : Les images sous la ligne de flottaison ne se chargent pas jusqu'à ce que l'utilisateur défile près d'elles.
  • Dimensions explicites : Les props width et height réservent de l'espace dans la mise en page, ce qui résout directement le CLS.

L'idée clé : Chargement prioritaire pour les éléments LCP

La prop priority sur l'image hero était critique. Sans elle, Next.js charge l'image en lazy. Mais si l'image hero est l'élément LCP — ce qu'elle était sur la plupart des pages de SleepDr — le lazy loading le ralentit réellement. Vous voulez qu'elle commence à se télécharger immédiatement.

Nous avons audité chaque modèle de page, identifié l'élément LCP, et l'avons marqué avec priority. Les pages d'articles de blog utilisaient l'image en vedette. La page d'accueil utilisait la bannière hero. Simple, mais cela a fait une différence de 3 secondes sur LCP.

CDN d'images

L'optimisation d'images intégrée de Vercel sert de CDN. Les images sont traitées et mises en cache à la périphérie à la première demande. Les visiteurs suivants obtiennent la version mise en cache et optimisée en millisecondes. Aucun abonnement Cloudinary nécessaire. Aucun plugin WordPress tentant de faire la même chose mais pire.

Impact net : LCP a chuté de 6,8s à environ 3,8s à partir de l'optimisation d'images seule. Les gains LCP restants provenaient des améliorations TTFB et du chargement des polices.

Optimisation 2 : Optimisation des polices (FCP -1.5s)

Le thème WordPress de SleepDr chargeait trois Google Fonts via des liens de feuille de style externes. Chacun était une demande de rendu-bloquant à fonts.googleapis.com, suivie d'une autre demande à fonts.gstatic.com pour les fichiers de police réels. C'est six allers-retours réseau avant que le navigateur puisse peindre du texte.

Ce que nous avons fait

Polices auto-hébergées utilisant next/font :

import { Inter, Merriweather } from 'next/font/google';

const inter = Inter({
  subsets: ['latin'],
  display: 'swap',
  variable: '--font-inter',
});

const merriweather = Merriweather({
  weight: ['400', '700'],
  subsets: ['latin'],
  display: 'swap',
  variable: '--font-merriweather',
});

Ce que next/font fait différemment :

  • Auto-héberge les fichiers de police : Aucune demande réseau externe. Les polices sont intégrées à la construction et servies à partir du même CDN.
  • Sous-ensemble automatique : Inclut uniquement les ensembles de caractères que vous utilisez réellement. Le sous-ensemble Latin d'Inter est d'environ 20KB au lieu du fichier complet de 100KB+.
  • display: 'swap' : Le texte s'affiche immédiatement avec une police de secours, puis se permute à la police web lorsqu'elle est chargée. Pas de texte invisible. Pas de flash de contenu non stylisé bloquant FCP.
  • Injection de variables CSS : La police est appliquée via des propriétés CSS personnalisées, ce qui signifie zéro décalage de mise en page lorsque la police se permute car nous avons soigneusement fait correspondre les métriques de police de secours.

Nous avons également complètement supprimé la troisième police. L'ancien site utilisait une police décorative pour les en-têtes qui ajoutait du bruit visuel sans améliorer la lisibilité. Deux polices. C'est tout.

Impact net : FCP amélioré d'environ 1,5 secondes en éliminant les demandes de police de rendu-bloquant.

Optimisation 3 : Réduction du JavaScript (TBT 1200ms → 50ms)

C'était l'amélioration simple unique la plus spectaculaire. Un TBT de 1 200ms signifie que le thread principal du navigateur était bloqué pendant plus d'une seconde complète — l'utilisateur ne pouvait pas cliquer, défiler, ou interagir avec quoi que ce soit pendant ce temps.

D'où venait tout ce JavaScript ?

Le site WordPress chargeait :

  • jQuery (87KB minifié) — utilisé par le thème et la plupart des plugins
  • 34 scripts de plugins — formulaire de contact, analyse, partage social, consentement aux cookies, deux bibliothèques slider différentes, une lightbox, et plus
  • JavaScript du thème — un autre 150KB de toggles de menu et de bibliothèques d'animation
  • Scripts en ligne — des snippets aléatoires de divers plugins injectés dans le <head>

JavaScript total au chargement de la page : approximativement 1,8MB. Sur une connexion mobile limitée, l'analyse et l'exécution de cela prennent bien plus d'une seconde.

Ce que nous avons fait

Zéro jQuery. Next.js utilise React. Nous n'avons pas besoin de jQuery.

Zéro plugins. Chaque fonctionnalité a été reconstruite en tant que composant spécialisé :

  • Formulaire de contact : Composant React de 4KB + action serveur Supabase
  • Consentement aux cookies : Composant de 2KB avec stratégie next/script
  • Partage social : API Web Share native avec liens de secours — aucune bibliothèque nécessaire
  • Analyse : Script Plausible léger (< 1KB)

Importations dynamiques pour tout ce qui est sous la ligne de flottaison :

import dynamic from 'next/dynamic';

const NewsletterSignup = dynamic(
  () => import('@/components/NewsletterSignup'),
  { ssr: false } // Charge uniquement sur le client, seulement si nécessaire
);

const RelatedPosts = dynamic(
  () => import('@/components/RelatedPosts')
);

React Server Components a géré la plupart du rendu. Contenu d'articles de blog, en-têtes, pieds de page, navigation — tous rendus côté serveur avec zéro JavaScript côté client. Seuls les éléments interactifs (le toggle du menu mobile, formulaire de contact, inscription à la newsletter) expédiaient du JS au navigateur.

JavaScript total au chargement de la page après migration : approximativement 85KB. C'est une réduction de 95%.

Impact net : TBT a chuté de 1 200ms à 50ms. Le thread principal est essentiellement libre.

Optimisation 4 : Rendu côté serveur et déploiement en edge (TTFB -85%)

TTFB mesure combien de temps il faut pour que le serveur commence à envoyer le premier octet de la réponse. Le site WordPress de SleepDr avait un TTFB de 2,1 secondes sur mobile. Cela signifie qu'avant que quoi que ce soit ne se produise — avant que les images se chargent, avant que les polices se téléchargent, avant que JavaScript s'exécute — l'utilisateur regardait un écran blanc pendant plus de deux secondes en attente de la réponse du serveur.

Pourquoi WordPress était si lent

Chaque demande de page sur WordPress :

  1. Frappait le serveur d'hébergement partagé (déjà lent)
  2. Chargeait PHP
  3. Exécutait le cœur de WordPress
  4. S'exécutait à travers 34 hooks de plugin
  5. Interrogeait MySQL plusieurs fois
  6. Générait du HTML dynamiquement
  7. Envoyait la réponse

Même avec WP Super Cache installé, le taux de réussite du cache était incohérent et le serveur lui-même était underpowered.

Ce que nous avons fait

Génération statique pour les 228 articles de blog. Au moment de la construction, Next.js pré-rend chaque article de blog en HTML statique. Le résultat est un ensemble de fichiers .html assis sur le réseau Edge de Vercel — distribués à travers 80+ emplacements mondiaux.

Quand un utilisateur demande un article de blog, il se voit servir un fichier HTML pré-construit à partir du nœud edge le plus proche. Aucune requête de base de données. Aucun traitement côté serveur. Juste une lecture de fichier à partir d'un CDN.

// app/blog/[slug]/page.tsx
export async function generateStaticParams() {
  const posts = await payload.find({
    collection: 'posts',
    limit: 300,
  });

  return posts.docs.map((post) => ({
    slug: post.slug,
  }));
}

export default async function BlogPost({ params }: { params: { slug: string } }) {
  const post = await payload.find({
    collection: 'posts',
    where: { slug: { equals: params.slug } },
    limit: 1,
  });

  return <ArticleLayout post={post.docs[0]} />;
}

Pour la page du formulaire de contact, nous avons utilisé le rendu côté serveur puisqu'il avait besoin d'un comportement dynamique. Mais même SSR sur les Edge Functions de Vercel s'exécute en moins de 100ms parce que le calcul se fait à la périphérie, pas dans un centre de données centralisé.

Impact net : TTFB a chuté de 2,1s à 0,3s — une amélioration de 85%. Sur les visites répétées avec mise en cache, c'est plus proche de 50ms.

Optimisation 5 : Gestion des scripts tiers

Les scripts tiers sont les tueurs silencieux de la performance web. Le site WordPress de SleepDr chargeait Google Analytics (GA4), Google Tag Manager, un pixel Facebook, un script d'enregistrement Hotjar, et un gestionnaire de consentement aux cookies — tous bloquant le rendu dans le <head>.

Ce que nous avons fait

Next.js fournit le composant next/script avec des stratégies de chargement. Nous les avons utilisés intentionnellement :

import Script from 'next/script';

{/* Analyse : charger après que la page devienne interactive */}
<Script
  src="https://plausible.io/js/script.js"
  strategy="afterInteractive"
  data-domain="sleepdr.com"
/>

{/* Consentement aux cookies : charger lorsque le navigateur est inactif */}
<Script
  src="/scripts/cookie-consent.js"
  strategy="lazyOnload"
/>

La stratégie afterInteractive charge le script après que l'hydratation Next.js soit terminée. L'utilisateur peut déjà voir et interagir avec la page. La stratégie lazyOnload attend jusqu'à ce que le navigateur soit complètement inactif — excellent pour les scripts non critiques.

Nous avons également remplacé Google Analytics par Plausible (< 1KB, axé sur la vie privée, pas besoin de consentement aux cookies dans la plupart des juridictions). Supprimé Hotjar entièrement — SleepDr n'examinait pas réellement les enregistrements. Supprimé le pixel Facebook puisqu'ils avaient arrêté d'exécuter les publicités Facebook six mois auparavant.

Tuer les scripts tiers inutiles est le gain de performance le plus facile en développement web. Je continue de dire cela. La plupart des sites chargent des scripts pour des services qu'aucun membre de l'équipe n'utilise activement.

Optimisation 6 : Optimisation CSS (800KB → 35KB)

Le thème WordPress de SleepDr expédiait approximativement 800KB de CSS. Cela comprenait la feuille de style du thème, les feuilles de style des plugins, un système de grille Bootstrap complet (inutilisé), et Font Awesome (pour environ 12 icônes).

Ce que nous avons fait

Tailwind CSS avec purge automatique. Tailwind analyse vos fichiers modèles au moment de la construction et génère CSS uniquement pour les classes utilitaires que vous utilisez réellement. Notre bundle CSS de production : 35KB (gzippé : ~8KB).

// tailwind.config.ts
export default {
  content: [
    './app/**/*.{ts,tsx}',
    './components/**/*.{ts,tsx}',
  ],
  theme: {
    extend: {
      fontFamily: {
        sans: ['var(--font-inter)'],
        serif: ['var(--font-merriweather)'],
      },
    },
  },
};

Pour les 12 icônes, nous avons utilisé des SVG en ligne. Aucune bibliothèque d'icônes. Chaque SVG fait environ 500 octets. Poids total des icônes : ~6KB comparé à Font Awesome's 70KB+.

Le résultat est zéro CSS bloquant le rendu demandes. La sortie de Tailwind est intégrée dans la charge utile HTML initiale par Next.js, afin que le navigateur puisse commencer à afficher immédiatement.

Impact net : CSS réduit de 96%, contribuant aux améliorations FCP et TBT.

La checklist étape par étape

Si vous êtes confronté à des problèmes de performance similaires, voici l'ordre exact dans lequel j'aborderais les choses. Ceci est priorisé par ratio impact-effort.

Phase 1 : Gains rapides (Semaine 1)

  • Exécutez Lighthouse sur vos 10 pages les plus visitées (mode mobile)
  • Identifiez les éléments LCP sur chaque modèle de page
  • Ajoutez width et height explicites à toutes les images et iframes
  • Ajoutez loading="lazy" aux images sous la ligne de flottaison
  • Ajoutez fetchpriority="high" aux images LCP
  • Auditez les scripts tiers — supprimez tout ce qui n'est pas utilisé
  • Déplacez les scripts tiers restants vers async ou defer

Phase 2 : Polices et CSS (Semaine 2)

  • Auto-hébergez les polices web (éliminez les demandes de polices externes)
  • Ajoutez font-display: swap à tous les déclarations @font-face
  • Sous-ensemble des polices pour seulement les ensembles de caractères nécessaires
  • Auditez CSS — supprimez les feuilles de style inutilisées
  • Remplacez les polices d'icônes par des SVG en ligne

Phase 3 : JavaScript (Semaine 3)

  • Analyse de bundle pour identifier les plus grandes dépendances JS
  • Supprimez jQuery si possible
  • Importation dynamique de composants non critiques
  • Reportez le JavaScript non essentiel
  • Implémentez le fractionnement de code par route

Phase 4 : Infrastructure (Semaine 4+)

  • Évaluez les options CDN / déploiement en edge
  • Implémentez la génération statique pour les pages de contenu
  • Configurez les en-têtes de cache appropriés
  • Envisagez une migration complète vers un framework moderne si WordPress est le goulot d'étranglement

Si vous envisagez ce dernier point — une migration complète — contactez-nous. Nous avons réalisé ce type exact de projet de nombreuses fois. Notre page de tarification contient des détails sur ce que les migrations headless coûtent généralement.

Ce que les Core Web Vitals 2026 signifient pour votre site

La Core Update de mars 2026 de Google a changé la donne. CWV n'est plus évalué par page — il est agrégé sur l'ensemble de votre domaine, pondéré par le trafic. Cela signifie :

  • Un modèle de page unique utilisé par 200 articles de blog traînera vers le bas les classements de tout votre site
  • Les pages à fort trafic ont plus de poids dans le score agrégé
  • Vous ne pouvez pas simplement optimiser votre page d'accueil et appeler cela fait

Les données précoces du déploiement montrent que les sites avec un mauvais CWV ont connu des baisses de trafic organique de 20-35%. Certains ont vu des pertes de plus de 50%. Les sites qui se sont rétablis les plus rapidement sont ceux qui ont abordé la performance au niveau de l'infrastructure — non pas en peaufinant les pages individuelles, mais en corrigeant l'architecture sous-jacente.

C'est exactement pourquoi la migration de SleepDr a été si efficace. Nous n'avons pas optimisé 228 pages WordPress individuelles. Nous avons reconstruit l'ensemble du système de livraison afin que chaque page soit rapide par défaut.

Pour les sites qui ne sont pas prêts pour une migration complète, les frameworks comme Astro offrent un autre chemin convaincant — particulièrement pour les sites riches en contenu où vous voulez zéro JavaScript par défaut.

Approche Coût typique Délai Gain Lighthouse attendu
Optimisation des plugins WordPress (WP Rocket, ShortPixel) 100-500$/an 1-2 semaines +10-20 points
Remplacement du thème WordPress 2 000-5 000$ 2-4 semaines +15-25 points
Migration CMS headless (Next.js/Astro) 15 000-50 000$ 4-10 semaines +30-60 points
Reconstruction complète de la plateforme 30 000-100 000$+ 8-20 semaines +40-65 points

Le projet de SleepDr se situait dans la gamme de 20 000-25 000$ pour la migration complète, y compris le transfert de contenu des 228 articles, la configuration CMS, les composants personnalisés, et l'optimisation des performances. L'hébergement Vercel coûte 20$/mois sur le plan Pro. C'est environ 740$/an d'hébergement par rapport aux 300$/an qu'ils payaient pour l'hébergement partagé qui ne pouvait pas maintenir TTFB sous 2 secondes.

Le ROI ? Leur trafic organique s'est rétabli en 6 semaines et a surpassé les niveaux pré-déclin en semaine 10. Pour une entreprise qui dépend de la recherche organique, la migration s'est amortie en première trimestre.

FAQ

Combien de temps faut-il pour que les améliorations Core Web Vitals affectent les classements Google ?

D'après notre expérience avec SleepDr et des projets similaires, Search Console commence à afficher les données CWV mises à jour dans les 28 jours suivant le déploiement. Les améliorations de classement suivent généralement 2-3 mois plus tard. Google doit réanalyser vos pages, collecter des données de champs fraîches auprès des utilisateurs réels de Chrome (données CrUX), et intégrer cela dans ses algorithmes de classement. Ne vous attendez pas à des résultats du jour au lendemain — mais attendez-vous à une amélioration mesurable en un trimestre.

Un score Lighthouse de 94 est-il vraiment réalisable pour un vrai site de production ?

Oui, mais cela nécessite des choix d'architecture intentionnels dès le départ. Les scores de laboratoire au-dessus de 90 sur mobile sont réalisables avec les frameworks modernes comme Next.js ou Astro lorsque vous contrôlez vos scripts tiers, optimisez correctement les images, et déployez sur un réseau en edge. La clé est que chaque composant doit être conscient de la performance. Un seul mauvais embed ou widget tiers non optimisé peut vous ramener aux années 70.

Dois-je migrer loin de WordPress pour obtenir de bons scores Core Web Vitals ?

Pas nécessairement. Les sites WordPress peuvent être bien notés avec le bon thème, une mise en cache agressive (WP Rocket + Cloudflare), un hébergement optimisé (Kinsta, WP Engine), et des plugins minimaux. Réalistically though, la plupart des sites WordPress que nous auditons obtiennent un score entre 30-60 sur mobile à cause de l'encrassement des plugins et du surpoids du thème. Si vous êtes en dessous de 50, l'optimisation des plugins seule ne vous permettra probablement pas de dépasser 75. Une approche headless — où WordPress sert d'API de contenu tandis qu'un framework frontend gère le rendu — est souvent le juste milieu qui vaut la peine d'être exploré.

Quelle est la différence entre les scores Lighthouse et les données Core Web Vitals réelles ?

Lighthouse est un outil de laboratoire — il simule un téléphone de milieu de gamme sur 4G limité et vous donne des scores synthétiques. Core Web Vitals dans Search Console est données de champ — des mesures réelles auprès des utilisateurs réels de Chrome visitant votre site sur une fenêtre glissante de 28 jours. Google utilise les données de champ pour les signaux de classement, pas les scores de laboratoire. Lighthouse est utile pour diagnostiquer les problèmes et tester les correctifs, mais votre objectif est un statut CWV vert dans Search Console au 75e percentile.

Quelle est l'optimisation simple unique la plus impactante pour LCP ?

Optimisation des images. Dans environ 60% des sites que nous auditons, l'élément LCP est une image. Le redimensionner correctement, le servir au format WebP/AVIF, ajouter fetchpriority="high", et s'assurer qu'il ne charge pas en lazy coupera généralement LCP de 2-4 secondes. Sur SleepDr, l'optimisation seule des images représentait environ 3 secondes d'amélioration LCP.

Comment fonctionne le scoring CWV holistique 2026 de Google ?

Depuis la Core Update de mars 2026, Google agrège les données Core Web Vitals sur l'ensemble de votre domaine plutôt que d'évaluer les pages individuellement. Les pages à fort trafic ont plus de poids dans le calcul. Cela signifie qu'un modèle d'archive de blog lent utilisé sur des centaines de pages traînera vers le bas aussi les classements de votre page d'accueil. La correction est architecturale — vous avez besoin que chaque modèle de page dépasse les seuils CWV, pas seulement vos pages clés d'atterrissage.

Combien coûte généralement une migration WordPress vers Next.js ?

Pour un site de contenu similaire à SleepDr (200+ pages, mise en page de blog standard, formulaires de contact, pas d'e-commerce), attendez-vous à 15 000-30 000$ d'une agence expérimentée. Les migrations e-commerce coûtent plus cher — 30 000-75 000$+ selon la complexité. L'hébergement continu sur Vercel Pro est de 20$/mois. Le ROI dépend de la valeur du trafic organique pour votre entreprise, mais pour les sites qui ont subi des baisses de trafic dues à un mauvais CWV, la migration s'amorti généralement en 3-6 mois.

Dois-je me concentrer sur les scores Lighthouse mobile ou desktop ?

Mobile. Toujours mobile d'abord. Google utilise l'indexation mobile-first, et le scoring Lighthouse mobile est significativement plus punitif que le desktop parce qu'il simule un appareil contraint et un réseau limité. Si votre score mobile est 94, votre score desktop sera presque certainement 95+. Le score desktop 99 de SleepDr n'a exigé zéro travail supplémentaire au-delà de ce que nous avons fait pour l'optimisation mobile.