Frequently asked questions

Yes, officially since 2021. But they work as a tiebreaker factor, not as a standalone lever. A page with excellent content and poor CWV can still rank very well — but on competitive queries, CWV can make the difference between position 3 and position 1.

Web vitals refer to the complete set of web performance metrics defined by Google (TTFB, FCP, LCP, INP, CLS, etc.). Core Web Vitals are the three metrics officially selected as ranking signals: LCP, INP, and CLS. These are the "essential" web vitals.

PageSpeed Insights displays lab data (simulation) and field data when available. Search Console uses only real field data (CrUX) over 28 days. A lab score of 90/100 does not guarantee good field data — real-world conditions (low-end mobile devices, slow 4G connections) are often far less favorable.

Search Console aggregates data over a rolling 28-day period. After an optimization, allow 4 to 6 weeks before the report fully reflects the improvement. Field data takes time to refresh.

Yes. Google evaluates CWV separately for mobile and desktop in Search Console. On the majority of e-commerce sites, mobile is more problematic — and it's the mobile version that carries the most weight in rankings since the switch to mobile-first indexing.

LCP is generally the first to fix — product images and sliders are frequent sources of slow LCP. INP is often the hardest to improve on platforms like Shopify or WooCommerce due to the density of third-party scripts. CLS is often the quickest to fix once images are sized and pop-ins are controlled.

Yes, and it's well documented. Google has measured that an LCP > 4s triples the bounce rate. Industry studies show that a 100ms improvement in load time can increase conversion rates by 1 to 3% on e-commerce sites. CWV optimization is not just an SEO issue — it's a direct business issue.

The simplest approach: a web performance audit that combines PageSpeed Insights, Search Console, Chrome DevTools and WebPageTest to precisely identify the priority levers on your stack. Without a field diagnosis, you're optimizing blind.

Yes, completely. Lighthouse measures under simulated conditions: emulated Moto G4 device, CPU 4× slower, Slow 4G network. Search Console reflects your real visitors on their actual devices and connections. If your audience uses recent devices and fast connections, the gap can be considerable — I've observed a lab LCP of 14.6s on a site whose field LCP (CrUX) sits at 1.7s. For SEO and conversion, field data is what counts.

PageSpeed Insights combines two sources: a Lighthouse report (lab data) run in real time, and CrUX field data from the Chrome UX Report. Lighthouse alone only shows lab data. PSI is therefore more complete — it lets you compare lab scores against what your real users actually experience. For pages behind authentication or to automate tests in CI/CD, the Lighthouse CLI remains more appropriate.

Not directly. The composite score (0–100) is not a ranking signal. What matters for SEO are the field Core Web Vitals (LCP, INP, CLS) measured by Google via CrUX. A Lighthouse score of 40 with green field CWV will carry more SEO weight than a score of 90 with red CWV. Lighthouse is for diagnosing — field data is for deciding.

The mobile profile emulates a CPU 4× slower than your machine and a Slow 4G connection (1.6 Mbps). The desktop profile uses your actual machine with no significant network throttling. The gap can exceed 40 points on pages with heavy JavaScript or unoptimized images. This is deliberate: the mobile profile is calibrated to represent conditions at the bottom of the global device range, not your real users' conditions.

LCP (25%) and TBT (30%) together account for 55% of the score — that's where you attack first. On LCP, target the image itself: AVIF or WebP format, fetchpriority="high", resource preload, no blocking scripts in front. On TBT, reduce blocking JavaScript through code splitting, defer on non-critical third parties, and outright removal of scripts that don't serve the first render. CLS (25%) comes next, and the fix is often quick: declare width/height on every image, aspect-ratio on media containers, and font-display: swap on web fonts.

After every significant front-end deployment (new component, framework update, addition of a third-party script). Outside of deployments, once a month is enough for moderate-traffic sites. For critical sites, automated monitoring via Lighthouse CI in a pipeline is more reliable than manual checks — it catches regressions the moment they occur.

30 seconds in Chrome: F12, Lighthouse tab, Analyze button. For a reliable, reproducible audit: private browsing window, extensions disabled, 3 consecutive runs with the median taken. Allow 5 to 10 minutes for a serious first audit, including interpreting the results. The difficulty isn't running the audit — it's reading the results without taking them out of context.

Indirectly. TTFB is not a direct ranking signal, but it influences LCP, which is a Core Web Vital integrated into the Page Experience Signal since 2021. A high TTFB delays the rendering of the LCP element, which degrades the field score. With equivalent content and backlinks, the site with the lowest TTFB has the advantage on competitive queries.

TTFB measures the delay until the first byte of the HTTP response — pure server performance, before the browser has even started parsing. LCP measures the moment the largest visible element arrives in the viewport, on the user side. LCP breaks down into four phases, of which TTFB is the first: a TTFB of 800 ms already consumes 800 ms of your LCP budget before any browser processing. If your LCP target is 2.5 s, only 1.7 s remain for everything else.

WebPageTest simulates a single location under deterministic conditions. Search Console aggregates 28 days of real data at P75, across all locations and all networks. The gap often reveals a misconfigured CDN (no edge caching in certain regions) or a TTFB that degrades under load. Rely on field data for decisions.

Search Console uses a rolling 28-day window. After a fix, allow 4 to 6 weeks before the improvement is reflected in the Core Web Vitals report. CrUX data is updated monthly. If you use a RUM (Real User Monitoring) tool, the impact is visible within the first few hours.

Yes, but only for users geographically close to the server. A well-configured server-side page cache can get down to 20–50 ms from the same region. From another region (server in France, user in Singapore), network latency alone adds an irreducible 150–200 ms. A CDN is the only way to achieve low TTFB globally.

Each unique parameter combination (filters, sorts, colors) can generate a distinct cache key. On a catalog with 20 filters of 5 values each, that means thousands of cache entries that will never be warmed. The majority of requests end up as cache misses and reach the application server, nullifying the effect of the cache despite its presence.

Google sets the "good" threshold at under 800 ms at P75 in field data. That's the floor, not the target. The best French e-commerce sites I work with aim for under 400 ms at P75, and 80 to 200 ms on European visitors thanks to a well-configured edge CDN and a full-page cache at the origin. To benchmark, run a WebPageTest from Paris on the mobile profile (Moto G4, 4G): that's the calibration that lets you compare your performance to competitors under identical conditions.

Yes. Since 2021, CWV have been part of the "Page Experience" signals Google uses for ranking. On highly competitive queries (e.g. "men's running shoes"), with equivalent content, a site with good CWV will take the edge. The impact is moderate but real - and it adds to the direct impact on conversion.

FID only measured the delay before the first interaction. INP measures the latency of all interactions throughout the session (clicks, taps, keyboard input). INP is far more representative of the real experience on an e-commerce site where users click filters, add products to the cart, open menus. FID was removed from CWV in March 2024.

Lighthouse is a lab test on a simulated connection, with no active third-party scripts, no cookies, no user state. Field CWV measure your real users, with their actual mobile connection, their Chrome extensions, your live marketing scripts. The gap can be huge. Trust field data (Search Console, CrUX).

Google updates CWV data in Search Console on a 28-day rolling window. After a fix, expect 4 to 6 weeks before seeing the improvement reflected in the reports. CrUX data is updated monthly.

Yes, but with constraints. TTFB and infrastructure are managed by Shopify - you can't touch the server. On the other hand, you control the theme (images, fonts, CSS, JS), the installed apps (each app adds JS), and the Liquid code. The biggest gains often come from removing unused apps and optimizing images.

LCP first, because it shapes the perception of speed from the moment users land on the page. INP second, because it directly affects the shopping experience (filters, cart, checkout). CLS third - a high CLS causes accidental clicks and frustration, but its conversion impact is more indirect.

PageSpeed Insights, first. Google's Page Experience signal relies on CrUX field data, and that's precisely what PSI displays above the Lighthouse score — at the 75th percentile over a 28-day rolling window. WebPageTest doesn't have access to this data. However, once you need to understand why an LCP is poor, WPT takes over with its waterfall and filmstrip. The practical rule: PSI to measure what Google sees, WPT to understand what to fix.

Because they're two different measurements in the same report. The 0-100 score comes from Lighthouse in lab data: a single run, a single device (emulated Moto G4), a single network (Slow 4G), a single Google datacenter. The CrUX block aggregates your real Chrome users over 28 days at P75 — varied devices, varied connections, varied locations. Trust the field: that's what Google uses for ranking.

Yes, partly. The Starter plan is free and gives access to 30 locations worldwide, filmstrip, waterfall and Core Web Vitals — with a limit of 300 tests per month. The Pro plan starts at around $18.75/month and unlocks the API, scheduled tests, advanced scripting, premium locations and queue priority. For a one-off audit, the free plan is enough. For continuous monitoring, the API is essential.

Paris (EU West) if your audience is French-speaking — it's the most representative. But above all, don't test from just one location: a site that loads in 1.2 s from Paris can show 4.8 s from Mumbai or São Paulo. If you serve international users or your CDN covers multiple zones, systematically test from 2-3 contrasting locations. It's the only way to validate that an edge is working as intended.

Yes, exactly the same engine. PSI runs Lighthouse 13 in a Google environment with a fixed mobile profile (emulated Moto G4, Slow 4G, CPU 4× throttled). You'll get results very close to lighthouse https://example.com run locally with the same settings — except for the network environment. PSI's major differentiator is the addition of the CrUX block above the Lighthouse score, which doesn't exist in the CLI.

An hour to read a basic waterfall and filmstrip, half a day to seriously leverage multi-run comparisons, scripting and the API. The learning curve is steeper than PSI (which you can use in 30 seconds), but it pays off quickly: a well-read waterfall saves hours of guesswork. The classic beginner mistake is drawing conclusions from a single run — always run at least 3 and take the median.

WebPageTest yes, via its scripting language (navigate, setCookie, setValue, clickAndWait, logData). You can navigate to the protected page and only record metrics on that page. PageSpeed Insights no: it only loads a public URL via GET, without any interaction. For authenticated pages, it's WPT or nothing — or failing that, a public copy of the page with the same assets, measured in PSI.

Yes, the PageSpeed Insights v5 API is free with a Google key. Quota: 25,000 requests per day and 400 per 100 seconds — more than enough to audit a catalog of several hundred URLs daily. This makes it the default option for large-scale monitoring, whereas the WebPageTest API (reserved for the Pro plan) is better suited to a subset of strategic pages.

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.