Why JavaScript is the main reason websites feel slow
Images are heavy, but JavaScript is expensive: it must be downloaded, parsed and run before the page works. Why that hits phones hardest, and how to ship less.
The short answer
Images make pages heavy. JavaScript makes them slow. The difference is what the browser has to do with each: an image is downloaded and drawn, while script is downloaded, parsed, compiled and executed, on the single thread that also has to draw the page and respond to the visitor’s taps. Byte for byte, script is the most expensive thing a website can send, and phones pay several times more for it than laptops.
A business website sends far more of it than its pages need.
Why script costs more than bytes suggest
| Step | Image | Script |
|---|---|---|
| Download | Yes | Yes |
| Decode or parse | Fast, often off the main thread | On the main thread, proportional to size |
| Compile | No | Yes |
| Execute | No | Yes, and it may fetch and run more |
| Blocks interaction | No | Yes, while running |
| Cost on a mid-range phone versus a laptop | Similar | Several times higher |
A phone’s processor is slower and its connection worse, and script is the one resource whose cost scales with processor speed. The same page that feels instant at your desk can take seconds to become usable on the device most visitors hold.
Where the script comes from
- Frameworks that render the page with script. The page arrives mostly empty and is built in the browser. Every visitor downloads and runs the framework and the page logic, even to read plain text.
- Tag managers and third-party widgets. Analytics, chat, A/B testing, social embeds, ad pixels. Each is script you did not write, loaded on every page, often loading more script of its own.
- Libraries for one effect. A whole animation or carousel library for a single slider on the homepage, shipped to every page.
- Accumulation. Nobody removes anything. Each addition seemed small.
How to ship less
- Send HTML. Pages that arrive as finished HTML need no script to appear. That is the default for a content site, and it removes the largest cost at a stroke.
- Script only where a component needs it. A search box, a form, a cart. Each with its own small script, loaded when needed. Everything else stays script-free.
- Audit third parties by cost. For each tag: what does it earn, and what does it cost the visitor in main-thread time? Remove what does not earn its place; defer what must stay.
- Measure on a phone. Field data from real visitors, not a laptop test, decides whether the problem is solved.
What this means for you
If your site feels slow on phones and the images are already sized properly, the script is the cause. Look at how much is sent and where it comes from: a framework rendering plain pages, a tag manager full of history, libraries for single effects. The structural fix is a site that sends HTML and adds script only where needed, and it is why sites built that way stay fast without a tuning project.
Frequently asked questions
Isn't image size the bigger problem?
Images are usually the largest bytes, and they matter for how fast the main content appears. But an image only needs to be downloaded and drawn. Script must be downloaded, then parsed, then compiled, then run, all on the one thread that also handles the visitor's taps. Byte for byte, script is the most expensive thing you can send.
Our developer says the framework is fast. Is that wrong?
The framework may be fast at what it does. The question is whether a plain page needs it at all. A framework that renders every page with JavaScript ships its runtime and the page's logic to every visitor, including one who came to read one article. The fastest script is the one that is not sent.
How do I know how much script our site sends?
PageSpeed Insights lists the scripts and their sizes and shows how long the main thread was busy. Browser developer tools show the same per file. Compare the total with what the page actually does; a brochure page carrying a large application bundle is the pattern to look for.
Sources
- Google web.dev: Interaction to Next Paint (INP) (accessed 2026-09-11)
- Google web.dev: Web Vitals (accessed 2026-09-11)