# Spoiler: passing Core Web Vitals isn't fast - so how fast is fast enough for your site?

It’s 2026 and we are still talking about optimizing web performance. You might think, haven’t we solved this by now, is every site not fast by default? And the answer to that: no definitely not. And passing Core Web Vitals? Just means you did not frustrate most of your users.

Depending on your industry, your traffic sources, and your business goals, "not frustrating" your users is probably still costing you a massive amount of visibility and revenue.

But how fast is fast enough for your business? Or site? It depends on who you ask. So, as a piece of research to fall back on, let’s take a look at factors that might help you to determine how fast is fast enough for your site.

## 1. The baseline for public services: the faster the better

A lot of the factors I’m going to name are commercial or business driven. But there are actually use cases where performance is not just nice to have, but important, maybe even lifesaving.

Think for instance in emergencies: you are in a place with bad internet, or internet is almost down due to a lot of traffic (this can definitely happen in a national emergency situation). It can also be because your monthly package is finished. Or you are abroad. If it is vital information you need, like phone numbers, advice sites or reading the national or regional news, you don’t need it to be pretty. You need it to load as quickly as it can. Lightweight, HTML first, no heavy JS libraries.

This goes beyond absolute emergencies and into an accessibility point of view as well, as this quote shows us. They need sites to work for everyone.

> A few years ago I was doing policy research in a housing benefits office in London. In the middle of a tense, crowded room, a young woman sat clutching an old PlayStation Portable (PSP) games console. She stared at it intensely. I assumed she was playing a game to block out the stressful environment.
> 
> When I walked behind her, I recognized the screen. She was connected to the free Wi-Fi and browsing the GOV.UK pages on housing benefits.
> 
> The web browser on an old PSP is pathetically slow and frequently runs out of memory. But because the government pages were written in simple, lightweight HTML, they loaded. They were designed to work on absolutely any browser. They had to be. This is for everyone.

So, the answer to the question is my site fast enough if I pass Core Web Vitals for a public site: probably not. You need data from all your users and at least have P98 (98 out of 100 people) to be as fast as Core Web Vitals, not just 75 out of 100 as Core Web Vitals reports.

## 2. The baseline for e-commerce: every 100ms is a conversion loss

If you are running a webshop, passing Core Web Vitals is a great technical milestone, but it does not mean you have maxed out your conversion potential. There is a lot of research on this subject, in fact one of the famous case studies is called "Milliseconds make Millions".[ We have them all summed up in this guide. ](https://www.rumvision.com/md/blog/benefits-of-optimizing-core-web-vitals/)

### Research in 2026 shows: Core Web Vitals tresholds are leaving a lot of money on the table

[A recent (april 2026) report from Shopify](http://www.shopify.com/enterprise/blog/store-speed-conversion) analyzing millions of e-commerce stores shows just how tight the link still is between speed and revenue:

- **Every 100ms delay** can result in up to a 3.5% drop in conversions.
- **Load times between 1.5 and 2.5 seconds** (which is still considered "Good" or "Passing" by Google) already show a clear 30% conversion loss compared to sub-second sites.
- **Responsiveness matters just as much:** every 32ms delay in interaction response (INP) can cause a 1.5% drop in conversions.
 
One honest note: Shopify is clear this is a correlation, not proof that speed alone drives the sales - there are always other factors like pricing and product-market fit. But they grouped stores into performance tiers and controlled for the other metrics to isolate the speed signal, and the pattern still held. That’s what makes it worth paying attention to.

### Performance bottlenecks change depending on the size and maturity of your store

The relationship between speed and sales is also very interesting when you look at how a business evolves.

- **Early-stage shops** are highly sensitive to performance. When you are just starting out, your main hurdles are building brand awareness and earning a visitor's trust. Starting with a fast, optimized baseline gives you an immediate competitive edge without needing a massive budget or a dedicated engineering team. Think: Shopify, Hyvä, solutions who are fast by default.
- **Mid-size, growing brands** hit a different bottleneck. As a business expands, it is natural to start layering on third-party tools, tracking pixels, and custom integrations/ apps. This is the stage where performance often takes a hit from cumulative bloat. Because you are growing rapidly, reclaiming that lost speed is one of the most effective ways to instantly boost your conversion rates. By gaining RUM insights into the third party impact of your site, you can optimize a lot here.
- **Enterprise and mature stores** experience a smaller percentage shift in user behavior. When you have strong brand loyalty and high intent to buy, customers are more willing to tolerate a slight delay. However, the sheer volume of orders changes the financial equation entirely. When you process millions in revenue, a tiny fractional improvement in your conversion curve translates into massive absolute gains. This is where fine-tuning performance yields the absolute highest financial return.
 
For a mid-size or large e-commerce store, a site that sits comfortably at a 2.4-second Largest Contentful Paint (LCP) technically "passes" Google's Core Web Vitals. **But from a pure numbers game, that store is leaving an incredible amount of money on the table by not pushing closer to 1 second.**

## 3. The baseline for publishers: getting articles read and ads seen

For a publisher it comes down to two things: people need speed to read your articles, and they need to see your ads. Passing Core Web Vitals is a great start for your SEO, but it doesn’t guarantee either one of your main goals.

### Speed gets your articles read

The *Financial Times* showed this in a [famous experiment](https://medium.com/ft-product-technology/a-faster-ft-com-10e7c077dc1c) where they deliberately slowed the site down for some of their subscribers:

- A **1-second delay** caused a **4.9% drop** in articles read over the first seven days.
- A **3-second delay** pushed that to about **7.2%**, and it kept getting worse the longer people stayed in the test.
 
Fewer articles read means fewer ad slots served. And speed also decides whether the ads you do serve are ever seen. People land, skim the first paragraph, and scroll. If your ads take 2 or 3 seconds to load, that slot is still a blank white box by the time the reader has gone past it. In ad tech we call that a "ghost impression": the ad loaded, but no human saw it. Advertisers only pay for ads that hit a 50% viewability threshold, so a slow layout is ad space you give away for free.

### Core Web Vitals can’t see your revenue

LCP just finds the biggest text or image block early on - usually your headline - and calls the page "loaded." It has no idea whether the things that actually make you money kept pace with someone scrolling down the page.

That’s where RUM comes in. Instead of letting the browser decide what counts, you pick the elements that matter and measure when they really showed up for real users: the moment an ad container finished rendering, when your liveblog or stats iframe appeared, when a key template stopped lagging. It also ties a layout shift back to the exact element that caused it, usually an ad, which is one of the most annoying things you can do to a reader.

So for a publisher, passing Core Web Vitals isn’t fast enough. You need your articles loading quickly enough that people keep reading, and your ads rendering before they scroll past - and the only way to know you’ve got both is to measure the elements that carry your revenue, not the single block the browser happened to pick. Core Web Vitals won’t show you that. RUM will.

## 4. What the marketing & search ecosystem says about speed

If you ask the different platforms driving traffic to your site how fast you need to be, you will get a different answer from every single one. Passing your baseline Core Web Vitals might make one channel happy while hurting another:

### **SEO**

Passing Core Web Vitals at the 75th percentile hits Google's ranking signal. This is the one group that would be alright to have passing Core Web Vitals as endgoal and not look beyond. Interesting enough, we often see Technical SEO actually pushing beyond looking at Core Web Vitals, probably because they know about the UX gains and one never knows what Googles algorithm actually promotes..

### **PPC / paid ads**

If people don't bounce before your tracking scripts load. If you are paying for traffic via Google Ads or social campaigns, a "passing" 2.5-second load time on a mobile device means users are bouncing before your Meta Pixel or Google tag even fires. You are literally paying for clicks that never show up in your analytics. Worse yet, never convert.

### **AI Search, Agentic shopping and LLM bots**

[Keep it crawlable, lightweight, and stable.](https://web.dev/articles/ai-agent-site-ux#build_agent-friendly_websites_2) Agentic workflows and AI search engines rely on scraping and parsing your site quickly. If your pages take too long to render or have layout instability, AI bots hit timeout limits or can't take clear screenshots and will simply skip indexing your content or using your check-out.

## 5. The baseline for human psychology: In the blink of an eye

From a scientific point of view, the answer is this: cognitive psychology and UX research (best summarized by Jakob Nielsen) reveals three key thresholds:

- 0.1 seconds - the system feels instantaneous
- 0.3 seconds - matches the speed of the human sensorimotor feedback loop (a blink of an eye)
- 1.0 second - the user's flow of thought stays uninterrupted, though they notice the delay
 
Which means, if we look at the data, the perfect number is somewhere between 0.1 and 0.3 seconds.

### Core Web Vitals are a global goal

Knowing all this, how did we wind up with thresholds set by Google like LCP that needed to be below 2.5s?

> When they (Core Web Vitals) were determined, they noted that there isn’t one magic cutoff for “fast enough,” but multiple studies suggested keeping load times (LCP) under about 2–3 seconds is critical to avoid user frustration. Likewise, responses to user input (INP) should ideally happen within 100 ms to feel instantaneous and preserve the illusion of direct manipulation.  
>   
> -[ Addy Osmani, History of Core Web Vitals](https://addyosmani.com/blog/core-web-vitals/)

We learn a couple interesting things here that I’d like to zoom in on.

- Keeping the loading time under about 2-3 seconds is critical to avoid user frustration: We notice often that people optimizing Core Web Vitals think that 2.5 seconds should be the goal. But it’s actually just the bare minimum.
- Passing Core Web Vitals: We learned in our research, that the goal should actually be for a LCP feel instant. Or at least, in the blink of eye. That means we should aim for 0.2 seconds, not 2.5 seconds. Because Google also tells us, that their aim to “fast” was to be as smooth and quick as flipping a page.
- Likewise, responses to user input should ideally happen within 100 ms to feel instantaneous: This relates to First Input Delay, later replaced by Interaction to Next Paint. And it makes sense, you don't want to notice delays in interaction. But still we see that the goal here is 200ms, which is still noticeable. So, INP of 200ms: minimum to avoid frustration. Real goal to feel good: 100ms or less.
 
### The opportunity between frustration and delight

Tammy Everts [gave a talk](https://speakerdeck.com/tammyeverts/how-fast-is-fast-enough-perfnow-2025) at performance.now() 2025, which stuck with me, aiming for “Pragmagical” experiences for our visitors. And she is onto something here:

- Pragmatic: What is the moment it makes sense to stop optimizing and spend resources somewhere else?
- Magical: A great, instant experience where everything is fast, feels smooth, reacts quickly and doesn’t jump around.
 
There is a line there, and that is the one I’d like you all to find.

> At RUMvision, our pragmatic baseline for a standard commercial site is simple: all metrics and templates must be completely green at the 90th percentile (P90).
> 
> The single exception to this rule is critical public services and first-response platforms. From a lifeline perspective, you cannot afford to leave 10% of your audience in the performance dark. For those essential services, the threshold has to be set to the 98th percentile (P98) to ensure accessibility for everyone, on almost any hardware.

### Is instant achievable? Yes.

OK Karlijn, I hear you ask, the “blink of an eye” is really fast. And here is the thing, I agree it is. However, it’s 2026 and it’s not as impossible as it used to be.

We have:

- Speculation rules / prerendering
- BFCache
 
Both can get us near instant (like below 200ms) pages. And you can optimize a lot of users experiences with these techniques. But even without these pre-rendering and caching techniques within the browser, it is absolutely possible to have a page load faster than 1 second, and make the visitor feel like it’s fast.

### Is instant ALWAYS available? No.

First time visitors + cold cache + slow phones + bad internet connections... We can do a lot. We can’t make it instant for everyone, or at least - not every pagehit. This is where the pragmatical side comes in.

Having a 1s LCP for the 95-100 percentile is just not going to happen very often. There are too many real life variables to account for everyone having a good time. Between 75th and 95th percentile -> there is a huge opportunity to optimize their experience, and make them faster than 2.5 seconds, or even instant.

And until the 90th percentile: we feel like everyone should have at minimum an experience without frustration, so if your store doesn’t pass Core Web Vitals-metrics on that, than you are really coming up short in 2026. Honestly: on the 90th percentile, we should aim higher (lower?) than 2.5 seconds if you ask me.

## So, where does RUM come in?

If you agreed with me until now, than the answer to this question is obvious. CrUX is reported on the 75th percentile, and with the thresholds we just discussed. But if you want to optimize beyond that, and see it per template-type, beyond Chrome, in real life, it’s coming up very short.

That’s where real user monitoring, like RUMvision come in to give you insights. Those speculation rules for instance, did they work for real users at P90?

- BFcache, why did it fail and how often did it succeed?
- Is your LCP not accidentally lazy-loaded (and please account for different LCP’s per device and cookie-pop ups)?
- Are your ads causing cache-misses?
- What element is causing CLS and on what template specifically?
 
Core Web Vitals will not give you that info. Most RUMs won’t either, but we can, just by installing a snippet. You’ll have the first data to determine how fast everyone is on your sites within minutes, and be able to determine for yourself: **how fast is fast enough for me?**