Google scores every website on three Core Web Vitals metrics, LCP, INP, and CLS, and most sites fail at least one. Here is how to test your website speed, why it fails, and the fixes that move the needle.
The speed test your website is probably failing (Core Web Vitals guide)
Pull out your phone and open your website. Count the seconds until you can actually read something. One, two, three.
If you made it past three seconds, you are already testing the patience of most visitors. Google's DoubleClick research found that 53% of mobile visits abandon a page that takes more than three seconds to load. Your design, your copy, your offer: none of it matters if the page never finishes loading.
And here is the part most business owners miss. Google does not just observe this behavior. It measures your site against it, with a formal speed test called Core Web Vitals that feeds directly into how you rank. Most websites are failing that test right now.
What Google actually measures
Core Web Vitals are Google's three official metrics for page experience. They are measured from real visitors (field data from the Chrome User Experience Report), not from a lab simulation, and they are scored at the 75th percentile of visits. A good score means the experience is good for most real users, not just on a fast office connection.
The three metrics:
Largest Contentful Paint (LCP): how fast the main content appears. Good is 2.5 seconds or less. This is the big one, and the one most sites fail.
Interaction to Next Paint (INP): how quickly the page responds when someone taps or clicks. Good is 200 milliseconds or less. INP replaced the older First Input Delay metric as a Core Web Vital in March 2024, which means Google now judges the responsiveness of the whole visit, not just the first tap.
Cumulative Layout Shift (CLS): how much the layout jumps around while loading. Good is a score of 0.1 or less. This is the metric behind buttons that shift just as you tap them and paragraphs that reflow mid-read.
Pass all three and Google counts your page as delivering a good page experience, which helps when your page competes against equally relevant results. Fail them and you fight with one hand tied: slower pages rank a little worse and convert a lot worse.
One honest caveat before we go further: page experience is a tie-breaker, not a shortcut to the top. When two pages answer a query equally well, the faster one wins. Speed alone will not outrank a better answer. That framing matters because it keeps the advice honest: fix speed to stop losing winnable rankings and conversions, not to magically leapfrog competitors with stronger content. Core Web Vitals sit inside Google's page experience signals, which is why they belong in any serious technical SEO work, not as a side project.
Field data, not lab data: why your site feels fast to you
Here is the question every site owner asks: "It loads instantly on my laptop, so why does Google say it is slow?"
Because Google does not grade your laptop. Core Web Vitals are scored from field data: real visits from real users, collected through the Chrome User Experience Report, at the 75th percentile. Your page passes only if the experience is good for three out of four actual visits. Your fast office connection and new MacBook represent almost nobody.
And the data just got wider. In December 2025, Apple shipped Safari 26.2 with support for measuring LCP and the Event Timing API behind INP, which means iPhone visits now contribute real-user performance data for the first time. In the US, Safari holds over half of mobile browsing. Sites that looked fine in Chrome-only data suddenly had a much bigger, much more mobile-heavy sample judging them, and many scores moved.
Most websites are failing the test
The HTTP Archive's 2025 Web Almanac, built on Google's own Chrome UX Report field data from July 2025, puts numbers on this. Only 48% of mobile sites and 56% of desktop sites pass all three Core Web Vitals. LCP is the metric most mobile sites fail: just 62% score "good." INP looks healthier at 77% passing, which mostly reflects the work the industry did after it became official in 2024.
So more than half of mobile websites fail Google's speed test. And mobile is the score that counts. Just over half of global web traffic now comes from phones (StatCounter, July 2026), and Google completed its move to mobile-first indexing in July 2024. Since then, a site that does not work on a mobile device is not indexed at all.
Websites did not get slower by accident. The median mobile homepage is now more than three times heavier than it was a decade ago (HTTP Archive data puts page-weight growth at 202.8% across the decade to July 2025). Bigger images, more scripts, more trackers, more plugins, autoplay video backgrounds: each one seemed harmless alone. Together they pushed the average site past the thresholds Google measures.
What failing costs, in real numbers
This is where speed stops being a technical nicety and becomes a revenue question. The research here is unusually consistent.
Google and Deloitte studied 37 brands across retail, travel, and luxury ("Milliseconds Make Millions," 2019). A 0.1-second improvement in mobile load time was associated with an 8.4% lift in retail conversion rate, a 10.1% lift in travel conversions, and a 9.2% lift in average order value. Tenths of a second, single-digit percent gains: that is how tight the margins are.
Portent's 2022 analysis of e-commerce sites found that pages loading in one second converted at 2.5 times the rate of pages loading in five seconds. Google's analysis with SOASTA found the probability of a mobile bounce rises 32% as load time goes from one second to three.
Then there is the cleanest proof available: an actual A/B test. Rakuten 24, the Japanese online retailer, optimized one high-traffic landing page for Core Web Vitals and ran it against the original for a month. The only difference between the two versions was the performance work. The optimized page delivered 53.37% more revenue per visitor, a 33.13% higher conversion rate, 15.20% higher average order value, and a 35.12% lower exit rate (published as a Google web.dev case study, 2022).
It is not an outlier. Farfetch measured a 1.3% conversion lift for every 100 milliseconds shaved off LCP. Vodafone reported 8% more sales after a 31% LCP improvement. Groupe Renault found a one-second LCP improvement cut bounce rates by up to 14 percentage points and lifted conversions 13%.
The honest caveat: most of these studies are correlational, and no single fix guarantees Rakuten's numbers on your site. But the direction is unanimous across every dataset: faster pages convert better, and the effect is measurable in money.
Speed compounds after the click, too. Once a visitor becomes a lead, response time takes over, which is why we wrote separately about why the first five minutes decide everything.
Why is my website so slow?
When our team audits a slow site, the culprits are almost always the same, in roughly this order:
Unoptimized images. The hero image is usually the LCP element, and it is usually several times larger than it needs to be. Modern formats (WebP, AVIF), correct sizing, and real compression fix most of this in an afternoon.
Too many third-party scripts. Analytics, chat widgets, heatmaps, ad pixels, social embeds: each one adds network requests and JavaScript execution. We regularly find sites running tracking tools nobody has looked at in a year.
No caching strategy or CDN. If every visitor's browser re-downloads everything from a single server, geography becomes latency. A content delivery network and sane cache headers are baseline infrastructure, not advanced work.
Render-blocking resources and font loading. CSS and JavaScript that must finish before anything appears, plus web fonts that swap late and shift the layout (that is a CLS problem wearing a typography costume).
Slow server response. If the server takes its time answering (Time to First Byte), every metric downstream suffers. No frontend optimization outruns a slow server.
None of these require a redesign. Most require someone who treats performance as engineering, not as a plugin to install.
How to test your website speed in 2 minutes
You do not need our team for the diagnosis. Two free Google tools tell you exactly where you stand:
1. PageSpeed Insights. Enter your URL and Google scores both mobile and desktop, using real field data where available plus lab diagnostics. Read the mobile score first: that is the one that decides your rankings. Anything under 90 deserves attention, and the Core Web Vitals section tells you which of the three metrics fails.
2. Search Console's Core Web Vitals report. If your site is verified in Search Console, this shows pass and fail rates across your real pages over time. Watch it after any site change: performance regressions almost always arrive silently with a new plugin, a new script, or a "quick" homepage update.
Run the test now, before you read further. The number you get is the starting point for everything below.
How to improve website speed: fixes in the order that moves the needle
Fix per metric, in the order most sites fail them. LCP first, then INP, then CLS.
Fix LCP first, because it fails most. Compress and properly size the hero image, preload it, and serve it in a modern format (WebP or AVIF). On most sites we audit, this single change moves LCP more than everything else combined. Then check the server: if Time to First Byte is slow, upgrade the hosting or move closer to your audience before optimizing anything else, because no frontend fix outruns a slow server. A CDN with proper cache headers cuts repeat-visit loads dramatically and shrinks the geography penalty for visitors far from your server.
Then fix INP. Put your scripts on a diet. Remove every third-party tool you cannot name a decision you made with last month: analytics, chat widgets, heatmaps, ad pixels, social embeds. Defer or delay what remains so it loads after the content, and break up long JavaScript tasks that block taps. Marketing teams add scripts; almost nobody removes them.
Then fix CLS. Give images and embeds explicit dimensions so the page does not reflow as they load. Load fonts with display: swap and match the fallback sizing. CLS fixes are usually small code changes with an outsized effect on how "broken" a site feels.
Platform notes, because the fix depends on what you built on. On WordPress, the usual stack is a caching plugin plus an image optimization plugin, but the real win is usually removing page-builder bloat and unused plugins, not adding more. On Shopify, the culprit is almost always the app count: audit installed apps ruthlessly and pick a lean theme. On Next.js or React, use next/image with proper sizing, dynamic imports for heavy components, and font optimization.
What does not fix it: installing a caching plugin on top of a bloated homepage and calling it done, or chasing a perfect lab score while the field data from real visitors still fails. Optimize for the 75th-percentile real user, not the test.
When to call a developer
There is a line where DIY stops working. If your LCP element is a video background baked into the theme, if INP failures come from the theme's own JavaScript bundle, or if the hosting itself is the bottleneck, no plugin fixes that: the site needs engineering, not settings. That is usually the point where a rebuild on a performance-first stack costs less than another year of patches.
Where to start this week
1. Measure today. Run PageSpeed Insights on your homepage and your three most-visited pages. Write down the mobile scores and which vital fails. You cannot fix what you do not measure, and you will be surprised.
2. Fix the hero image this week. It is the most common LCP element and the cheapest win. Proper sizing, a modern format, and preloading: this is hours of work, not a project.
3. Make speed a habit, not a project. Check the Search Console vitals report monthly. Every new plugin, embed, and homepage video is a chance to regress. The sites that pass are the ones whose teams notice.
Google turned speed into a test with a pass mark. Your visitors turned it into a verdict long before that. The businesses winning in 2026 are not the ones with the prettiest websites. They are the ones whose pages load before the visitor's patience runs out.
This is how we build at The ZEONN: every site our Vancouver team ships is engineered against Core Web Vitals from the first commit, because a beautiful site that loads in six seconds is a beautiful site nobody sees. If your score came back red, book a free website speed audit and let us look at what is slowing you down. If you are planning a new build, our website design services start from performance, not decoration.
Core Web Vitals FAQ
What are Core Web Vitals? Google's three official page-experience metrics: Largest Contentful Paint (how fast the main content appears), Interaction to Next Paint (how quickly the page responds to taps and clicks), and Cumulative Layout Shift (how much the layout jumps while loading).
What are the Core Web Vitals thresholds? LCP of 2.5 seconds or less, INP of 200 milliseconds or less, and CLS of 0.1 or less, all measured at the 75th percentile of real visits. A page must pass all three.
How do I test my website speed? Run your URL through PageSpeed Insights for Google's mobile and desktop scores with Core Web Vitals diagnostics, and check the Core Web Vitals report in Search Console for pass and fail rates across your real pages over time.
How fast should a website load? Aim for the main content visible within 2.5 seconds on mobile. Research consistently shows conversions fall and bounce probability rises steeply past the three-second mark.
Why is my website so slow? The usual suspects, in order: unoptimized images (especially the hero), too many third-party scripts, no caching or CDN, render-blocking CSS and JavaScript plus late-loading fonts, and slow server response.
Does website speed affect SEO rankings? Yes, as a tie-breaker. Google uses page experience signals including Core Web Vitals when ranking. Speed will not outrank stronger content, but among equally relevant pages the faster one wins.
How can I improve my Core Web Vitals scores? Fix LCP first (hero image compression, preloading, modern formats, faster server), then INP (remove or defer third-party scripts), then CLS (explicit image dimensions, font-display: swap).
What is the most common reason for a poor LCP? An unoptimized hero image: too large, wrong format, or not preloaded. It is the LCP element on most pages and usually the cheapest fix.
What is INP and why did it replace FID? Interaction to Next Paint measures responsiveness across the whole visit, from tap to screen update. It replaced First Input Delay as a Core Web Vital in March 2024 because FID only measured the first interaction.
Why is my site fast for me but slow for visitors? Core Web Vitals are scored from field data at the 75th percentile of real visits, not from your device. Your fast connection and new laptop represent almost nobody in your actual audience.
Sources
- Rakuten 24 Core Web Vitals A/B test, Google web.dev case study (2022): 53.37% revenue-per-visitor lift, 33.13% conversion lift , https://web.dev/case-studies/rakuten
- Core Web Vitals pass rates, thresholds, and INP timeline: HTTP Archive Web Almanac 2025 (CrUX field data, July 2025) , http://christopholivierconsulting.com/page-speed-statistics/
- Mobile device traffic share (StatCounter, July 2026) and page-weight growth (HTTP Archive) , https://sqmagazine.co.uk/web-design-statistics/
- Mobile-first indexing completion, July 5, 2024 , Search Engine Land , https://searchengineland.com/google-wont-index-sites-that-do-not-work-on-mobile-devices-after-july-5th-442851
- Farfetch, Vodafone, and Groupe Renault performance figures , https://hackernoon.com/understanding-core-web-vitals-the-vital-signs-of-your-website
- Google/Deloitte "Milliseconds Make Millions" (2019), Portent site-speed analysis (2022), Google/SOASTA bounce study, Google DoubleClick mobile abandonment research , figures documented at http://christopholivierconsulting.com/page-speed-statistics/
- Safari 26.2 (December 12, 2025) adds LCP and Event Timing API (INP) support; CLS not yet supported , DebugBear , https://www.debugbear.com/blog/firefox-safari-web-vitals
- Google's official Core Web Vitals documentation , https://web.dev/articles/vitals
