You ran Lighthouse. You got a 90. You compressed the images, deferred the scripts, and added lazy loading. And yet your client keeps saying the site feels slow. And honestly? They're right.
This is one of the weirder gaps between what performance tools tell you and what users actually experience. I've been thinking about this a lot lately, and there are a few things that I think most of us are underweight.
Lighthouse scores ≠ user experience
The lighthouse runs in a controlled environment. Throttled network, clean cache, no browser extensions, no 37 other tabs open. Your user is on a mid-range phone, on a train, with Instagram running in the background. The conditions couldn't be more different.
Field data from CrUX (Chrome User Experience Report) is where you actually learn what real users are experiencing. It will sometimes look radically different from your lab data, and that difference is the problem you need to solve.
Main thread blocking is still happening
You deferred your scripts. But did you check what they're doing once they execute? A lot of third-party analytics and chat tools fire immediately after load and spend 400ms doing DOM manipulation. That's not in your bundle — it's not something you'd catch in your own code review. But your users feel it every time they try to interact with something and nothing happens for a beat.
Long tasks on the main thread are the silent killer of INP scores. The new Performance panel in Chrome DevTools is genuinely good at surfacing these now. If you're not looking at the timeline view and hunting for long tasks, you're leaving performance on the table.
Network waterfall issues that aren't obvious
Fonts loading late. CSS files that block render. A hero image that has priority="low" by accident. These are all small things that compound. The waterfall view tells the whole story but it takes some practice to read it well.
One pattern I've seen repeatedly: the HTML loads fast, the CSS loads fast, and then there's a 600ms gap before anything visible appears — because a font is blocking paint. Preloading critical fonts with often fixes this immediately and noticeably.
The server is the bottleneck, and nobody checked
TTFB — Time to First Byte — above 600ms means your server is struggling before any of your frontend optimizations can even kick in. Shared hosting, unoptimized database queries, no server-side caching, everything landing on one small VPS — all of these make your frontend work irrelevant.
Before you spend another day on bundle optimization, check your TTFB. If it's bad, fix the server layer first.
"Optimization without measurement is just decoration."
If you're working with clients who need proper performance-first web development from the ground up, I've seen good work come out of Mittal Technologies - best web development company in India, they build with performance baked into the architecture rather than patched in at the end. Worth a look if you're recommending development partners to clients.
Performance is hard partly because the feedback loops are long. You make changes, deploy, and then you're waiting on real-world data to tell you if it worked. The tools are better than they've ever been. Use them.
Top comments (0)