Why is unused JavaScript tanking your Core Web Vitals even when it never executes?

Why does code that's never called still impact performance?

The browser doesn't know in advance which JavaScript will be executed. It must therefore download, parse, and compile all JS files served. Even if a function is never called, its code has already consumed bandwidth and processor time.

This phenomenon is particularly visible on mobile: slow connections, limited processors. A 300 KB file packed with useless functions slows down page rendering — and degrades Core Web Vitals, notably FID and TBT.

What does code reuse actually mean in practice?

WordPress templates, pre-built themes, poorly configured Webpack bundles, libraries imported in their entirety when you only use a handful of functions. It's the daily reality for most websites.

Google points to a structural problem: development ease (reusing an existing component) clashes head-on with client-side performance. Legacy code accumulates, developers add without removing.

How does PageSpeed Insights detect unused JavaScript?

The tool analyzes code coverage via DevTools: it traces which lines of JS were executed during loading and initial interaction. Everything that wasn't touched is marked as "potentially unused".

Pay attention to the word "potentially" — some scripts only execute during specific interactions (button click, deep scroll). PSI cannot simulate all user journeys. But in the vast majority of cases, the diagnosis is reliable.

• The browser downloads and parses all JS, even code that never gets used
• Code reuse (frameworks, templates) mechanically introduces unnecessary weight
• PageSpeed Insights measures code coverage and identifies superfluous scripts
• This waste directly impacts Core Web Vitals (FID, TBT, indirect LCP)

Is this statement consistent with real-world observations?

Absolutely. We regularly see sites with 500 KB of JS just to display… a contact form. WordPress + visual builder + poorly coded plugins = obese bundle. And PageSpeed Insights measures it ruthlessly.

What's interesting is that Google finally makes official a point often downplayed by developers: "Yes, but this code doesn't execute, it costs nothing." Wrong. Parsing and downloading have a measurable cost, and that cost degrades user experience.

Should you take PageSpeed Insights literally on this point?

Yes, but with nuance. The tool flags "unused JavaScript," not necessarily "JavaScript to delete." A script may be necessary after interaction — lazy loading, modal, e-commerce cart.

The real challenge: separating what's critical for initial rendering from what can wait. Code splitting, dynamic imports, defer/async. But PageSpeed Insights doesn't state this explicitly — it simply points out the problem.

In what cases does this recommendation become counterproductive?

If you blindly remove everything PSI flags in red, you risk breaking features. A tracking script, a chatbot, a payment system — all of that can appear "unused" if the tool hasn't simulated the right user journey.

The other trap: fragmenting code too much. Multiplying small JS files can generate more HTTP requests, which degrades performance on HTTP/1.1 or with high network latency. You need to find balance — and it's rarely binary.

What should you do concretely to reduce unused JavaScript?

First step: measure. Open Chrome DevTools > Coverage, reload the page, interact normally. Red bars show code that was never executed. Identify the heaviest files with the lowest coverage.

Next, prioritize. Start with the big pieces: frameworks imported in their entirety, obsolete libraries, disabled WordPress plugins whose JS still loads. Don't waste time optimizing 2 KB when you're dragging around 200 KB of jQuery UI for a single datepicker.

What mistakes should you avoid in this optimization?

Don't delete blindly. A script can be "unused" during initial load but essential after interaction — form, modal, carousel. Test each change under real conditions, across multiple user journeys.

Also avoid falling into the "lazy-load everything" trap. Deferring too many scripts can create visual shifts (CLS) or delay interactivity (FID). The goal isn't zero JS on load, but to load the bare minimum needed for initial rendering.

How do you verify your site is compliant?

PageSpeed Insights remains the reference tool — use it regularly, in both mobile and desktop mode. Compare scores before/after optimization, and verify that TBT (Total Blocking Time) actually decreases.

As a complement: WebPageTest with a realistic mobile profile (3G/4G), Chrome User Experience Report for field data. If your field Core Web Vitals don't improve after optimization, you've missed a step.

• Measure code coverage with DevTools > Coverage
• Identify the heaviest JS files and the least-used ones
• Prioritize optimizations: frameworks, libraries, obsolete plugins
• Implement code splitting and dynamic imports to defer non-critical code
• Test under real conditions across multiple user journeys
• Validate with PageSpeed Insights and WebPageTest (mobile 3G/4G)
• Monitor field Core Web Vitals (CrUX) to confirm real-world impact