Your Design Isn't Slow Because of Images. It's the JavaScript Nobody Measures

Last year we took over maintenance of a site with a nearly perfect Lighthouse score on images. WebP, lazy loading, correct dimensions, everything by the book. And it still noticeably stuttered on mobile. The client was convinced he needed a beefier host. He didn't. The problem was 11 third-party scripts fighting over the browser's main thread while the user was trying to tap a button.

This is the most common misunderstanding about web performance. Everyone looks at images because they're easy to see and easy to fix. An image is 400 KB, you squeeze it to 80 KB, you feel productive. But that image loads in the background and blocks no one. JavaScript does the opposite: it gets downloaded, parsed, compiled, and executed on the main thread, the same thread the browser uses to respond to clicks and scrolls. While that code runs, the interface freezes.

The numbers that explain why your site stutters

This isn't a feeling, it's a measurable trend. HTTP Archive's 2024 Web Almanac reports that the median mobile page loads 558 KB of JavaScript, a 14% jump in a single year. Meanwhile the median page fires 22 JavaScript requests, and pages at the 90th percentile fire 68. Each of those requests is a chance for something to stall on the main thread.

The worst part: roughly 44% of the JavaScript bytes downloaded, about 206 KB on the median mobile page, are never used during page load. You pay for the bandwidth and the CPU time for code the user never runs.

Then comes the third-party layer. The same source shows that more than nine in ten pages include at least one third-party script. The median page among the top 10,000 sites drags in 27 distinct third-party domains. Nearly a third of all those third-party scripts are ads, analytics, and consent management, which means exactly cookie banners, Google Analytics, and tag managers. Three categories of tools almost nobody measures by their real cost, and all three sit on the main thread.

The chains nobody sees

Here's why this is insidious. You drop in one script, Google Tag Manager. One line of code, harmless. But GTM is designed to load other scripts, which load others still. The Web Almanac calls these inclusion chains and measures the median chain at 3 levels deep, with 14% of chains going deeper than 5. The record chain on file was 2,930 levels deep.

Translated to reality: marketing says "we just need one pixel," you add one line, and the user's browser ends up pulling twelve scripts from eight domains. None live in your repository, none are under your control, and all slow down your site. When your boss asks why it's slow, you're staring at your own code, which is clean.

How to actually measure it

Stop looking at the overall Lighthouse number. It tells you things are bad, not who's to blame. Open Chrome DevTools, the Performance tab, record a load, and watch the main-thread flame chart. Hunt for "long tasks," tasks longer than 50 milliseconds. Each one is a moment when the interface doesn't respond. Hover over them and it tells you which domain they came from.

The faster route: Lighthouse has an audit called "Reduce the impact of third-party code." It lists each third-party domain by name, how many bytes it pulls, and how many milliseconds it blocks the main thread. That's the table you bring to the meeting. Not "the site is slow," but "this chat widget eats 340 milliseconds of main thread and 2% of visitors use it."

For ongoing measurement, set a performance budget. A hard limit, say a maximum of 150 KB of third-party JavaScript and no more than 200 ms of their blocking time. Every new marketing request then passes through one question: does it fit the budget, and if it doesn't, what do we cut?

What to cut without fear

First rule: nothing that blocks rendering should load synchronously in the <head>. Analytics, pixel, chat, all of it ships with async or defer, or better yet deferred until the user interacts. A visitor doesn't need Hotjar to see your homepage.

Second, take inventory. In every project we've inherited we found at least one tracking pixel from a campaign that ended two years ago. Nobody removed it because nobody dared, and it did nothing but slow the site down. A third-party script audit isn't a technical chore, it's a business decision: for each script you ask who uses it and what we'd lose without it.

Third, for tag managers consider a server-side setup or tools like Partytown that push third-party code into a web worker, off the main thread. It's not a magic wand and it has its traps, but for sites buried in analytics it can be the difference between an interface that responds and one that stutters.

The point

Images are an easy scapegoat because they're visible. JavaScript is the real culprit because it's invisible and nobody measures its true cost. Until you open the flame chart and see who's eating your main thread, you're optimizing the wrong thing. Next time someone says "we need a bigger server," open DevTools before you open your wallet.

Related:

• Core Web Vitals Aren't an SEO Trick. They're Your Revenue
• 84% of Developers Use AI Tools. So Why Isn't the Code Better?

Think your site stutters but don't know where the time goes? Let's run a third-party script audit and show you, line by line, what it costs and what can go. Contact us.