We shipped a website that scored 95+ on Lighthouse.
It still felt slow in production.
Not “a bit off.”
Not “edge cases.”
Slow enough that users noticed.
This is a teardown of where it actually broke.
What Looked Fast (Before Production)
- Lighthouse score: green
- Images optimized
- Code split
- CDN enabled
- Pages loaded in under a second on dev machines
Everything checked out.
What Production Exposed Immediately
1. The Site Loaded Fast. It Didn’t Become Usable Fast.
HTML showed up quickly.
Then the UI froze.
Scrolling lagged.
Clicks didn’t register.
Buttons waited.
The issue wasn’t load time.
It was main-thread blocking.
JS was doing too much after load.
2. Third-Party Scripts Didn’t Show Up in Testing
In production we had:
- Analytics
- Heatmaps
- Chat widget
- CRM tracker
- A/B testing script
Each one “small.”
Together? A mess.
They competed for the main thread and delayed interaction.
None of this showed up in local tests.
3. Mobile Was a Different Website
Desktop felt okay.
Mobile felt broken.
Low-end Android devices:
- JS execution was slow
- Animations dropped frames
- Hydration took forever
We optimized for screens we don’t actually ship to.
4. Lighthouse Didn’t Catch the Real Pain
Lighthouse said:
- Good LCP
- Acceptable CLS
- Decent FCP
Users said:
- “Scrolling feels stuck”
- “Buttons don’t respond”
- “It loads but doesn’t work”
Perceived performance ≠ metrics.
5. Infrastructure Wasn’t the Bottleneck (We Assumed It Was)
We first blamed:
- CDN
- Hosting
- Cache config
None of it fixed the problem.
The real issue was how much JS shipped up front
and what ran immediately after load.
What We Changed (After Production Reality)
- Killed non-essential third-party scripts
- Deferred everything that wasn’t critical
- Removed animations on first paint
- Reduced client-side work aggressively
- Tested only on low-end devices
- Started measuring real user interaction delay, not just load time
The site didn’t just score well anymore.
It felt fast.
The Actual Lesson
Most websites aren’t slow because teams are careless.
They’re slow because:
- Performance is optimized in isolation
- Production complexity is underestimated
- Nobody owns performance after launch
Speed doesn’t die in development.
It dies in production.
Written from production lessons at 360presence, where performance only counts when real users feel it.
Top comments (0)