News for hackers. Stuff that matters.
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?

There are no comments on this comment yet.