When to Stop Optimising
I spent three hours last Tuesday staring at a PageSpeed Insights report, chasing a green score for a client who didn’t even care about their LCP. It’s the same cycle every time: someone buys a bloated, “all-in-one” multipurpose theme, watches their performance crater, and then expects me to perform digital alchemy to fix it. We’ve been sold this lie that speed is a game of chasing arbitrary benchmarks, but if you’re obsessing over a 98 vs. a 94 while your user is actually bouncing, you’ve already lost. Stop treating performance like a math problem and start asking how to decide when a site is fast enough for the actual humans trying to use it.
I’m not here to give you a checklist of technical vanity metrics that look good in a slide deck but mean nothing in production. Instead, I’m going to show you how to look past the hype and evaluate the actual logic of your stack. We’re going to talk about finding that sweet spot where your design decisions meet user reality, without letting a single over-engineered plugin dictate your budget.
Table of Contents
Core Web Vitals Benchmarks Are Just Someone Elses Defaults
Google hands you a set of Core Web Vitals benchmarks and basically tells you that if you aren’t in the green, you’re failing. It’s a neat, tidy way to package complexity, but it’s a trap. These numbers aren’t universal truths; they are just a baseline designed to push everyone toward a specific type of technical standard. When I’m auditing a site, I don’t just chase those green circles like they’re a high score in a video game. I look at the logic behind the metrics. A site can pass every automated test and still feel like it’s wading through molasses because the developer prioritized a massive, unoptimized hero video over everything else.
The reality is that you eventually hit a wall of diminishing returns in page speed. There is a massive difference between a site that loads in five seconds and one that loads in two, but the leap from 0.5 seconds to 0.2 seconds usually costs more in developer hours than it ever returns in revenue. You have to stop treating these benchmarks as a finish line and start treating them as a starting point for a conversation about user experience vs loading time. If the site feels snappy and the layout doesn’t jump around while someone is trying to click a button, you’ve probably already won the battle.
Optimizing for Perceived Performance Over Raw Millisecond Vanity
I’ve spent enough time staring at Lighthouse reports to know that chasing a perfect 100 is a fool’s errand. There is a massive difference between a site that is technically “fast” and a site that feels fast. You can obsess over shaving off fifty milliseconds of server response time, but if your layout shifts violently every time a heavy hero image finally decides to load, you’ve failed. This is where most developers trip up: they prioritize raw numbers over the actual human sitting on the other side of the screen.
I’m much more interested in optimizing for perceived performance than I am in hitting some arbitrary millisecond target. If I can get the text to render instantly while the heavy assets trickle in the background, the user stays engaged. They don’t feel the lag because the interface is already working for them. Once you hit a certain threshold, you hit the wall of diminishing returns in page speed; you’ll spend forty hours of development time just to move a metric by a fraction of a point. At that point, you aren’t building a better site; you’re just feeding a vanity metric that doesn’t actually move the needle on your conversion rate.
Stop chasing ghosts and start looking at the actual user experience
- Stop obsessing over the PageSpeed Insights score and start looking at your bounce rates; if the numbers are green but people are leaving the second the hero image loads, your “fast” site is actually a failure.
- Test on the hardware you’re actually ignoring—not your $3,000 MacBook Pro, but a three-year-old Android running on a spotty LTE connection in a coffee shop.
- Measure the “Time to Interactive” from a human perspective, because I don’t care if the page is technically loaded if the user clicks a button and nothing happens for two seconds while some bloated script wakes up.
- Audit your third-party bloat instead of shaving milliseconds off your CSS; most of the time, the “slowness” isn’t your code, it’s the five tracking pixels and the chat widget someone insisted on installing last Tuesday.
- Determine your “good enough” threshold based on your specific conversion goal, because a high-end portfolio needs a different level of snappiness than a local plumber’s landing page.
Stop Chasing Ghosts
At the end of the day, deciding when a site is “fast enough” isn’t about hitting a perfect 100 on a Lighthouse report or obsessing over millisecond fluctuations that no human being can actually perceive. It’s about recognizing that your stack—the theme, the plugins, the page builder—has already made a series of heavy-handed decisions about how your site should behave. You need to stop chasing benchmarks and start evaluating whether those decisions serve your user or just your ego. If your perceived performance is smooth and the critical content is there before the user loses interest, you’ve won. Don’t let a vanity metric trick you into over-engineering a solution for a problem that doesn’t actually exist.
My advice? Build with intention and stop treating performance like a game of whack-a-mole. Once you understand the logic behind your tools, you’ll realize that optimization is a series of trade-offs, not a destination. You don’t need the fastest site on the planet; you just need a site that doesn’t get in its own way. Stop letting the tools dictate your success and start making the decisions yourself. Now, go close those twenty open tabs of performance audits and actually go build something meaningful.
