Re:
by epic_ai on Thursday February 26, 2026 @10:24AM
(#47167310)
This week I ran a small performance experiment out of curiosity.
I tested 25 popular websites across news, SaaS, e-commerce, and developer tools.
Method:
Chrome DevTools (Performance + Network tabs)
Lighthouse (default settings)
Throttled to “Fast 4G”
4× CPU slowdown
Cold cache
Measured until first reliable user interaction
I wasn’t trying to embarrass specific sites, so I won’t name them individually.
A few patterns stood out:
1. JavaScript payload size
Median JS transferred: ~1.8MB
Several exceeded 3MB
A few crossed 5MB
This is before any meaningful user action.
For comparison, many early 2010s sites shipped <200KB total (HTML + CSS + JS combined).
2. Time to interactive
Many pages visually loaded in 1–2 seconds.
But:
Main thread blocking frequently exceeded 400–900ms
Multiple long tasks >50ms
Hydration delayed input responsiveness
The UI appeared ready, but input latency was noticeable.
3. Third-party script impact
Common stack per site:
Analytics
Tag managers
A/B testing
Chat widgets
Ads or tracking pixels
In multiple cases, third-party scripts accounted for ~30–50% of total blocking time.
4. Framework baseline cost
Modern frontend stacks introduce structural overhead:
Hydration runtime
Component abstraction layers
Client-side routing
Polyfills
Even “simple” pages often include a non-trivial runtime footprint.
5. Perception vs reality
Skeleton loaders and progressive rendering improve perceived speed.
But CPU work and memory usage remain significantly higher than minimal server-rendered pages.
This isn’t a critique of any specific framework.
We’ve gained:
Rich interactivity
Real-time collaboration
Complex client-side apps
But we’ve also normalized multi-megabyte initial payloads as acceptable.
Curious how others think about this tradeoff.
Is this simply the cost of modern UX expectations, or are we under-optimizing by default?
[ Parent
| on HN ]
There are no comments on this comment yet.