자주 묻는 질문

네, 공식적으로 2021년부터입니다. 하지만 독립적인 레버가 아닌 타이브레이커 요소로 작동합니다. 훌륭한 콘텐츠를 가진 페이지는 CWV가 좋지 않아도 충분히 높은 순위를 차지할 수 있습니다 — 하지만 경쟁이 치열한 검색어에서는 CWV가 3위와 1위의 차이를 만들 수 있습니다.

Web Vitals는 Google이 정의한 모든 웹 성능 지표(TTFB, FCP, LCP, INP, CLS 등)를 통칭합니다. Core Web Vitals는 검색 순위 신호로 공식 채택된 세 가지 지표인 LCP, INP, CLS를 말합니다. 이것이 바로 "핵심" Web Vitals입니다.

PageSpeed Insights는 실험실 데이터 (시뮬레이션)와 가능한 경우 현장 데이터를 표시합니다. Search Console은 28일간의 실제 현장 데이터(CrUX)만 사용합니다. 실험실 점수 90/100이 좋은 현장 데이터를 보장하지는 않습니다 — 실제 환경(저사양 모바일 기기, 느린 4G 연결)은 종종 훨씬 불리한 경우가 많습니다.

Search Console은 28일 롤링 기간의 데이터를 집계합니다. 최적화 후, 보고서에 개선 사항이 완전히 반영되기까지 4~6주를 예상하세요. 실제 사용자 데이터는 갱신되는 데 시간이 걸립니다.

네. Google은 Search Console에서 모바일과 데스크톱에 대해 CWV를 별도로 평가합니다. 대부분의 이커머스 사이트에서 모바일이 더 문제가 많으며, 모바일 우선 인덱싱(mobile-first indexing)으로 전환된 이후 순위에 가장 큰 영향을 미치는 것은 모바일 버전입니다.

LCP는 일반적으로 가장 먼저 수정해야 할 항목입니다 — 상품 이미지와 슬라이더는 느린 LCP의 주요 원인입니다. INP는 서드파티 스크립트의 밀도로 인해 Shopify나 WooCommerce 같은 플랫폼에서 개선하기가 가장 어려운 경우가 많습니다. CLS는 이미지 크기를 지정하고 팝업을 제어하면 가장 빠르게 수정할 수 있는 경우가 많습니다.

네, 이는 문서화된 사실입니다. Google은 LCP > 4초일 경우 이탈률이 3배 증가한다고 측정했습니다. 업계 연구에 따르면 로딩 시간을 100ms 개선하면 이커머스 사이트의 전환율이 1~3% 향상될 수 있습니다. CWV 최적화는 단순한 SEO 과제가 아니라 직접적인 비즈니스 과제입니다.

가장 간단한 방법은 PageSpeed Insights, Search Console, Chrome DevTools, WebPageTest를 결합한 웹 성능 감사로, 여러분의 스택에서 우선순위 개선 항목을 정확히 파악할 수 있습니다. 현장 진단 없이는 감으로 최적화하는 것과 다름없습니다.

네, 완전히 정상입니다. Lighthouse는 시뮬레이션된 조건에서 측정합니다. 에뮬레이션된 Moto G4 기기, CPU 4배 느림, Slow 4G 네트워크. Search Console은 실제 기기와 연결 환경에서 실제 방문자를 반영합니다. 사용자층이 최신 기기와 빠른 연결을 사용한다면 그 차이는 상당할 수 있습니다. 실제로 CrUX field LCP가 1.7s인 사이트의 lab LCP가 14.6s로 측정된 사례가 있습니다. SEO와 전환율 관점에서 중요한 것은 field 데이터입니다.

PageSpeed Insights는 두 가지 출처를 통합합니다. 실시간으로 실행되는 Lighthouse 보고서(lab data)와 Chrome UX Report에서 가져온 CrUX field data입니다. Lighthouse 단독으로는 lab data만 보여줍니다. PSI는 lab 점수를 실제 사용자 경험과 비교할 수 있어 더 완전한 정보를 제공합니다. 인증이 필요한 페이지나 CI/CD에서 테스트를 자동화하는 경우에는 Lighthouse CLI가 더 적합합니다.

아니오, 직접적으로는 아닙니다. 복합 점수(0–100)는 랭킹 신호가 아닙니다. SEO에 중요한 것은 CrUX를 통해 Google이 측정하는 field Core Web Vitals(LCP, INP, CLS)입니다. field CWV가 초록색인 Lighthouse 점수 40점이, field CWV가 빨간색인 Lighthouse 점수 90점보다 SEO 관점에서 더 중요합니다. Lighthouse는 진단에 활용하고, 의사결정은 field 데이터를 기반으로 하십시오.

모바일 프로필은 CPU를 4배 느리게 에뮬레이션하고 Slow 4G 연결(1.6 Mbps)을 사용합니다. 데스크톱 프로필은 의미 있는 네트워크 throttling 없이 실제 머신을 사용합니다. JavaScript가 무겁거나 이미지가 최적화되지 않은 페이지에서는 40점 이상 차이가 날 수 있습니다. 이는 의도적인 설계입니다. 모바일 프로필은 실제 사용자 조건이 아니라 전 세계 하위 기기 스펙트럼 조건을 나타내도록 보정되어 있습니다.

LCP(25%)와 TBT(30%)만으로 점수의 55%를 차지합니다. 이 두 지표부터 공략해야 합니다. LCP에 대해서는 해당 이미지 자체를 겨냥하십시오. AVIF 또는 WebP 형식, fetchpriority="high", 리소스 preload, 앞을 막는 스크립트 없음. TBT에 대해서는 code splitting, 비필수 서드파티에 대한 defer, 그리고 첫 렌더링에 기여하지 않는 스크립트의 완전 제거를 통해 블로킹 JavaScript를 줄이십시오. CLS(25%)가 다음 순서이며 수정은 흔히 빠르게 완료됩니다. 모든 이미지에 width/height 선언, 미디어 컨테이너에 aspect-ratio, 웹 폰트에 font-display: swap을 적용하십시오.

프론트엔드에 중요한 변경이 있을 때마다(새 컴포넌트, 프레임워크 업데이트, 서드파티 스크립트 추가) 실행하십시오. 배포 외에는 트래픽이 적당한 사이트의 경우 월 1회면 충분합니다. 중요한 사이트의 경우 CI/CD 파이프라인에서 Lighthouse CI를 통한 자동화된 모니터링이 수동 확인보다 신뢰성이 높습니다. 성능 저하가 발생하는 시점에 즉시 감지할 수 있기 때문입니다.

Chrome에서 30초면 됩니다. F12, Lighthouse 탭, 분석 버튼을 클릭하면 됩니다. 신뢰할 수 있고 재현 가능한 감사를 위해서는 시크릿 창을 사용하고, 확장 프로그램을 비활성화하고, 중앙값을 구하기 위해 3회 연속 실행하십시오. 진지한 첫 감사를 위해서는 결과 해석을 포함하여 5–10분을 예상하십시오. 어려운 부분은 감사를 실행하는 것이 아니라, 결과를 맥락에서 벗어나지 않게 올바르게 해석하는 것입니다.

간접적으로 영향을 미칩니다. TTFB는 직접적인 순위 신호는 아니지만 LCP에 영향을 미치며, LCP는 2021년부터 Page Experience Signal에 포함된 Core Web Vital입니다. TTFB가 높으면 LCP 요소의 렌더링이 지연되어 field data 점수가 저하됩니다. 콘텐츠와 백링크가 동등하다면, TTFB가 낮은 사이트가 경쟁적인 검색어에서 우위를 점합니다.

TTFB는 HTTP 응답의 첫 번째 바이트까지의 지연을 측정합니다. 이는 순수한 서버 성능이며, 브라우저가 파싱을 시작하기도 전의 시간입니다. LCP는 가장 큰 가시적 요소가 viewport에 도달하는 순간을 측정하며, 이는 사용자 측 지표입니다. LCP는 네 단계로 구성되며 TTFB가 그 첫 번째입니다. TTFB가 800ms라면 브라우저가 어떤 처리도 하기 전에 LCP 예산의 800ms를 소비한 것입니다. LCP 목표가 2.5s라면 나머지 모든 작업에 남는 시간은 1.7s뿐입니다.

WebPageTest는 결정론적 환경에서 단일 위치를 시뮬레이션합니다. Search Console은 모든 위치와 모든 네트워크를 아우르는 28일치 실제 데이터를 P75로 집계합니다. 이 차이는 흔히 잘못 설정된 CDN(일부 지역에 edge caching 미적용)이나 실제 트래픽 부하 하에서 성능이 저하되는 TTFB를 나타냅니다. 의사결정에는 field data를 신뢰하십시오.

Search Console은 28일 이동 기간을 사용합니다. 수정 후 Core Web Vitals 보고서에 개선이 반영되기까지 4~6주를 예상하십시오. CrUX 데이터는 월별로 업데이트됩니다. RUM(Real User Monitoring) 도구를 사용하는 경우 몇 시간 내에 효과를 확인할 수 있습니다.

가능하지만, 서버와 지리적으로 가까운 사용자에게만 해당됩니다. 잘 설정된 서버 페이지 cache는 같은 지역에서 20-50ms까지 낮출 수 있습니다. 다른 지역(서버는 프랑스, 사용자는 싱가포르)에서는 네트워크 지연만으로 150-200ms가 불가피하게 추가됩니다. CDN만이 전 세계적으로 낮은 TTFB를 달성하는 유일한 방법입니다.

고유한 파라미터 조합(필터, 정렬, 색상)마다 별도의 cache key가 생성될 수 있습니다. 각각 5개의 값을 가진 필터가 20개 있는 카탈로그에서는 수천 개의 cache 항목이 발생하며 대부분은 워밍업되지 않습니다. 대부분의 요청이 cache miss가 되어 애플리케이션 서버에 도달하며, cache가 존재함에도 그 효과가 무효화됩니다.

Google이 정한 "양호" 기준은 field data 기준 P75에서 800ms 미만입니다. 이는 최소 기준일 뿐 목표가 아닙니다. 제가 함께 일하는 프랑스의 최고 e-commerce 사이트들은 P75에서 400ms 미만을 목표로 하며, 올바르게 설정된 edge CDN과 origin의 full-page cache 덕분에 유럽 방문자 기준으로는 80~200ms를 달성합니다. 벤치마킹을 위해서는 파리에서 모바일 프로파일(Moto G4, 4G)로 WebPageTest를 실행하십시오. 이는 경쟁사와 동일한 조건에서 성능을 비교할 수 있는 기준입니다.

네. 2021년부터 CWV는 Google이 랭킹에 사용하는 "Page Experience" 신호의 일부입니다. 매우 경쟁이 치열한 검색어(예: "남성 러닝화")에서 콘텐츠가 동등하다면, 좋은 CWV를 가진 사이트가 우위를 차지합니다. 영향은 중간 정도이지만 실재하며, 전환율에 미치는 직접적인 영향과 합쳐집니다.

FID는 첫 번째 상호작용까지의 지연만 측정했습니다. INP는 세션 전반에 걸친 모든 상호작용의 지연 시간(클릭, 탭, 키보드 입력)을 측정합니다. 사용자가 필터를 클릭하고, 장바구니에 상품을 담고, 메뉴를 여는 이커머스 사이트의 실제 경험을 INP가 훨씬 더 잘 대표합니다. FID는 2024년 3월에 CWV에서 제외되었습니다.

Lighthouse는 시뮬레이션된 연결에서 서드파티 스크립트, 쿠키, 사용자 상태 없이 실행되는 실험실 테스트입니다. Field CWV는 실제 사용자, 실제 모바일 연결, Chrome 확장 프로그램, 활성화된 마케팅 스크립트와 함께 측정됩니다. 격차는 엄청날 수 있습니다. Field 데이터(Search Console, CrUX)를 신뢰하세요.

Google은 Search Console의 CWV 데이터를 28일 롤링 윈도우의 지연으로 업데이트합니다. 수정 후 보고서에 개선이 반영되기까지 4-6주를 예상하세요. CrUX 데이터는 월간 업데이트됩니다.

네, 그러나 제약이 있습니다. TTFB와 인프라는 Shopify가 관리합니다 - 서버를 건드릴 수 없습니다. 반면 테마(이미지, 폰트, CSS, JS), 설치된 앱(각 앱은 JS를 추가합니다), Liquid 코드는 제어할 수 있습니다. 가장 큰 이득은 종종 불필요한 앱 제거와 이미지 최적화에서 나옵니다.

LCP가 첫 번째입니다. 페이지 도착 시점부터 속도 인지를 결정하기 때문입니다. INP가 두 번째인데, 구매 경험(필터, 장바구니, checkout)에 직접 영향을 미칩니다. CLS가 세 번째입니다 - 높은 CLS는 잘못된 클릭과 사용자 좌절을 유발하지만, 전환에 대한 영향은 더 간접적입니다.

먼저 PageSpeed Insights입니다. Google의 Page Experience 시그널은 CrUX field data에 의존하며, PSI가 Lighthouse score 위에 표시하는 것이 바로 이것입니다 — 28일 rolling window에서 75th percentile로. WebPageTest는 이 데이터에 접근할 수 없습니다. 그러나 LCP가 왜 나쁜지 이해해야 할 때는 WPT가 waterfall과 filmstrip으로 역할을 맡습니다. 실용적인 규칙: Google이 보는 것을 측정하려면 PSI, 무엇을 수정해야 하는지 이해하려면 WPT입니다.

같은 리포트 안의 서로 다른 두 측정값이기 때문입니다. 0-100 score는 lab data에서의 Lighthouse: 단일 run, 단일 기기 (emulated Moto G4), 단일 네트워크 (Slow 4G), 단일 Google datacenter. CrUX block은 28일 동안 P75에서 실제 Chrome 사용자를 집계합니다 — 다양한 기기, 다양한 연결, 다양한 위치. field data를 신뢰하세요: Google이 ranking에 사용하는 것이 바로 그것입니다.

부분적으로는 무료입니다. Starter plan은 무료이며 전 세계 30개 위치, filmstrip, waterfall, Core Web Vitals에 접근할 수 있습니다 — 월 300 테스트 한도로. Pro plan은 약 $18.75/월부터 시작하며 API, 예약 테스트, 고급 scripting, premium 위치, queue 우선순위를 해제합니다. 일회성 audit의 경우 무료 plan으로 충분합니다. 지속적인 모니터링의 경우 API는 필수입니다.

오디언스가 프랑스어권이라면 Paris (EU West)가 가장 대표적입니다. 하지만 무엇보다 단일 위치에서만 테스트하지 마세요: Paris에서 1.2 초에 로드되는 사이트가 Mumbai나 São Paulo에서 4.8 초를 기록할 수 있습니다. 해외 사용자에게 서비스하거나 CDN이 여러 영역을 커버한다면 대조적인 2-3개 위치에서 체계적으로 테스트하세요. edge가 의도대로 작동하는지 검증하는 유일한 방법입니다.

네, 정확히 같은 엔진입니다. PSI는 고정된 mobile profile (emulated Moto G4, Slow 4G, CPU 4× throttled)로 Google 환경에서 Lighthouse 13을 실행합니다. 같은 설정으로 로컬에서 실행한 lighthouse https://example.com과 매우 유사한 결과를 얻을 수 있습니다 — 네트워크 환경을 제외하고. PSI의 주요 차별점은 CLI에는 없는 Lighthouse score 위의 CrUX block 추가입니다.

기본적인 waterfall과 filmstrip 읽기는 1시간, multi-run 비교·scripting·API를 진지하게 활용하려면 반나절. 학습 곡선은 PSI (30초에 사용 가능)보다 가파르지만 빠르게 보답합니다: waterfall을 잘 읽으면 추측으로 보내는 수 시간을 절약합니다. 초보자의 전형적인 실수는 단일 run에서 결론을 도출하는 것입니다 — 항상 최소 3번 실행하고 중앙값을 취하세요.

WebPageTest는 가능합니다. scripting 언어(navigate, setCookie, setValue, clickAndWait, logData)를 통해 보호된 페이지로 이동하고 해당 페이지에서만 지표를 기록할 수 있습니다. PageSpeed Insights는 불가능합니다: interaction 없이 GET으로 공개 URL만 로드합니다. 인증된 페이지의 경우 WPT가 유일한 선택입니다 — 아니면 PSI에서 측정하기 위해 동일한 assets를 가진 페이지의 공개 사본을 사용하세요.

네, PageSpeed Insights v5 API는 Google 키와 함께 무료로 사용할 수 있습니다. 할당량: 하루 25,000 요청 및 100초당 400건 — 매일 수백 개 URL의 카탈로그를 audit하기에 충분합니다. 이것이 대규모 모니터링의 기본 옵션인 반면, WebPageTest API (Pro plan에서만 사용 가능)는 전략적 페이지의 하위 집합에 더 적합합니다.

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.