Is Lighthouse score a ranking factor?

No. The Lighthouse score is a synthetic lab metric. Core Web Vitals (the field-data version) is the ranking signal. A page can have a Lighthouse score of 95 and still fail Core Web Vitals in the field — and a page with a Lighthouse score of 60 can pass field metrics if the user-side variance happens to be favourable.

How long do I have to wait to see CRUX update after a fix?

CRUX uses a 28-day rolling window. You'll start seeing partial impact within 7–14 days as new sessions enter the window, and the full effect is visible after 28 days. If a fix isn't reflected in CRUX after 28 days, the fix probably didn't work in the field.

What if my page doesn't have enough traffic for CRUX data?

PageSpeed Insights will show 'No data available' for low-traffic URLs. In that case, use a representative high-traffic URL on the same template as a proxy. The CRUX origin-level metric (rolled up across all your URLs) is also available and useful for diagnosing site-wide issues.

Should I disable Google Tag Manager to fix INP?

Almost never. The fix is to audit which tags are firing on user input and defer or remove the heavy ones. Common offenders: full chat-widget initialization on input, A/B-testing scripts that re-render the page on click, analytics libraries that send synchronous beacons.

How do Canadian-hosted sites compare to US-hosted sites for Core Web Vitals?

For Canadian-traffic-heavy sites, hosting in Canada (or on a CDN with strong Toronto/Vancouver edge presence) reduces TTFB by 80–200ms vs US-East hosting. That alone can move LCP from 'needs improvement' to 'good' on edge-of-threshold pages.

Are Core Web Vitals weighted equally by Google?

Officially yes — to pass, you need to pass all three. In practice, LCP and INP have larger correlation with ranking outcomes than CLS in our 2026 audit data. CLS is still worth fixing (especially for mobile UX), but it's the lowest-priority of the three for ranking work.

How to Read a Core Web Vitals Report 2026: A Canadian Operator's Guide

The decision in one paragraph

Core Web Vitals are three metrics — LCP (Largest Contentful Paint), CLS (Cumulative Layout Shift), and INP (Interaction to Next Paint) — measured on real users via the Chrome User Experience Report (CRUX). Lab data (Lighthouse, PageSpeed Insights synthetic) is a useful diagnostic but not what Google actually uses for ranking. The 75th-percentile rule means a page passes only if 75% of real-user sessions hit the threshold. Read field data first, lab data second, and prioritize fixes by traffic-weighted impact, not by Lighthouse score.

What LCP, CLS, and INP actually measure

LCP — Largest Contentful Paint
Time from navigation start to when the largest above-the-fold visual element finishes rendering. Threshold: ≤2.5s = good, 2.5–4.0s = needs improvement, >4.0s = poor. Usually the hero image, hero video poster frame, or a hero text block.
CLS — Cumulative Layout Shift
Sum of unexpected layout shifts that happen during page life. Threshold: ≤0.1 = good, 0.1–0.25 = needs improvement, >0.25 = poor. Caused by images without dimensions, ads injected after load, fonts swapping, late-loading widgets.
INP — Interaction to Next Paint
Replaced FID in March 2024. Measures the worst latency between a user input (tap, click, keystroke) and the next visual update. Threshold: ≤200ms = good, 200–500ms = needs improvement, >500ms = poor. Almost always a JavaScript-execution problem.

Three numbers, one ranking signal. INP is where most Canadian ecommerce sites fail in 2026, and it's the hardest of the three to fix because it requires JavaScript discipline most CMSs don't enforce.

— Martin Vassilev, founder, Toronto SEO

Field data vs lab data: why they disagree

PageSpeed Insights shows two columns side by side: 'Discover what your real users are experiencing' (field data, from CRUX) and 'Diagnose performance issues' (lab data, from a synthetic Lighthouse run). They almost never agree, and operators routinely chase the wrong one.

Field data is what Google uses for ranking. It's measured on real Chrome users over a rolling 28-day window. It captures the variance of real devices, real networks, and real user behaviour. It's slow to react to fixes (you'll wait 14–28 days to see your changes reflected) and can only be measured on pages with enough traffic to qualify.

Lab data is what Lighthouse measures in a controlled environment. It's instant — you change the code, you re-run, you see the new number. It's useful for debugging individual fixes. It's not what Google ranks on.

The mistake is using lab data to declare 'we passed Core Web Vitals' when CRUX still shows red bars for real users. The fix has happened in the lab; the field hasn't caught up yet, or the fix doesn't survive real-world conditions.

The 75th-percentile rule and what it means

Google evaluates Core Web Vitals at the 75th percentile of real-user sessions. To pass LCP, 75% of your sessions need to hit ≤2.5s. The 25% slowest sessions can be much slower — the page still passes.

This matters for prioritization. If your median LCP is 1.8s but your 75th percentile is 4.1s, you have a tail problem, not a typical-user problem. Fixing the median doesn't help; fixing the slow 25% does.

Common tail-distribution culprits: third-party scripts that occasionally hang, slow international CDN edges (matters for Canadian sites with US-based hosting and US-edge CDN), heavy ad networks that load slowly under contention, video elements that block rendering on mobile.

How to diagnose each metric when it fails

LCP failing — start here
Identify the LCP element (Lighthouse marks it). Common fixes: serve hero image as preloaded AVIF/WebP, drop hero video for lower-bandwidth users, eliminate render-blocking CSS in <head>, use rel=preload for critical fonts, host fonts on your own domain instead of Google Fonts.
CLS failing — start here
Open Chrome DevTools → Performance → Web Vitals lane to see which element shifted. Most common: images without explicit width/height attributes, ads injected after first render, fonts loading with FOIT/FOUT, third-party widgets (chat, review carousels) appearing late.
INP failing — start here
Most expensive to fix. Common causes: large JavaScript bundles loading on interaction, third-party tags executing on every input, React re-renders triggered by state changes that don't need them. Tools: Web Vitals Chrome extension, Long Animation Frames API, INP debugger in DevTools.

Prioritizing fixes by business impact

Not every red Core Web Vitals bar is worth fixing immediately. Prioritize by traffic share × revenue impact:

URL pattern	Failing metric	Traffic share	Action priority
Homepage	LCP red	High	Immediate
Top 10 commercial-intent landing pages	LCP or INP red	High per-URL	Within 30 days
Blog category pages	CLS red	Medium	Within 60 days
Long-tail blog articles	CLS red	Low per-URL, high in aggregate	Group fix in next sprint
Internal admin / login pages	Any	N/A (noindex)	Don't bother
Checkout funnel	INP red	Direct revenue impact	Immediate, even if traffic is low