๐Ÿค–NEW:AI-Powered Incremental Builds โ€” your site updates in under 30 seconds. See what's new โ†’
Performance Audit ยท SSRF Protected

JavaScript Bundle Analyzer & Auditor

Inspect total JavaScript footprint, detect heavy third-party vendor libraries, and diagnose main-thread execution overhead impacting Core Web Vitals INP.

โ„น๏ธ Important โ€” how sizes are calculated: This scan reads your page's raw HTML and identifies <script> tags, but it does not download external script files to measure their real size. Known libraries (jQuery, React, Vue, and 7 others) get their typical published weight. Any other external script โ€” including your site's own main bundle, if it isn't one of those known libraries โ€” is assigned a flat 35KB placeholder regardless of its actual size, and is labeled "(unmeasured, placeholder)" in the breakdown below. Inline script blocks ARE measured accurately from their real character count. Treat the total footprint and INP risk rating as a rough starting signal, not a precise measurement โ€” for exact transferred sizes, use your browser's DevTools Network tab.

Understanding JavaScript Weight and Its Impact on Interactivity

1. Why JavaScript weight matters more than other asset types

An image or a stylesheet, once downloaded, mostly just sits there being displayed โ€” but JavaScript has to be parsed, compiled, and executed by the browser's single main thread before it does anything, and that execution directly competes with the thread's ability to respond to user input. This is why a 500KB image and 500KB of JavaScript have very different real-world performance costs: the image mostly affects load time, while the JavaScript can make the page feel frozen or unresponsive even after it has visually finished loading.

2. Parse/compile time vs. download time

Mobile devices, particularly mid-range and budget Android phones which make up a large share of global web traffic, have meaningfully slower CPUs than the desktop or high-end phone most developers test on โ€” the same JavaScript bundle can take 3-5x longer to parse and execute on a budget device than on a developer's laptop. This is why Google's Core Web Vitals guidance emphasizes testing on representative mobile hardware (or using CPU throttling in DevTools) rather than judging JavaScript performance from a fast development machine alone.

3. Common sources of JS bloat on WordPress

Page builder plugins (Elementor, Divi, WPBakery) often load their full JavaScript runtime on every page regardless of whether that page uses builder-specific widgets. Multiple slider or carousel plugins loaded simultaneously duplicate similar functionality. Old jQuery plugin dependencies persist long after the visual feature they powered was removed from the page. Marketing and analytics tags accumulate over time as different team members add tracking without anyone owning the removal of unused ones. Each of these is individually small but compounds into a meaningfully bloated bundle over a site's lifetime.

4. Practical reduction strategies

Audit and remove plugins that duplicate functionality (two carousel plugins doing the same job). Replace jQuery-dependent plugins with modern vanilla-JS or CSS-only equivalents where possible โ€” jQuery itself is often unnecessary in current WordPress since core no longer requires it for most functionality. Defer or delay non-critical third-party scripts (analytics, chat, ads) so they load after the page becomes interactive rather than competing with initial render. For custom-built themes, use code-splitting so JavaScript only loads for the specific page sections that need it, rather than one monolithic bundle shipped everywhere.

5. Getting a precise, byte-accurate audit

This tool's fast HTML-scan approach is a useful starting signal, but for a byte-accurate, comprehensive audit, use your browser's DevTools: open the Network tab, filter to JS, reload the page, and sort by size โ€” this shows the exact transferred (compressed) and decoded sizes for every script your browser actually downloaded and executed, including those loaded dynamically after the initial page load, which this tool's static HTML scan cannot see at all.

Frequently Asked Questions

How does JavaScript bundle size affect Interaction to Next Paint (INP)?

JavaScript must be parsed, compiled, and executed on the browser main thread before event listeners can fire. Heavy JavaScript payloads monopolize the thread, causing high Total Blocking Time (TBT) and input latency delays that degrade your Google INP score.

What is considered a healthy total JavaScript weight for WordPress?

For optimal Core Web Vitals, aim for under 300 KB of total compressed JavaScript on initial page load. Sites exceeding 700 KB frequently suffer from mobile UI stutter and sluggish interaction responsiveness.

How can I reduce JavaScript bundle size on WordPress sites?

Common remedies include removing unused plugins, swapping heavy libraries (like replacing Moment.js with date-fns or native Intl), delaying non-critical third-party trackers with defer/async, and implementing conditional script dequeueing on pages where specific plugins are not needed.

Is this scan safe against internal network IP attacks (SSRF)?

Yes. All URL requests pass through an SSRF verification layer that strictly blocks private IP addresses (10.x, 192.168.x, 172.16-31.x), loopback (127.0.0.1, localhost), and cloud metadata endpoints.

Are the KB sizes shown for every script actually measured?

Only partially. Inline script blocks are measured accurately from their real character count. External scripts matching one of 9 well-known libraries (jQuery, React, Vue, and others) use that library's typical published weight. Any other external script โ€” including your own theme or plugin bundles that aren't on the known-library list โ€” is assigned a flat 35KB placeholder and marked "(unmeasured, placeholder)" in the results, since this scan does not download and measure external files directly. Use browser DevTools' Network tab for exact transferred sizes.

Why doesn't this tool just download every external script to measure its real size?

Downloading every external file would make the scan noticeably slower and would need to account for compression, caching headers, and CDN redirects to report an accurate "transferred" size โ€” closer to what a full page-load waterfall tool does. This tool is designed as a fast, first-pass signal: which known heavy libraries are present, and roughly how many external vs. inline scripts exist. For a precise byte-for-byte bundle audit, pair this with your browser's DevTools Network tab or a dedicated tool like WebPageTest.

What should I do if my site's main bundle shows as an "unmeasured, placeholder" entry?

That means the scan couldn't match it against a known library signature โ€” which is expected for custom theme or plugin JavaScript bundles built specifically for your site. Open your browser's DevTools, go to the Network tab, filter by JS, and reload the page to see the real transferred size of every script including that one. This is also the most reliable way to identify exactly which bundle is contributing the most weight when the INP Risk rating here is elevated.