Is your JavaScript being downloaded for nothing?

Why is Google paying attention to unexecuted JavaScript?

The issue is straightforward: many sites download JavaScript they never use. Entire libraries, obsolete functions, modules loaded "just in case". The browser must download, parse, and compile this code even if it serves no purpose.

Result: extended loading times, wasted bandwidth consumption, processor taxed for nothing. On mobile devices with limited connections, this carries significant weight. Google understands this well and integrates this metric into PageSpeed Insights to force awareness.

How does PageSpeed Insights detect this unused code?

The tool relies on Chrome's Coverage API, which traces actual code execution during loading. Each line of JavaScript is analyzed: executed or not. If entire blocks remain inactive, PageSpeed flags them as "unused JavaScript".

The metric appears in the "Opportunities" section with an estimate of potential loading time gains. The higher the percentage of unexecuted code, the more severe the alert.

What is the real impact on SEO?

Unused JavaScript slows down First Contentful Paint (FCP) and Time to Interactive (TTI), two metrics that feed into Core Web Vitals. While the direct impact on rankings remains moderate, a slow site degrades user experience, increases bounce rate, and reduces conversions.

Google won't penalize a site solely for unexecuted JS, but it's an indirect signal: poorly optimized code often reflects careless technical management. And Google picks up on that.

• PageSpeed Insights identifies JavaScript downloaded but never executed
• This dead code slows loading without adding value
• The tool uses Coverage API to trace actual code execution
• Impact on FCP, TTI and indirectly on Core Web Vitals
• Potential gains displayed in the "Opportunities" section

Is this alert really new?

No. The "Remove unused JavaScript" audit has existed in Lighthouse (and therefore PageSpeed Insights) for several years. What's changing is that Google is now explicitly communicating about it, a sign that the topic is rising in priority.

In practice, we observe that many sites ignore this recommendation, considering it secondary. Mistake. Sites that clean up their JS often gain 20 to 40% loading time reduction on mobile.

Is Google's tolerance threshold known?

[To verify] Google provides no official figure on the acceptable percentage of unexecuted JavaScript. PageSpeed Insights flags the problem as soon as it detects optimization potential, but no specific threshold is documented.

From experience, we see alerts starting at 15-20% unused code. Beyond 40%, the impact becomes critical. But these observations are empirical, not official.

Are all JavaScript frameworks equal when facing this problem?

No. Sites using React, Vue or Angular without proper tree-shaking often end up with huge bundles where only a fraction is used. Modern frameworks with code-splitting (Next.js, Nuxt) fare better.

WordPress sites with 15 plugins each loading their own jQuery library? Disaster. The problem isn't the framework, it's discipline (or its absence) in dependency management.

How do I identify unused JavaScript on my site?

First step: run PageSpeed Insights on your key pages. Scroll down to the "Opportunities" section and locate "Remove unused JavaScript". Click to see which files are affected and in what proportion.

Second verification: use the Coverage tab in Chrome DevTools (Cmd+Shift+P > "Show Coverage"). Load your page, interact with it, and observe the red bars (unexecuted code). Files with more than 50% red are priorities.

What concrete actions should I take to reduce this dead code?

Start by auditing your dependencies. List all JavaScript libraries loaded and ask yourself: is it really necessary? Used on this specific page? Often, you discover obsolete or redundant libraries.

Next, implement code-splitting: load only the JavaScript necessary for each page, defer the rest. Webpack, Rollup, and Vite offer configurations to automate this. For CMS platforms, explore intelligent minification plugins.

Finally, lazy-load non-critical scripts. Anything not essential for initial display (analytics tracking, social widgets, chat) can be loaded after the "load" event or on scroll.

What mistakes should I avoid when cleaning up?

Never remove code without testing. Some scripts appear unused at load but are triggered by user interaction (modals, sliders, forms). Test all critical user journeys after each modification.

Also be careful with third-party scripts (Google Ads, Facebook Pixel). You don't control their code. Optimization comes through asynchronous or deferred loading, not by removing the internal code they contain.

• Audit PageSpeed Insights and Coverage DevTools
• List all JavaScript dependencies and eliminate redundancies
• Implement code-splitting by page or component
• Lazy-load non-critical scripts (analytics, widgets)
• Test all functionality after each modification
• Monitor the metric regularly over time