PageSpeed 70 vs 95: the true reality
Source: Dev.to
Introduction
Let’s be honest from the start: if you have a website for an accounting firm, a psychologist, a real estate agency, a barbershop, a clinic, an office, or any other common local business, it’s very unlikely that someone is opening your site with a stopwatch in hand thinking, “Wow, it loaded in 1.8 s instead of 1.2 s.” That’s simply not how most decisions are made in the real world. (And at some point, I was part of it too.)
The developer bubble vs. the business reality
Inside the developer bubble, a PageSpeed score below 90 feels like a serious mistake, Lighthouse not fully green is a sign of negligence, and a CLS above 0.1 is almost an architectural sin. Outside that bubble—where businesses need to generate leads and pay bills—the logic is far more pragmatic.
Clients want to show up on Google, be found on Maps, inspire trust, and be able to contact someone without friction. They don’t know what LCP is, they don’t care about TBT (not the old Twitter one, the other), and they’re very unlikely to reject a service because a PageSpeed score is 78 instead of 95. That doesn’t make them wrong—just human.
Speed matters, but context matters more
There’s a massive difference between a truly slow website—heavy, janky, taking 5–8 seconds to show anything—and a well‑built site sitting around a 65–80 score, loading fast enough to deliver a solid experience.
- Going from 40 to 70 completely changes user perception.
- Going from 70 to 95 improves important details, but rarely redefines the outcome of a local business on its own.
Speed is a ranking factor—that’s a fact—but it’s not the dominant factor in most scenarios. For common websites, content quality, well‑executed local SEO, clarity of the offer, authority, and reviews carry far more weight. Speed works as a strong reinforcement—often as a tie‑breaker—but rarely as a miracle solution on its own.
When to chase higher scores
A PageSpeed score of 98 helps, improves experience, and reduces friction, but it doesn’t compensate for weak content or a confusing value proposition. Chasing very high scores usually involves real technical decisions:
- Reducing animations
- Revisiting aesthetics
- Changing rendering strategies (e.g., moving to SSG/ISR)
- Optimizing builds
- Reviewing dependencies
All of these have a cost—in time, complexity, and architectural trade‑offs. For many common websites, the most visible return from these optimizations appears when there is volume: meaningful traffic, many sessions, many conversions, or more complex digital products. Outside of that, the gains exist, but they’re more subtle and cumulative.
The right question
“Does my site load fast enough to deliver a good experience and not push people away?”
If the answer is yes, you’ve already solved most of the problem. Everything else becomes refinement.
Looking ahead
Before anyone assumes this is just opinion, a future post will continue the discussion and dive into the data: real studies, Core Web Vitals, field metrics, large‑company case studies, and concrete impacts on conversion and business. No empty lab tests—just numbers from people who actually gained or lost money because of performance.
Call to action
Now I want to hear from you:
- Have you ever seen a client complain about speed?
- Lost a project because of a score?
- Felt a real difference after improving performance?
Let’s talk about real life—with less dogma and more context.