Visualizing the Hidden CPU Cost of Modern JavaScript Frameworks
Skip to main content
Visualizing the Hidden CPU Cost of Modern JavaScript Frameworks
Get link
Other Apps
June 23, 2026
A while ago, I noticed something that didn't quite make sense.<br>On paper, today's internet connections are incredibly fast. Many people have access to hundreds of megabits per second, and modern processors are vastly more powerful than those from a decade ago.<br>Yet it's still common to open a website, see most of the interface appear almost immediately, and then wait another second or several seconds before buttons respond or menus become clickable.<br>The page looks finished.<br>It just isn't usable.
That made me curious about what the browser was actually doing after the download had already completed.
The Observation<br>When most people think a website is loading, they imagine data traveling across the internet.<br>That's only part of the story.<br>Modern web applications often send HTML, CSS, JavaScript, images, fonts, analytics scripts, and framework code to the browser.<br>Downloading those files is only the beginning.<br>After everything arrives, the browser still has to parse, compile, and execute the JavaScript before much of the page becomes interactive.<br>For simple websites this work is minimal.<br>For large applications, it can become surprisingly expensive.
The CPU Becomes the Bottleneck<br>One thing I found interesting is that improving your internet connection doesn't reduce the amount of work your processor has to perform.<br>Once the JavaScript bundle reaches your computer, the network's job is finished.<br>Now the browser takes over.<br>It builds objects in memory.<br>Creates component trees.<br>Calculates layouts.<br>Attaches event listeners.<br>Updates the DOM.<br>All of that work happens on your own hardware.<br>If the workload becomes large enough, the processor not the network becomes the limiting factor.
Mobile Devices Feel It Even More<br>This becomes much more noticeable on phones and lightweight laptops.<br>Unlike desktop computers with large cooling systems, mobile devices operate within very tight thermal and power limits.<br>They are designed to deliver short bursts of performance while preserving battery life.<br>When a browser spends an extended period executing large amounts of JavaScript on the main thread, the processor remains busy much longer than it normally would.<br>As temperatures increase, modern chips automatically reduce their clock speeds to stay within safe operating limits.<br>The result is familiar to almost everyone.<br>The page appears.<br>But it doesn't respond.<br>Buttons don't work.<br>Scrolling feels delayed.<br>The interface is waiting for the processor to finish its work.
A Small Demonstration<br>The following Python example doesn't simulate a browser exactly, but it demonstrates the difference between a fast download and a processor performing sustained work afterward.
$ python test.py<br>Downloading page...<br>Download complete.<br>Processing application...<br>CPU work completed in 3.42 seconds.<br>Application is now responsive.
The important part isn't the exact numbers.<br>It's the sequence.<br>The "download" finishes almost instantly.<br>Most of the waiting happens afterward while the processor performs local computation.<br>That's a useful mental model for understanding why some modern web applications feel slow even on fast internet connections.
Why Modern Frameworks Exist<br>To be fair, this isn't simply bad engineering.<br>Modern JavaScript frameworks solve real problems.<br>They help developers manage complex applications, maintain reusable components, and build interactive user experiences that would have been much harder to implement a decade ago.<br>Those benefits are significant.<br>But every abstraction has a cost.<br>The more work we ask browsers to perform locally, the more dependent we become on the performance of the user's hardware.
Finding the Balance<br>I don't think the solution is abandoning modern frameworks.<br>The real challenge is deciding where work should happen.<br>Some processing makes perfect sense in the browser.<br>Other tasks may be better handled on the server before the page ever reaches the client.<br>Techniques such as server-side rendering, static generation, code splitting, and reducing unnecessary JavaScript can all improve how quickly a page becomes interactive.
What I Learned<br>This changed the way I think about web performance.<br>For a long time, I assumed slow websites were mostly caused by slow internet connections.<br>Now I see that downloading a page is often the easy part.<br>The real work frequently begins after the browser already has everything it needs.<br>Modern web performance isn't only about moving data faster.
It's also about respecting the limited processing power, battery life, and thermal constraints of the devices people use every day.
Note: This benchmark was executed natively inside a highly constrained mobile terminal environment. To see the engineering limits and the long-term sovereign AI mission behind this setup, read...