Traduit du dernier trimestre

Le dernier trimestre, nous avons mené un projet qui illustre parfaitement pourquoi WordPress n'est pas toujours le bon outil pour le travail. SleepDr.com — un site de contenu sur la santé du sommeil avec 228 articles de blog, un formulaire de contact et un score mobile Lighthouse de 35 — nous a contactés en désespoir de cause pour améliorer la vitesse. Leur trafic organique avait baissé pendant des mois. La mise à jour principale de Google en mars 2026, qui a introduit la notation holistique des Core Web Vitals à l'échelle du site, les avait durement frappés. Chaque article de blog lent traînait tout le domaine vers le bas.

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 la façon dont 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: WordPress to Next.js Migration (Lighthouse 35→94)

Avant : Pourquoi WordPress tuait SleepDr

La configuration WordPress de SleepDr était un exemple classique 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 accédait à une base de données MySQL, générait du HTML à la volée et servait des images non optimisées via un plan d'hébergement partagé qui était déjà en difficulté 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 était perturbée partout par les annonces, les images sans dimensions et le chargement des polices web
  • TBT : 1 200 ms — 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 aux utilisateurs sur des appareils mobiles. Et puisque la simulation mobile Lighthouse de Google imite un téléphone milieu de gamme sur une connexion 4G limitée, les scores reflétaient ce que les vrais utilisateurs dans des conditions moins qu'idéales expérimentaient.

Après la mise à jour principale de Google en mars 2026 qui a introduit une notation hollistique des CWV — agrégeant les performances sur l'ensemble du domaine plutôt que par page — les 228 articles de blog lents de SleepDr empoisonnaient leurs classements à l'échelle du site. Les données initiales du déploiement ont montré des baisses de trafic de 20-35% pour les sites affectés. SleepDr a connu environ un déclin de 30%.

Quelque chose devait changer.

La pile de migration : Pourquoi nous avons choisi ce que nous avons choisi

Nous n'avons pas choisi cette pile parce qu'elle est tendance. Nous l'avons choisie parce que chaque élément 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 dessus via notre pratique de développement Next.js.
  • Payload CMS 3 : Headless CMS auto-hébergé qui a donné à l'équipe de contenu de SleepDr la même expérience d'édition à laquelle ils étaient habitués avec WordPress, moins le bloat. Nous gérons beaucoup de mises en œuvre de CMS headless et Payload 3 est devenu notre référence pour les sites riches en contenu.
  • Supabase : Base de données PostgreSQL avec capacités en temps réel. Gère les soumissions de formulaires de contact, les événements analytiques et toutes les données dynamiques.
  • Vercel : Déploiement edge. Le site est servi à partir du 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 articles avec leurs images, métadonnées et structures d'URL — a pris environ 2 semaines de ce total. Nous avons écrit un script personnalisé pour récupérer le contenu de l'API REST WordPress, le transformer et l'envoyer à Payload CMS.

Avant et après : Les chiffres

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

Métrique Avant (WordPress) Après (Next.js 15) Amélioration
First Contentful Paint (FCP) 4,2 s 1,1 s -3,1 s (74 % plus rapide)
Largest Contentful Paint (LCP) 6,8 s 1,8 s -5,0 s (74 % plus rapide)
Cumulative Layout Shift (CLS) 0,28 0,01 -0,27 (réduction de 96 %)
Total Blocking Time (TBT) 1 200 ms 50 ms -1 150 ms (réduction de 96 %)
Time to First Byte (TTFB) 2,1 s 0,3 s -1,8 s (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 à la cerise d'une seule page. Nous avons exécuté Lighthouse sur 20 pages représentatives et fait la moyenne des résultats. Le score mobile a varié de 91 à 97 sur toutes les pages testées. Le desktop était de 97 à 100.

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

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

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

Les images étaient le plus grand tue-performance du vieux 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 tant que PNG provenant directement de la machine d'un designer. Certaines images faisaient 3-4 MB.

Ce que nous avons fait

Utilisé next/image pour chaque image. Ce composant fait beaucoup de travail lourd :

import Image from 'next/image';

export function HeroImage({ src, alt }) {
  return (
    <Image
      src={src}
      alt={alt}
      width={1200}
      height={630}
      priority // Image héros au-dessus de la ligne de flottaison : la précharger
      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 pour que les utilisateurs mobiles ne téléchargent pas des images de taille desktop.
  • Chargement lazy par défaut : Les images en dessous de la ligne de flottaison ne se chargent pas jusqu'à ce que l'utilisateur scrolle à proximité.
  • Dimensions explicites : Les props width et height réservent l'espace dans la mise en page, ce qui corrige directement le CLS.

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

Le prop priority sur l'image héros était critique. Sans lui, Next.js charge l'image de manière lazy. Mais si l'image héros est l'élément LCP — ce qu'elle était sur la plupart des pages de SleepDr — le chargement lazy aggrave en réalité votre score LCP. Vous voulez qu'elle commence à télécharger immédiatement.

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

Image CDN

L'optimisation d'image 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 ultérieurs obtiennent la version mise en cache et optimisée en millisecondes. Pas besoin d'abonnement Cloudinary. Pas de plugin WordPress essayant de faire la même chose mais pire.

Impact net : LCP a chuté de 6,8 s à environ 3,8 s à partir de l'optimisation des images seule. Les gains LCP restants sont venus 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 polices Google via des liens de feuille de style externe. Chacun était une demande de blocage de rendu à 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 le texte.

Ce que nous avons fait

Polices auto-hébergées en 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 : Pas de demandes réseau externes. Les polices sont regroupées avec la construction et servies à partir du même CDN.
  • Sous-ensemble automatique : N'inclut que les jeux de caractères que vous utilisez réellement. Le sous-ensemble Latin d'Inter est d'environ 20 KB au lieu de 100 KB+ complet.
  • display: 'swap' : Le texte s'affiche immédiatement avec une police de secours, puis s'échange avec la police web une fois qu'elle est chargée. Pas de texte invisible. Aucun contenu sans style qui bloque FCP.
  • Injection de variables CSS : La police est appliquée via des propriétés CSS personnalisées, ce qui signifie zéro changement de mise en page lorsque la police s'échange car nous avons soigneusement fait correspondre les métriques de la police de secours.

Nous avons également supprimé la troisième police entièrement. 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 seconde en éliminant les demandes de police qui bloquent le rendu.

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

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

D'où venait tout ce JavaScript?

Le site WordPress chargeait :

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

JavaScript total au chargement de la page : environ 1,8 MB. 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 à usage unique :

  • Formulaire de contact : composant React de 4 KB + action serveur Supabase
  • Consentement aux cookies : composant de 2 KB 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 (< 1 KB)

Imports dynamiques pour tout ce qui est en dessous de la ligne de flottaison :

import dynamic from 'next/dynamic';

const NewsletterSignup = dynamic(
  () => import('@/components/NewsletterSignup'),
  { ssr: false } // Se charge uniquement sur le client, uniquement 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 — tout rendu côté serveur sans JavaScript côté client. Seuls les éléments interactifs (le basculement du menu mobile, le formulaire de contact, l'inscription à la newsletter) envoyaient JS au navigateur.

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

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

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

TTFB mesure le temps qu'il faut au serveur pour commencer à 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 passe — avant le chargement des images, avant le téléchargement des polices, avant l'exécution de JavaScript — 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 noyau WordPress
  4. Passait par 34 hooks de plugin
  5. Effectuait plusieurs requêtes MySQL
  6. Générait HTML de manière dynamique
  7. Envoyait la réponse

Même avec WP Super Cache installé, le taux de succès du cache était incohérent et le serveur lui-même était sous-alimenté.

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 au format HTML statique. Le résultat est un ensemble de fichiers .html assis sur le réseau edge de Vercel — distribué sur plus de 80 emplacements mondiaux.

Lorsqu'un utilisateur demande un article de blog, un fichier HTML pré-construit est servi à partir du nœud edge le plus proche. Pas de requête de base de données. Pas de 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 100 ms car le calcul se produit à la périphérie, pas dans un centre de données centralisé.

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

Optimisation 5 : Gestion des scripts tiers

Les scripts tiers sont les tueurs silencieux des performances 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 la <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 : se 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 : se charger quand le navigateur est inactif */}
<Script
  src="/scripts/cookie-consent.js"
  strategy="lazyOnload"
/>

La stratégie afterInteractive charge le script après que Next.js termine l'hydratation. 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 (< 1 KB, axé sur la confidentialité, pas de consentement aux cookies nécessaire dans la plupart des juridictions). Supprimé Hotjar entièrement — SleepDr ne révisait pas réellement les enregistrements. Supprimé le pixel Facebook puisqu'ils avaient arrêté d'exécuter des annonces Facebook six mois plus tôt.

Éliminer les scripts tiers inutiles est le gain de performance le plus facile du développement web. Je continue à le dire. La plupart des sites chargent des scripts pour des services que personne sur l'équipe n'utilise activement.

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

Le thème WordPress de SleepDr livrait environ 800 KB de CSS. Cela incluait 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 scanne vos fichiers de template au moment de la construction et génère CSS uniquement pour les classes d'utilitaire que vous utilisez réellement. Notre bundle CSS de production : 35 KB (gzippé : ~8 KB).

// 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 est d'environ 500 octets. Poids total des icônes : ~6 KB contre 70 KB+ de Font Awesome.

Le résultat est zéro demandes CSS qui bloquent le rendu. La sortie de Tailwind est en ligne dans la charge utile HTML initiale par Next.js, pour que le navigateur puisse commencer à afficher immédiatement.

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

La checklist étape par étape

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

Phase 1 : Victoires rapides (Semaine 1)

  • Exécutez Lighthouse sur vos 10 pages les plus visitées (mode mobile)
  • Identifiez les éléments LCP sur chaque template de page
  • Ajoutez width et height explicites à toutes les images et iframes
  • Ajoutez loading="lazy" aux images en dessous de 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 : Police et CSS (Semaine 2)

  • Auto-hébergez les polices web (éliminez les demandes de police externe)
  • Ajoutez font-display: swap à toutes les déclarations @font-face
  • Réduisez les polices à seulement les jeux 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)

  • Analysez le bundle pour identifier les plus grandes dépendances JS
  • Supprimez jQuery si possible
  • Importez de manière dynamique les composants non critiques
  • Reportez le JavaScript non essentiel
  • Implémentez le fractionnement du code par route

Phase 4 : Infrastructure (Semaine 4+)

  • Évaluez les options CDN / déploiement 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 fait ce type exact de projet plusieurs fois. Notre page de tarification contient les détails sur le coût typique des migrations headless.

Ce que les Core Web Vitals 2026 signifient pour votre site

La mise à jour principale de Google en mars 2026 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 lent utilisé par 200 articles de blog entraînera le classement de tout votre site
  • Les pages à fort trafic ont plus de poids dans le score global
  • Vous ne pouvez pas simplement optimiser votre page d'accueil et appeler ça fini

Les données initiales du déploiement montrent que les sites avec un CWV médiocre ont connu une baisse du trafic organique de 20-35 %. Certains ont vu des pertes supérieures à 50 %. Les sites qui se sont rétablis le plus rapidement étaient ceux qui ont abordé les performances au niveau de l'infrastructure — pas en optimisant 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 pour 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 — surtout pour les sites riches en contenu où vous voulez zéro JavaScript par défaut.

Approche Coût typique Calendrier Gain Lighthouse attendu
Optimisation de plugin WordPress (WP Rocket, ShortPixel) 100-500 $ par an 1-2 semaines +10-20 points
Remplacement de 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 du CMS, les composants personnalisés et l'optimisation des performances. L'hébergement sur Vercel coûte $20/mois sur le plan Pro. C'est environ $740/an d'hébergement contre les $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 dépassé les niveaux d'avant le déclin à la semaine 10. Pour une entreprise qui dépend de la recherche organique, la migration s'est remboursée dans le premier trimestre.

FAQ

Combien de temps faut-il aux améliorations des Core Web Vitals pour affecter les classements Google? Selon 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 re-crawler vos pages, collecter de nouvelles données de champ auprès des vrais utilisateurs de Chrome (données CrUX), et considérer cela dans ses algorithmes de classement. N'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 réellement 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 en laboratoire au-dessus de 90 sur mobile sont réalisables avec des 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 edge. La clé est que chaque composant doit être conscient des performances. 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 bien se classer 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éalistiquement cependant, la plupart des sites WordPress que nous auditons obtiennent entre 30-60 sur mobile en raison du bloat accumulé des plugins et de la surcharge du thème. Si vous êtes en dessous de 50, l'optimisation seule des plugins ne vous amènera probablement pas au-dessus de 75. Une approche headless — où WordPress sert d'API de contenu tandis qu'un framework frontend gère le rendu — est souvent le terrain intermédiaire qui vaut la peine d'être exploré.

Quelle est la différence entre les scores Lighthouse et les données réelles des Core Web Vitals? Lighthouse est un outil de laboratoire — il simule un téléphone milieu de gamme sur une 4G limitée et vous donne des scores synthétiques. Core Web Vitals dans Search Console sont des données de champ — des mesures réelles auprès des vrais utilisateurs de Chrome visitant votre site au cours d'une fenêtre roulante 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 corrections, mais votre objectif est un statut CWV vert dans Search Console au 75e percentile.

Quelle est l'optimisation unique la plus impactante pour LCP? Optimisation des images. Dans environ 60 % des sites que nous auditons, l'élément LCP est une image. Son dimensionnement correct, son service au format WebP/AVIF, l'ajout de fetchpriority="high", et s'assurer qu'il ne se charge pas de manière lazy réduira généralement LCP de 2-4 secondes. Chez SleepDr, l'optimisation des images seule représentait environ 3 secondes d'amélioration LCP.

Comment fonctionne la notation hollistique CWV de Google en 2026? Depuis la mise à jour principale de Google en 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 entraînera également vos classements de page d'accueil. La correction est architecturale — vous avez besoin que chaque modèle de page réussisse les seuils CWV, pas seulement vos pages de destination clés.

Combien coûte généralement une migration WordPress vers Next.js? Pour un site de contenu similaire à SleepDr (200+ pages, mise en page standard du blog, formulaires de contact, pas de commerce électronique), attendez-vous à $15 000-30 000 d'une agence expérimentée. Les migrations de commerce électronique 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 connu une baisse de trafic due à un CWV médiocre, la migration se rembourse généralement en 3-6 mois.

Dois-je me concentrer sur les scores Lighthouse mobiles ou desktop? Mobile. Toujours mobile d'abord. Google utilise l'indexation mobile-first, et la notation Lighthouse mobile est nettement plus punitive que le desktop car elle simule un appareil et un réseau contraints. Si votre score mobile est 94, votre score desktop sera presque certainement 95+. Le score desktop de SleepDr de 99 n'a nécessité aucun travail supplémentaire au-delà de ce que nous avons fait pour l'optimisation mobile.