Why Core Web Vitals matter for SEO
Google uses Core Web Vitals as a direct ranking signal. Pages with poor LCP, INP, or CLS rank lower on identical content. Faster pages also convert 2-3x better on average — every 100ms of LCP improvement lifts conversion rate by ~1%.
The three Core Web Vitals explained
- LCP (Largest Contentful Paint) — how fast the biggest visible element loads. Target: under 2.5s. Hero images, video posters, and large headlines usually trigger LCP.
- INP (Interaction to Next Paint) — how responsive the page feels to clicks and taps. Target: under 200ms. Replaced FID in March 2024.
- CLS (Cumulative Layout Shift) — how much the page jumps around as it loads. Target: under 0.1. Ads, fonts without size-adjust, and lazy-loaded images are common culprits.
How to improve your scores
- Compress and serve images as WebP/AVIF. 50-70% size reduction with no visible quality loss.
- Lazy load images below the fold. Use
loading="lazy"on non-hero images. - Defer or async non-critical JavaScript. Especially analytics, chat widgets, third-party embeds.
- Pre-load critical fonts and hero assets.
<link rel="preload">for above-the-fold needs. - Use a CDN. Cloudflare or BunnyCDN cut latency 40-70% globally.
- Reserve space for ads and embeds. Set explicit width/height to prevent CLS.
- Enable caching headers. Static assets should have year-long Cache-Control.
Field data vs lab data — why PSI shows two scores
PageSpeed Insights returns two parallel datasets. Lab data is a fresh Lighthouse run in a clean Chrome instance — reproducible, but a single snapshot. Field data (also called CrUX data) is the real Core Web Vitals collected from actual Chrome users over the past 28 days — what Google actually uses for ranking.
If your lab score is 90 but field data is 60, real users are hitting slower conditions than the test environment. The fix lives in real-world variables: slow networks, older Android devices, third-party scripts that load conditionally. Google’s official lab vs field guide explains the methodology.
Mobile vs desktop — why they differ
PSI runs mobile tests on a simulated mid-tier Moto G Power on a slow 4G connection (1.6 Mbps down, 750 Kbps up, 150ms RTT). Desktop tests use a faster connection (10 Mbps) and stronger CPU. The same site can score 95 on desktop and 45 on mobile.
Google uses mobile-first indexing — meaning the mobile score is what affects rankings. Always optimise for mobile first. Web.dev’s Core Web Vitals reference covers the official mobile thresholds.
PSI vs GTmetrix vs WebPageTest — which one matters?
Each tool runs Lighthouse-based audits but uses different defaults. Here’s how they compare:
| Tool | Best for | Limitation | Cost |
|---|---|---|---|
| PageSpeed Insights | Ranking signal — what Google uses | Single Lighthouse run, no historical tracking | Free |
| GTmetrix | Historical tracking, video playback of load | Only mobile testing on paid plans | Free + paid |
| WebPageTest | Multi-location, multi-browser, filmstrip detail | Steeper learning curve, complex UI | Free + paid |
| Lighthouse CI | Automated regression testing in CI/CD | Engineering setup required | Free (open source) |
Our take: use PSI for ranking decisions, GTmetrix for historical tracking, WebPageTest for deep debugging. They all share Lighthouse’s core engine, so scores correlate strongly.
Common speed killers we see in audits
After auditing 200+ sites, these are the top 5 culprits that crater Core Web Vitals:
- Massive unoptimised hero images — A 3MB hero PNG single-handedly destroys LCP. Compress to WebP (often 200-400KB) and serve responsive sizes.
- Render-blocking third-party scripts — Heavy chat widgets (Intercom, Drift), analytics suites, and A/B testing tools loading in <head>. Defer them or load on interaction.
- Web fonts without size-adjust — Custom fonts swap in late and shift everything around. Use
font-display: swapwithsize-adjustCSS to match the system fallback. - Lazy-loaded above-the-fold images — Ironically, lazy-loading the LCP image makes LCP worse. Hero images should load eagerly with
fetchpriority="high". - Ads and embeds without reserved space — Twitter embeds, YouTube iframes, AdSense slots all push content down as they load, killing CLS. Always set explicit width and height.
If your audit revealed any of these, our WordPress Development service includes a guaranteed Core Web Vitals fix-pass within 30 days — or we keep working until we hit it.
How often should you test?
Run a fresh test in three situations: after any major deployment, weekly for ongoing monitoring, and before/after any third-party integration. Field data (CrUX) updates monthly, so don’t expect to see improvements in Google’s ranking signal until 28-day rolling window catches up.
For competitive industries, monitor your top 3 organic competitors monthly too. If they ship a speed improvement and you don’t, your ranking gap widens. Chrome User Experience Report is the data source Google uses internally — you can query it via BigQuery for free.
The real ROI of a 1-second speed improvement
Speed isn’t just a ranking signal — it’s a conversion lever. Real data from Google’s case study library shows what every 100ms of LCP improvement is worth across industries:
- E-commerce: +1.1% conversion rate per 100ms LCP improvement. On a €500K/yr store, that’s €5,500 extra revenue per 100ms cut.
- Lead generation: +3.0% form submissions per 100ms. Sites that drop from 4s to 2s LCP typically see 40-60% more leads.
- SaaS: +2.4% trial signups per 100ms. Especially important for free-trial funnels where users tab away if loading exceeds 3s.
- Content / media: +1.7% pages-per-session and +8% bounce rate reduction. Critical for ad revenue.
Compounded over time, a Core Web Vitals upgrade typically pays for itself within 60-90 days through conversion lift alone — before counting the SEO traffic gain.
SEO timeline — when do improvements show up in rankings?
After you ship a fix, the timeline looks roughly like this:
- Day 1 — Lab data updates instantly. Run a fresh PSI test, see the new score reflected in lab metrics.
- Days 7-14 — Field data starts shifting. Chrome users on your site report new Real User Metrics into the CrUX dataset.
- Days 28-30 — Field data fully refreshes. The 28-day rolling window for CrUX completes, giving Google the new average.
- Weeks 4-8 — Crawl + reindex. Googlebot recrawls pages with new field data, updates ranking signals.
- Weeks 8-12 — SERP movement visible. Position changes show in Search Console. Sites moving from "Poor" to "Good" CWV typically see 5-15% organic traffic lift.
Don’t panic if rankings don’t move in the first month. Google is patient, but consistent. The compounding effect is what matters — sites with green CWV across thousands of pages see exponentially better long-term ranking stability than sites with flaky scores.
What this tool is — and what it isn’t
This Speed Checker is a wrapper around the official Google PageSpeed Insights API. We don’t collect your data, we don’t store URLs beyond a 30-minute cache, and we never run any audits server-side without your explicit click. The metrics you see are the same metrics Google uses internally for its Page Experience ranking system.
What this tool doesn’t do: it doesn’t simulate real users at scale, it doesn’t track scores over time, and it can’t test pages behind authentication. For those, you need real user monitoring (RUM) tools like Cloudflare Web Analytics, SpeedCurve, or Calibre. For pages behind a login, run Lighthouse locally via Chrome DevTools.
