Ever wondered how much JavaScript the typical Next.js application really ships to users? We at Catch Metrics were curious too. So, we embarked on a massive crawl of 300,000 production domains built with Next.js. Our goal? To get a clear, data-backed picture of JavaScript bundle sizes in the wild — from sleek landing pages to intricate SaaS dashboards. The results? Too insightful to keep locked away in a spreadsheet.

Get ready to explore the fascinating, and sometimes startling, world of Next.js bundle sizes.

Key Findings and Observations

The Wide World of Bundle Sizes: A Look at the First 90%

We sliced our data into deciles, where each decile represents 10% of the 270,000 "lighter" sites. Here's what we found:

• Decile 1 (the lightest sites): Median bundles start at around 350 kB - reasonably optimized.
• Decile 5 (halfway point): Bundles already cross the significant 1 MB mark.
• Decile 9: Median sizes exceed 3 MB.

The visual trend is clear: as bundle sizes grow, volatility increases. Notice how the boxes in the chart grow taller moving rightward, signaling wider variation (inter-quartile ranges) in bundle sizes. Between deciles 6 and 9, this middle 50% nearly doubles in size, underscoring that controlling bundle size becomes increasingly challenging as your site grows.

Venturing into the Heavyweights: The Worst 10%

Now, let's zoom in on that worst 10%: the applications with the largest JavaScript footprints. Prepare for some eye-opening numbers.

The 99th percentile, which still covers a significant 3,000 sites, is already pushing a median of approximately 17 MB. To put that in perspective, that's nearly 12 times heavier than the median site in the very first decile. In the most extreme case we encountered, a single-page application was attempting to load a jaw-dropping 56 MB of JavaScript. To put that into perspective that means that the bundle contains 2 to 4 million lines of code, depending on line length. Frankly, these figures left us stunned.

Two key observations stand out in this heavyweight category:

• Runaway Upper Tail: The median bundle size absolutely balloons, showcasing an extreme upper range.
• Volatility Spikes: The variability within these large bundles is immense. The inter-quartile range in the 99th percentile expands from about 3 MB to over 10 MB.

Beyond Megabytes: The Real-World Cost in Seconds

Bundle size in megabytes is one thing, but what does this mean for the actual user experience?

We calculated the end-to-end cost, the download and parse time on a typical mid-tier Android phone using a steady 4G network (75 Mbps).

Here’s a quick breakdown of our assumptions:

• Downloading 100 kB of JavaScript on this 4G connection takes about 11 ms.
• Parsing that same 100 kB on a high-end phone takes roughly 25 ms.
• Since a mid-tier phone is about four times slower at parsing, it takes approximately 100 ms for that 100 kB.
• Combining these gives us our end-to-end cost.

Impact Across the First 90%

When we plot this time cost, a familiar pattern emerges: a steady, concerning climb.

Two patterns are particularly striking:

• Non-Linear Growth: The median delay approximately doubles every two to three deciles.
• Widening Spread: As bundles grow past the 1 MB mark, the Interquartile Range (IQR) also fattens. This suggests that individual library choices and how rigorously code-splitting is applied become dominant factors in performance.

Shockingly, half the sites in the ninth decile already make users wait more than 3 seconds just for their JavaScript to download and parse, even before Next.js can begin to hydrate the page and make it interactive.

Impact Within the Worst 10%

Zooming into the heaviest cohort, the scale of these delays becomes almost unreal.

For the heaviest bundles, the scale is astonishing:

• Median delay at 99th percentile: around 16 seconds
• Upper extreme: some sites hit up to 45 seconds of delay.
• Even the 97th percentileexperiences delays over 7 seconds.

These aren't just minor slowdowns; they indicate serious underlying issues.

The Biggest Bundle on the Web

This picture truly is worth a thousand words and begs the question: Why is this happening?

Why Bundle Size Matters: A Brief Primer

A JavaScript "bundle" is a compressed package of files your build tool creates for web browsers. Its size directly influences:

• Download time: Larger bundles slow down network transfers.
• Parsing and compiling time: Browsers need extra processing to make JavaScript usable, causing noticeable delays, particularly on slower devices.

If either of these stages takes too long, users are left waiting for the page to become interactive, even if the basic HTML structure has already appeared. On devices with limited resources, there's even a third bottleneck: memory pressure while the JavaScript is running.

User Experience Consequences

Large bundles directly impact users in several critical ways:

• Network-dependent delays: On slow or congested mobile networks, downloading a 5 MB bundle can easily introduce an additional 7 to 10 seconds of waiting.
• Slower CPUs, especially common in mid or low-end Android phones and older iPhones (like the iPhone 6 or the first-gen SE), struggle with parsing and compiling large JavaScript files. Since JavaScript parsing and compilation are often CPU-intensive tasks that heavily rely on single-thread performance, these devices, which typically have weaker single-core speeds, are disproportionately affected. Even 1 MB of JavaScript can take over 1 second to parse on these slower devices.
• UI unresponsiveness due to main thread overload: the page might look like it's loaded, but clicks and taps do nothing, creating a frustratingly unresponsive experience.

Ad revenue and SEO Impacts

The consequences of bloated bundles extend into tangible business metrics:

• Poor Core Web Vitals
• Slow initial load times due to massive bundles will negatively impact your Largest Contentful Paint (LCP) and First Contentful Paint (FCP) scores.
• Sluggish interactivity will harm your Interaction to Next Paint (INP) score.
• Even slow server-side rendering, potentially exacerbated by complex bundling, can hurt your Time to First Byte (TTFB) score.
• SEO Damage: These poor Core Web Vitals directly harm your site's SEO ranking. Google has made it clear that page experience is a ranking factor.
• Higher Bounce Rates: The data is stark – around 53% of mobile users will abandon a site that takes longer than 3 seconds to become usable. Source
• Increased Cloud Costs: You'll also likely see a bigger cloud bill, as you're footing the network fees for sending these larger bundles to every user.

In Conclusion: Bundle Size Matters, A Lot.

JavaScript bundle size isn't just a technical detail; it's a critical factor that has a direct correlation with:

• How quickly your page loads.
• How soon your page becomes interactive.
• Your Core Web Vitals, which in turn significantly affect your SEO ranking.
• Your operational costs for cloud services.
• And most importantly, whether your users stick around or leave in frustration.

Is your Next.js application performing optimally, or could bundle bloat be holding it back?

If you're concerned about your site's bundle sizes and want to ensure the best possible performance, reach out to us at Catch Metrics! We can help.