Fixing “Reduce Unused JavaScript” in PageSpeed Insights

You run your WordPress site through Google PageSpeed Insights, and the orange warning stares back at you: Reduce unused JavaScript. Below it, a list of scripts you did not write, cannot safely delete, and barely understand. This is the single most common performance recommendation WordPress site owners face, and most optimization guides get the solution completely wrong. They tell you to remove scripts. The real fix is to control when and how scripts execute. That is exactly what OptiWave does.

What Does “Reduce Unused JavaScript” Actually Mean?

When Lighthouse flags “reduce unused JavaScript,” it is measuring a coverage gap. The browser downloaded a JavaScript file, parsed every byte of it, but only a fraction of those functions actually ran during the initial page load. The rest sat idle in memory, blocking the main thread for zero benefit.

A typical WordPress page loads scripts from your theme, page builder, contact forms, analytics, chat widgets, WooCommerce cart handlers, and slider libraries. On a fresh Elementor install with WooCommerce, you can easily reach 800KB to 1.2MB of render-blocking JavaScript before a single word of content appears. Lighthouse sees all that code execute during initial paint and correctly flags it as waste.

The keyword here is during initial paint. Most of those scripts are not truly unused. They handle interactions that happen later: menu toggles, cart updates, form validation, slider transitions. The problem is not that the code exists. The problem is that it runs too early.

Why Removing Scripts Is the Wrong Approach

The instinct after seeing this audit is to start dequeuing scripts. Developers grep through wp_enqueue_script handles, write conditional logic to load scripts only on specific pages, and manually strip out anything that looks unnecessary. This works until it does not.

Remove the wrong jQuery dependency and your mobile menu stops opening. Dequeue a WooCommerce fragment handler and cart counts freeze. Strip out a form library and your lead capture breaks silently, costing conversions for days before anyone notices. Every WordPress plugin registers scripts with internal dependency chains that are invisible to a simple dequeue strategy.

The safer, more effective approach is execution timing control. Instead of deleting scripts the page might need later, you keep every script intact but change when the browser processes it. This is the core philosophy behind OptiWave’s optimization engine: nothing gets removed, everything gets rescheduled.

The Crawl Budget Problem Nobody Talks About

There is a second, less obvious reason why OptiWave deliberately avoids the “remove unused CSS and JS” approach that other performance plugins use. Those plugins analyze each page individually, strip out the CSS rules and JavaScript functions that page does not need, and generate a unique optimized file for that specific URL. A site with 200 pages ends up with 200 unique CSS files and potentially 200 unique JS bundles sitting in the cache directory.

That is hundreds of extra static asset URLs that did not exist before. And crawlers find them.

Google, Pinterest, Bing, and other platform crawlers allocate a finite crawl budget to your domain. Crawl budget determines how many URLs a bot will request during each visit. When crawlers discover hundreds of generated CSS and JS files in your page source, they follow those URLs and spend crawl budget downloading and indexing assets that provide zero SEO value. Every request wasted on a per-page generated stylesheet is a request that could have been spent indexing your actual content, product pages, or blog posts.

Pinterest is particularly aggressive about crawling linked assets. If your Rich Pins or product pins link to pages that reference hundreds of unique generated files, the Pinterest crawler burns through your crawl allocation processing those assets instead of discovering new pinnable content. The same problem impacts Googlebot on larger sites where crawl efficiency directly affects how quickly new pages get indexed.

OptiWave sidesteps this problem entirely. Because it uses Critical CSS (one compact inline style block per page type) plus the media="print" swap on your existing original stylesheets, no duplicate files are generated. Your original CSS and JS files stay exactly where they are with their original URLs. Crawlers see the same asset URLs they have always seen. Zero crawl budget wasted on generated files, zero asset URL bloat in your sitemap or page source.

The Media Print Method: How OptiWave Handles Unused CSS

Understanding how OptiWave handles the CSS side of the “unused code” problem is critical, because PageSpeed flags unused CSS with equal severity.

OptiWave uses a two-phase CSS delivery pipeline. First, it generates Critical CSS: the minimal stylesheet required to render the visible above-the-fold content without any layout shift. This critical stylesheet gets inlined directly into the <head> of the HTML document, so the browser can paint the first frame immediately.

Every remaining stylesheet (your theme CSS, builder CSS, plugin CSS) gets its media attribute rewritten from "all" to "print". The browser still downloads these files, but it treats them as print-only stylesheets and skips them entirely during screen rendering. Once the page finishes loading, a tiny inline script swaps the media attribute back to "all", and the full styles apply seamlessly.

The result: Lighthouse sees zero render-blocking CSS. The browser paints content instantly using only the critical styles. And every style the page actually needs loads asynchronously without breaking layouts, animations, or responsive breakpoints. No styles removed. No duplicate files generated. No broken components. Just smarter delivery timing.

Defer, Idle, and On-Interaction: OptiWave’s Three JavaScript Strategies

OptiWave provides three distinct JavaScript execution strategies that you can assign per-script or apply globally. Each serves a different purpose, and understanding the differences is the key to passing both synthetic Lighthouse tests and real-user INP field data.

1. Defer: The defer attribute tells the browser to download the script in parallel with HTML parsing but delay execution until the DOM is fully constructed. This is the lightest-touch optimization. Scripts maintain their original execution order and run immediately after the parser finishes. Use this for essential UI libraries like jQuery, navigation controllers, and WooCommerce cart handlers that need to initialize before the user interacts with anything.

2. Idle (requestIdleCallback): Scripts assigned to the idle strategy get deferred even further. OptiWave uses the browser’s requestIdleCallback API to execute these scripts only when the main thread has nothing else to do. If the user is scrolling, clicking, or triggering animations, idle scripts wait. The moment the browser reports a free frame, the script runs. This is ideal for non-critical functionality like analytics trackers, heatmap recorders, A/B testing libraries, and social share button initializers.

3. On Interaction: This is the most aggressive strategy. Scripts flagged for on-interaction execution do not run at all until the user performs a deliberate interaction: a click, a tap, a scroll, or a keypress. OptiWave rewrites the script’s type to text/plain (preventing browser execution) and stores the original source in a data-src attribute. When the first user interaction fires, OptiWave rapidly loads and executes the queued scripts in their correct dependency order. This strategy is best for heavy third-party scripts like chat widgets, video embeds, and marketing pixels that have zero impact on initial page experience.

The power of OptiWave is that these three strategies work together on the same page. Your jQuery and navigation scripts defer. Your analytics runs at idle. Your live chat widget waits for interaction. The main thread stays clear during initial load, Lighthouse reports minimal unused JavaScript, and real users get instant responsiveness.

How Critical CSS Eliminates Render-Blocking Stylesheets

PageSpeed Insights does not only flag unused JavaScript. The companion warning, “Eliminate render-blocking resources,” targets CSS files that block the browser from painting anything until they are fully downloaded and parsed. On a typical WordPress site with a page builder, this means 200KB to 400KB of CSS must transfer before the user sees a single pixel.

OptiWave’s proprietary Remote Cloud engine solves this by rendering your pages in a headless browser environment, extracting only the CSS rules that apply to above-the-fold elements, and compiling them into a compact critical stylesheet. This process runs entirely off your server, so your hosting resources stay untouched. The generated critical CSS typically weighs between 8KB and 25KB, compared to the 200KB+ full stylesheet bundle.

Combined with the media="print" swap technique for non-critical CSS, OptiWave delivers a complete solution: zero render-blocking CSS resources, instant first paint, and all styles fully available after initial load. Your Largest Contentful Paint (LCP) drops dramatically because the browser no longer waits for massive stylesheets before rendering content.

Setting Up OptiWave to Pass the PageSpeed Audit

Fixing the “Reduce unused JavaScript” warning with OptiWave takes under two minutes. After installing and activating the plugin, navigate to the OptiWave dashboard. The JavaScript optimization panel lets you set a global default strategy (defer is recommended as the baseline) and override individual scripts with idle or on-interaction as needed.

For CSS optimization, enable Critical CSS generation and the media print delivery method from the CSS panel. OptiWave’s cloud engine begins processing your pages automatically. Within minutes, every page on your site serves an inlined critical stylesheet with remaining CSS deferred through the print media swap.

The combination of intelligent JavaScript scheduling and async CSS delivery addresses both the “Reduce unused JavaScript” and “Eliminate render-blocking resources” warnings simultaneously. Sites running OptiWave consistently report 15 to 30 point improvements on mobile PageSpeed scores from these two optimizations alone.

Stop manually dequeuing scripts and hoping nothing breaks. Let OptiWave manage your script and stylesheet execution pipeline automatically. Explore OptiWave plans and start your 14-day free trial →

Frequently Asked Questions