Foire aux questions

Oui, officiellement depuis 2021. Mais ils fonctionnent comme un facteur de départage, pas comme un levier autonome. Une page avec un excellent contenu et de mauvais CWV peut très bien se classer, mais sur des requêtes compétitives, les CWV peuvent faire la différence entre la position 3 et la position 1.

Les web vitals désignent l'ensemble des métriques de performance web définies par Google (TTFB, FCP, LCP, INP, CLS, etc.). Les Core Web Vitals sont les trois métriques officiellement retenues comme signaux de classement : LCP, INP et CLS. Ce sont les web vitals "essentiels".

PageSpeed Insights affiche des données de labo (simulation) et des données de terrain si disponibles. Search Console utilise uniquement les données de terrain réelles (CrUX) sur 28 jours. Un score de labo de 90/100 ne garantit pas de bonnes données terrain : les conditions réelles (appareils mobiles bas de gamme, connexions 4G lentes) sont souvent bien moins favorables.

Search Console agrège les données sur 28 jours glissants. Après une optimisation, comptez 4 à 6 semaines avant que le rapport reflète pleinement l'amélioration. Les données de terrain mettent du temps à se renouveler.

Oui. Google évalue les CWV séparément pour mobile et desktop dans Search Console. Sur la majorité des sites e-commerce, le mobile est plus problématique, et c'est la version mobile qui pèse le plus dans le classement depuis le passage au mobile-first indexing.

Le LCP est généralement le premier à corriger : les images produit et les sliders sont des sources fréquentes de LCP lent. L'INP est souvent le plus difficile à améliorer sur les plateformes comme Shopify ou WooCommerce à cause de la densité de scripts tiers. Le CLS est souvent le plus rapide à corriger une fois les images dimensionnées et les pop-ins maîtrisés.

Oui, et c'est documenté. Google a mesuré qu'un LCP > 4 s triple le taux de rebond. Des études sectorielles montrent qu'une amélioration de 100 ms du temps de chargement peut augmenter le taux de conversion de 1 à 3 % sur les sites e-commerce. L'optimisation CWV n'est pas qu'un enjeu SEO, c'est un enjeu business direct.

Le plus simple : un audit performance web qui combine PageSpeed Insights, Search Console, Chrome DevTools et WebPageTest pour identifier précisément les leviers prioritaires sur votre stack. Sans diagnostic terrain, on optimise à l'aveugle.

Oui, complètement. Lighthouse mesure en conditions simulées : appareil Moto G4 émulé, CPU 4× plus lent, réseau Slow 4G. Search Console reflète vos vrais visiteurs sur leurs appareils et connexions réels. Si votre audience est sur des devices récents et des connexions rapides, l'écart peut être considérable : j'ai observé un LCP lab à 14,6 s sur un site dont le LCP terrain (CrUX) est à 1,7 s. Pour le SEO et la conversion, c'est la donnée terrain qui compte.

PageSpeed Insights intègre deux sources : un rapport Lighthouse (lab data) exécuté en temps réel, et les données CrUX terrain issues du Chrome UX Report. Lighthouse seul ne montre que le lab. PSI est donc plus complet : il permet de confronter les scores lab à ce que vos vrais utilisateurs vivent. Pour des pages derrière authentification ou pour automatiser des tests en CI/CD, le CLI Lighthouse reste plus adapté.

Non, directement. Le score composite (0–100) n'est pas un signal de ranking. Ce qui compte pour le SEO, ce sont les Core Web Vitals terrain (LCP, INP, CLS) mesurés par Google via CrUX. Un score Lighthouse de 40 avec des CWV verts en terrain aura plus de poids SEO qu'un score de 90 avec des CWV rouges. Lighthouse sert à diagnostiquer ; les données terrain servent à décider.

Le profil mobile émule un CPU 4× plus lent que votre machine et une connexion Slow 4G (1,6 Mbps). Le profil desktop utilise votre machine réelle sans bridage réseau significatif. L'écart peut dépasser 40 points sur des pages avec du JavaScript lourd ou des images non optimisées. C'est délibéré : le profil mobile est calibré pour représenter les conditions du bas du parc mondial, pas les conditions de vos utilisateurs réels.

LCP (25 %) et TBT (30 %) pèsent 55 % du score à eux deux : c'est là qu'il faut attaquer en premier. Sur le LCP, viser l'image concernée : format AVIF ou WebP, fetchpriority="high", preload de la ressource, aucun script bloquant devant. Sur le TBT, réduire le JavaScript bloquant via code splitting, defer sur les tiers non critiques, et suppression pure des scripts qui ne servent pas le premier rendu. CLS (25 %) vient ensuite, et la correction est souvent rapide : déclarer width/height sur toutes les images, aspect-ratio sur les conteneurs médias, et font-display: swap sur les polices web.

À chaque déploiement significatif côté front (nouveau composant, mise à jour de framework, ajout d'un script tiers). En dehors des déploiements, une fois par mois suffit pour les sites à trafic modéré. Pour les sites critiques, un monitoring automatisé via Lighthouse CI en pipeline est plus fiable qu'une vérification manuelle : il détecte les régressions au moment où elles se produisent.

30 secondes dans Chrome : F12, onglet Lighthouse, bouton Analyser. Pour un audit fiable et reproductible : fenêtre de navigation privée, extensions désactivées, 3 runs consécutifs avec prise de la médiane. Comptez 5 à 10 minutes pour un premier audit sérieux, interprétation des résultats comprise. La difficulté n'est pas de lancer l'audit, c'est de lire les résultats sans les sortir de leur contexte.

Indirectement. Le TTFB n'est pas un signal de ranking direct, mais il influence le LCP, qui est un Core Web Vital intégré au Page Experience Signal depuis 2021. Un TTFB élevé retarde le rendu de l'élément LCP, ce qui dégrade le score terrain. À contenu et backlinks équivalents, le site avec le TTFB le plus bas prend l'avantage sur les requêtes concurrentielles.

Le TTFB mesure le délai jusqu'au premier octet de la réponse HTTP : pure performance serveur, avant même que le navigateur ait commencé à parser. Le LCP mesure le moment où le plus grand élément visible arrive dans le viewport, côté utilisateur. Le LCP se décompose en quatre phases dont le TTFB est la première : un TTFB de 800 ms consomme déjà 800 ms de votre budget LCP avant tout traitement navigateur. Si votre cible LCP est 2,5 s, il ne reste que 1,7 s pour tout le reste.

WebPageTest simule une seule localisation dans des conditions déterministes. La Search Console agrège 28 jours de données réelles au P75, toutes localisations et tous réseaux confondus. L'écart révèle souvent un CDN mal configuré (pas d'edge caching sur certaines régions) ou un TTFB qui se dégrade sous charge. Fiez-vous aux données terrain pour les décisions.

La Search Console utilise une fenêtre glissante de 28 jours. Après une correction, comptez 4 à 6 semaines avant de voir l'amélioration reflétée dans le rapport Core Web Vitals. Les données CrUX sont mises à jour mensuellement. Si vous utilisez un outil RUM (Real User Monitoring), l'impact est visible dès les premières heures.

Oui, mais seulement pour les utilisateurs géographiquement proches du serveur. Un cache de page serveur bien configuré peut descendre à 20-50 ms depuis la même région. Depuis une autre région (serveur en France, utilisateur à Singapour), la latence réseau seule ajoute 150-200 ms incompressibles. Le CDN est la seule façon d'atteindre des TTFB bas mondialement.

Chaque combinaison de paramètres uniques (filtres, triages, couleurs) peut générer une clé de cache distincte. Sur un catalogue avec 20 filtres de 5 valeurs chacun, cela représente des milliers d'entrées de cache qui ne seront jamais réchauffées. La majorité des requêtes tombe en cache miss et atteint le serveur applicatif, annulant l'effet du cache malgré sa présence.

Google fixe le seuil "bon" à moins de 800 ms au P75 en données terrain. C'est le plancher, pas l'objectif. Les meilleurs sites e-commerce français que j'accompagne visent moins de 400 ms au P75, et 80 à 200 ms sur les visiteurs européens grâce à un CDN edge bien configuré et un cache de page complet côté origine. Pour benchmarker, lancez un test WebPageTest depuis Paris en profil mobile (Moto G4, 4G) : c'est le calibre qui permet de comparer vos performances aux concurrents dans les mêmes conditions.

Oui. Depuis 2021, les CWV font partie des signaux "Page Experience" utilisés par Google pour le ranking. Sur des requêtes très concurrentielles (ex. : "chaussures running homme"), à contenu équivalent, un site avec de bons CWV prendra l'avantage. L'impact est modéré mais réel - et il s'additionne à l'impact direct sur la conversion.

FID mesurait uniquement le délai avant la première interaction. INP mesure la latence de toutes les interactions tout au long de la session (clics, taps, touches clavier). INP est bien plus représentatif de l'expérience réelle sur un site e-commerce où l'utilisateur clique sur des filtres, ajoute des produits au panier, ouvre des menus. FID a été retiré des CWV en mars 2024.

Lighthouse est un test en laboratoire sur une connexion simulée, sans scripts tiers actifs, sans cookies, sans état utilisateur. Les CWV terrain mesurent vos vrais utilisateurs, avec leur connexion mobile réelle, leurs extensions Chrome, vos scripts marketing actifs. L'écart peut être énorme. Faites confiance aux données terrain (Search Console, CrUX).

Google met à jour les données CWV dans Search Console avec un décalage de 28 jours glissants. Après une correction, comptez 4 à 6 semaines avant de voir l'amélioration reflétée dans les rapports. Les données CrUX sont mises à jour mensuellement.

Oui, mais avec des contraintes. Le TTFB et l'infrastructure sont gérés par Shopify - vous ne pouvez pas toucher au serveur. En revanche, vous contrôlez le thème (images, polices, CSS, JS), les apps installées (chaque app ajoute du JS), et le code Liquid. Les gains les plus importants viennent souvent de la suppression d'apps inutiles et de l'optimisation des images.

LCP en premier, car il conditionne la perception de vitesse dès l'arrivée sur la page. INP en second, car il affecte directement l'expérience d'achat (filtres, panier, checkout). CLS en troisième - un CLS élevé génère des clics accidentels et de la frustration, mais son impact conversion est plus indirect.

PageSpeed Insights, en premier. Le signal Page Experience de Google s'appuie sur les données terrain CrUX, et c'est précisément ce que PSI affiche au-dessus du score Lighthouse - au 75e percentile sur 28 jours glissants. WebPageTest n'a pas accès à cette donnée. En revanche, dès qu'il faut comprendre pourquoi un LCP est mauvais, WPT reprend la main avec son waterfall et son filmstrip. La règle pratique : PSI pour mesurer ce que Google voit, WPT pour comprendre quoi corriger.

Parce que ce sont deux mesures différentes dans le même rapport. Le score 0-100 vient de Lighthouse en lab data : un seul run, un seul device (Moto G4 émulé), un seul réseau (Slow 4G), un seul datacenter Google. Le bloc CrUX, lui, agrège vos vrais utilisateurs Chrome sur 28 jours au P75 : des terminaux variés, des connexions variées, des localisations variées. Faire confiance au terrain : c'est lui que Google utilise pour le ranking.

Oui, en partie. Le plan Starter est gratuit et donne accès à 30 localisations dans le monde, au filmstrip, au waterfall et aux Core Web Vitals - avec une limite de 300 tests par mois. Le plan Pro démarre à environ 18,75 $/mois et débloque l'API, les tests planifiés, le scripting avancé, les localisations premium et la priorité de file. Pour un audit ponctuel, le plan gratuit suffit. Pour du monitoring continu, l'API est indispensable.

Paris (EU West) si votre audience est francophone, c'est la plus représentative. Mais surtout ne testez pas qu'une seule localisation : un site qui charge en 1,2 s depuis Paris peut afficher 4,8 s depuis Mumbai ou São Paulo. Si vous servez l'international ou si votre CDN couvre plusieurs zones, testez systématiquement depuis 2-3 localisations contrastées. C'est la seule façon de valider qu'un edge fonctionne comme prévu.

Oui, exactement la même chose. PSI exécute Lighthouse 13 dans un environnement Google avec un profil mobile fixé (Moto G4 émulé, Slow 4G, CPU 4× ralenti). Vous obtiendrez donc des résultats très proches de lighthouse https://example.com lancé localement avec les mêmes settings, à l'environnement réseau près. La différence majeure de PSI, c'est l'ajout du bloc CrUX au-dessus du score Lighthouse, qui n'existe pas dans le CLI.

Une heure pour lire un waterfall et un filmstrip basique, une demi-journée pour exploiter sérieusement les comparaisons multi-runs, le scripting et l'API. La courbe est plus raide que PSI (qui s'utilise en 30 secondes), mais elle paie vite : un waterfall bien lu fait gagner des heures de devinette. Le piège classique du débutant est de tirer des conclusions d'un seul run - toujours en faire au moins 3 et prendre la médiane.

WebPageTest oui, via son langage de scripting (navigate, setCookie, setValue, clickAndWait, logData). Vous pouvez naviguer jusqu'à la page protégée et n'enregistrer les métriques que sur celle-ci. PageSpeed Insights non : il ne charge qu'une URL publique en GET, sans interaction. Pour les pages authentifiées, c'est WPT ou rien - à défaut, une copie publique de la page avec les mêmes assets, à mesurer dans PSI.

Oui, l'API PageSpeed Insights v5 est gratuite avec une clé Google. Quota : 25 000 requêtes par jour et 400 par 100 secondes, largement assez pour auditer un catalogue de plusieurs centaines d'URLs au quotidien. C'est ce qui en fait l'option par défaut pour un monitoring de masse, là où l'API WebPageTest (réservée au plan Pro) est plus adaptée à un sous-ensemble de pages stratégiques.

Le diagnostic seul prend 5 jours ouvrés. L'implémentation des correctifs varie de 2 à 6 semaines selon la complexité de la stack et le nombre de blocages identifiés. Les résultats terrain (CrUX) sont mesurables après 28 à 35 jours, le temps que Google collecte suffisamment de données post-correction.

Pas nécessairement, mais le score Lighthouse ne suffit pas pour répondre à cette question. Lighthouse est une mesure de lab (condition contrôlée, réseau simulé, aucun visiteur réel). Ce qui compte, ce sont les données terrain : LCP, INP et CLS mesurés sur les vrais visiteurs via CrUX ou un outil RUM. J'ai vu des sites à 85 en Lighthouse avec un LCP terrain de 4 secondes sur mobile.

Le "temps de chargement" est une notion floue qui correspond souvent à l'événement load (quand toutes les ressources sont téléchargées). Ce n'est pas ce que ressent l'utilisateur. Les Core Web Vitals mesurent des expériences précises : LCP (quand le contenu principal est visible), INP (réactivité aux interactions), CLS (stabilité visuelle). Ce sont ces trois métriques que Google utilise comme signaux de classement.

Partiellement. Des gains significatifs sont souvent accessibles sans modifier le code applicatif : configuration CDN, compression Brotli, optimisation des images, cache HTTP agressif, suppression de scripts tiers non critiques via le tag manager. Sur un site WordPress, ces optimisations infrastructure peuvent représenter 50 à 70 % des gains totaux. Au-delà, les gains résiduels demandent d'intervenir dans le code.

Oui, depuis le déploiement du signal Page Experience en 2021. Les Core Web Vitals sont un facteur de ranking confirmé. Sur des requêtes très concurrentielles, à qualité de contenu comparable, le site le plus rapide prend l'avantage. L'impact est réel mais modéré sur la majorité des requêtes ; il s'additionne cependant à l'effet direct sur le taux de conversion et le taux de rebond.

Ça dépend de ce que vous savez déjà. Si vous n'avez aucune idée d'où vient le problème, le diagnostic complet (données terrain croisées avec analyse synthétique) est la bonne entrée de jeu : il vous évite de corriger la mauvaise chose. Si vous avez déjà des données CrUX dégradées sur une métrique précise et que vous cherchez la cause racine, je peux intervenir de façon plus ciblée.

Un serveur rapide ne garantit pas un site rapide. Le TTFB (Time to First Byte) peut être excellent à 150 ms et le LCP terrain dépasser 5 secondes si le HTML reçu doit encore télécharger 3 Mo d'images non optimisées et exécuter 800 Ko de JavaScript avant d'afficher quoi que ce soit. La vitesse d'un site, c'est la somme du serveur, du réseau, du navigateur et du code front-end. L'hébergeur ne voit qu'une partie.

Principalement des sites e-commerce, des sites institutionnels B2B et des plateformes de réservation ou de services en ligne. Les stacks les plus fréquentes dans mes missions : WordPress/WooCommerce, Shopify, Next.js, applications React sur infrastructure AWS ou Cloudflare. Je travaille aussi bien sur des projets de 20 000 sessions/mois que sur des sites à 2 millions de visites mensuelles.

Non, WP Super Cache (gratuit, WordPress.org) ou le cache natif de votre hébergeur (Kinsta, WP Engine, SiteGround) suffisent pour la majorité des sites. Les plugins payants comme WP Rocket (59 $/an) ou LiteSpeed Cache (sur hébergement LiteSpeed) apportent une valeur réelle pour les sites à fort trafic ou e-commerce grâce à l'intégration complète : cache + assets + images + CDN en un seul outil.

Souvent non. WP Rocket règle le cache, la minification et le lazy loading, mais il ne peut pas compenser un hébergement lent (TTFB élevé), des images surdimensionnées non converties en WebP, ou une interaction JavaScript bloquée par un plugin tiers. Les Core Web Vitals sont une mesure terrain : WP Rocket améliore les données lab (Lighthouse), mais le gain terrain dépend de l'ensemble de la stack.

Lighthouse mesure un chargement de page simulé dans des conditions contrôlées (réseau 4G throttlé, CPU throttlé x4). Les CWV dans Search Console sont les données réelles de vos visiteurs : mobile lent en 3G, navigateur avec extensions, contenu tiers qui se charge différemment selon les pays. Les deux mesures divergent particulièrement sur l'INP, qui n'existe pas dans Lighthouse 10 (remplacé par TBT, une approximation).

Pour les petits sites : Infomaniak, o2switch ou PlanetHoster (hébergement mutualisé français avec serveurs LiteSpeed) offrent des TTFB entre 200 et 400 ms à 5-10 €/mois. Pour les sites à trafic moyen (10 000+ visites/mois) : un VPS chez OVH, Scaleway ou Hetzner avec Nginx FastCGI Cache passe sous les 60 ms de TTFB pour moins de 15 €/mois. Les hébergements managés WordPress (Kinsta, Rocket.net) démarrent à 30-35 $/mois mais incluent un CDN intégré et un support performance dédié.

Oui, indirectement. WordPress 6.5 et les versions récentes de Gutenberg ont apporté des améliorations de performance notables côté rendu. Certains plugins optimisent activement leur code à chaque version. En pratique, maintenir le core et les plugins à jour évite d'accumuler du code déprécié qui ralentit PHP, et corrige des régressions de performance introduites par des versions antérieures.

La méthode fiable : tester avec WebPageTest en filmstrip avant/après activation du plugin, en vidant le cache entre chaque test. Query Monitor affiche également le nombre de requêtes SQL et la mémoire consommée par plugin. Pour les scripts JS, le panneau Performance de Chrome DevTools (onglet Network filtré) montre ce que chaque plugin charge et son coût en temps de parse/exécution.

Ils ne jouent pas exactement le même rôle. Perfmatters (25 $/an) est spécialisé dans la désactivation chirurgicale des scripts/styles par page et le retrait des bloatwares WordPress (embeds, emojis, REST API non utilisée). WP Rocket (59 $/an) inclut en plus le cache de page, la minification et l'intégration CDN. La combinaison Perfmatters + cache serveur natif (Nginx ou hébergeur) dépasse souvent WP Rocket seul en performance, pour un coût global similaire sur un VPS.

Oui. Depuis le déploiement du signal Page Experience en 2021, les CWV font partie des facteurs de classement Google. L'impact est pondéré : sur des requêtes très compétitives, à contenu équivalent, un site avec de bons CWV prend l'avantage sur un concurrent dont les métriques sont en zone rouge. L'effet direct est difficile à isoler, mais l'effet indirect (rebond réduit, engagement amélioré) contribue aux signaux comportementaux que Google mesure.

Les données lab de Lighthouse simulent un utilisateur dans des conditions réseau contrôlées (4G throttled, CPU ralenti). Elles sont reproductibles et utiles pour diagnostiquer. Les données de terrain de Search Console proviennent de vrais utilisateurs Chrome sur leurs appareils réels, agrégées sur 28 jours. Un score Lighthouse excellent peut coexister avec des données terrain rouges si votre audience utilise des appareils anciens ou des connexions dégradées. Fiez-vous au terrain pour valider, au lab pour investiguer.

Parce que Lighthouse mesure une session simulée, pas vos utilisateurs réels. Les causes les plus fréquentes de cet écart : trafic mobile sur des appareils anciens (median Android en France = processeur 4 à 6 fois plus lent que le MacBook utilisé pour tester), scripts tiers actifs uniquement en dehors du mode incognito de Lighthouse, ou ressources LCP non distribuées sur CDN dans certaines régions. Le score Lighthouse est un indicateur de qualité technique, pas un miroir des données CrUX.

Comptez 4 à 6 semaines. Google met à jour les données CrUX avec un délai de 28 jours glissants. Une correction déployée le 1er juin commencera à être reflétée autour du 15 juin et sera pleinement visible vers le 1er juillet. Ne pas évaluer l'efficacité d'une correction avant ce délai.

Oui, depuis le déploiement du "Page Experience Update" de Google en 2021. Les CWV font partie des signaux de qualité de page utilisés dans l'algorithme. L'impact sur le ranking est réel mais modéré : sur des requêtes compétitives, à pertinence de contenu égale, le site avec les meilleurs CWV prend l'avantage. L'effet est plus visible sur mobile, segment où les écarts de performance sont les plus importants.

Utiliser le nœud Paris (OVH ou Hetzner) pour une mesure représentative d'un trafic majoritairement français. Pour diagnostiquer un problème CDN ou mesurer l'expérience internationale, comparer Paris avec un nœud distant (Singapour, São Paulo). Un LCP de 1,2 s depuis Paris contre 5,8 s depuis Singapour signale une ressource statique (image, police) non distribuée sur le CDN ou une origine serveur non géo-distribuée.

Presque, mais pas exactement. PageSpeed Insights exécute Lighthouse sur les serveurs de Google avec une configuration standardisée et ajoute les données CrUX en haut de page. Lighthouse CLI exécuté localement peut donner des scores légèrement différents selon la connexion et les ressources CPU de la machine hôte. Pour des tests reproductibles en CI/CD, utiliser Lighthouse CLI avec --throttling-method=simulate pour s'affranchir des variations réseau locales.

L'URL n'a pas assez de données CrUX : moins de 1 000 visites Chrome sur 28 jours. Dans ce cas, Search Console ne peut pas afficher de données terrain pour cette URL spécifiquement. Deux options : analyser les données au niveau de l'origine (domaine entier) via la CrUX API, ou utiliser les données lab de Lighthouse et WebPageTest comme proxy de diagnostic. Pour un site en croissance, c'est une situation normale ; les pages à trafic élevé restent prioritaires.

Les deux, mais priorité au mobile. Google utilise les signaux CWV de la version mobile pour le ranking. Sur mobile, les conditions sont systématiquement plus dégradées : appareils moins puissants, connexions variables. Un LCP de 2,1 s en desktop peut atteindre 4,8 s sur mobile. Lighthouse propose deux modes (mobile par défaut avec throttling, desktop sans throttling) : toujours vérifier les deux pour identifier les optimisations critiques sur chaque surface.