Performance

How JavaScript Slows Your Site — and What to Do About It

JavaScript is the single biggest cause of slow interaction response on the modern web. A page can load its HTML and CSS in under a second and still feel sluggish because the browser is busy parsing, compiling and executing scripts before the user can do anything. Here is how to identify the scripts that hurt and what to do about them.

How JavaScript affects performance

When a browser loads a page, it builds a DOM from the HTML. Every time it encounters a <script> tag without special attributes, it stops building the DOM, downloads the script, parses it, compiles it and executes it before moving on. This is called render-blocking, and it is the main reason JavaScript pages often feel slower than static ones.

The impact goes beyond the initial load. Once the page is visible, JavaScript continues to consume CPU and memory on interaction. A poorly optimised event listener, a heavy framework re-render or a background analytics script can add hundreds of milliseconds to a button press or a form submission. Google uses Interaction to Next Paint (INP) to measure this, and it has become a Core Web Vital because slow interactivity drives users away.

The fix is rarely “remove all JavaScript”. Modern sites need JavaScript for interactivity, analytics, fonts and third-party widgets. The goal is to control when scripts load, which scripts load and how much work they do on the main thread.

Identifying heavy scripts with Chrome DevTools

Before you fix anything, measure. Chrome DevTools gives you two panels that matter most for JavaScript performance.

The Coverage panel (Cmd+Shift+P, type “Coverage”) shows what percentage of each script actually runs on the page you are viewing. It is common to see 70-80% of a framework library go unused on a marketing page. The unused bytes are still downloaded, parsed and compiled.

The Performance panel records a trace while you interact with the page. Look for long yellow or purple tasks on the main thread. The “Bottom-Up” tab shows which functions consume the most total time. If a single analytics vendor or chat widget appears near the top, that script is costing you real money in lost conversions.

Third-party script auditors like Request Map or WebPageTest can show the full dependency tree. A single tag manager often loads ten or more additional scripts, each blocking the main thread. The fix may be as simple as removing unused tags.

Defer vs async — loading scripts without blocking

The HTML defer and async attributes tell the browser to download scripts without blocking the DOM parser.

defer downloads the script in the background and executes it only after the HTML is fully parsed. Scripts with defer run in order, which makes them safe for scripts that depend on each other or on the full DOM. Use defer for your own application code and for analytics that need the whole page.

async also downloads in the background, but it executes as soon as the download finishes, regardless of whether the HTML parser has finished. Async scripts are unordered and can interrupt the parser mid-way. Use async for independent third-party scripts such as social media widgets, A/B testing tools and chat widgets where execution order does not matter.

A simple rule: put your own scripts in defer and third-party snippets that do not depend on the DOM in async. Scripts that must run before the page renders, such as critical path code, can stay in the <head> but should be kept small and inlined.

Code splitting — only load what you need

Code splitting divides your JavaScript bundle into smaller chunks that load on demand. Instead of sending a 300 KB bundle for every page, the browser loads only the JavaScript needed for the current route or interaction.

Modern frameworks such as React, Vue and Angular support code splitting natively through dynamic import(). A route-based split ensures the homepage loads only homepage JavaScript, and the dashboard code loads only when the user navigates there. Component-level splitting goes further: a heavy image carousel or a rich text editor can load its JavaScript only when the user scrolls to it or clicks a button.

Measure the impact with Lighthouse. A site that moves from a single 400 KB bundle to route-based splitting often sees a 30-50% reduction in JavaScript per page, which translates directly into faster LCP and lower INP.

Removing unused JavaScript

Unused JavaScript is the easiest problem to fix because the solution is deletion. Browser DevTools Coverage panel tells you exactly which functions and modules never execute on a given page.

Start with libraries. If your site loads jQuery but uses only a handful of selectors, replace them with document.querySelector. If a slider plugin is used on one page but loaded site-wide, move the script tag to that page only. If you bundle your own code, tree-shaking during the build step removes exported functions that nothing imports.

Polyfills are another source of bloat. Many sites load polyfills for browsers that no longer need them. If your analytics shows that 98% of visitors use modern browsers, drop the polyfill bundle and save 30-50 KB of parse time.

A clean-up pass every six months removes scripts that were added for a campaign, a temporary A/B test or a feature that was never launched. Each removal reduces parse time, main-thread blocking and the attack surface for security vulnerabilities.

Managing third-party scripts

Third-party scripts are the hardest to control because you do not write them. A single tag manager can load dozens of vendor scripts, each competing for main-thread time.

Audit every third-party script by asking three questions. Does it need to run on every page, or can it be restricted to specific pages? Does it need to run immediately, or can it be deferred after the page is interactive? Does it need to run at all, or does the data arrive too late to act on?

Use a script-loading library or a tag manager’s built-in delay features to pause non-critical scripts until after requestIdleCallback or a user interaction. Set resource hints like <link rel="preconnect"> for critical third-party origins to speed up the connection while keeping the script non-blocking.

Where possible, replace heavy third-party embeds with static fallbacks. A social media feed that loads a full JavaScript SDK can be replaced with a server-side rendered list of recent posts, updated via a cron job. The performance gain on every page load is significant, and the user experience is nearly identical.

Questions

Frequently asked questions

How do I know if JavaScript is slowing my site?

Run a Lighthouse test and check the “JavaScript execution time” diagnostic. Anything above 2 seconds on mobile is a problem. Also check the Chrome DevTools Performance panel for long tasks on the main thread.

What is the difference between defer and async?

Both download scripts without blocking HTML parsing. Defer executes scripts in order after the HTML is fully parsed. Async executes as soon as the download finishes, in whatever order the downloads complete. Use defer for your own code and async for independent third-party scripts.

Should I remove all JavaScript from my site?

No. JavaScript is necessary for interactivity, analytics and dynamic content. The goal is not elimination but optimisation: load only what is needed, as late as possible, and keep execution short.

How much can code splitting improve performance?

Most sites that implement route-based code splitting see a 30-50% reduction in JavaScript per page. This directly improves LCP, INP and Time to Interactive.

How often should I audit third-party scripts?

Every three to six months. Marketing campaigns, A/B tests and temporary widgets accumulate over time. Each audit should remove scripts that are no longer needed, defer those that can wait, and restrict page-level scripts to the pages that actually use them.

Keep reading