Should you really abandon complete unbundling of your JavaScript files?

Why does Google warn against total unbundling?

The current trend pushes some developers to cut their JavaScript bundles into hundreds of small files, thinking they are optimizing cache and reducing the size of transmitted resources. The reasoning seems logical: if a file changes, only that one will be re-downloaded.

However, browsers impose a strict limit on simultaneous HTTP connections per host — usually 6 to 8 depending on versions. Multiplying files creates a bottleneck: each request has to wait for a connection to free up, exponentially increasing the overall loading time.

What’s the difference between complete unbundling and route-based code splitting?

Route-based code splitting involves breaking down JavaScript according to user journeys: one bundle for the homepage, another for product pages, etc. This approach limits the number of files loaded on each navigation while maintaining reasonable granularity.

Complete unbundling, on the other hand, goes as far as separating each module or component into its own file. On a modern site, this can represent several hundred HTTP requests for a single page — even with HTTP/2, latency accumulates.

What concrete impact does this have on Google crawling and indexing?

Googlebot does not have infinite patience. A loading process that drags on due to hundreds of requests can slow down rendering and delay the indexing of content generated in JavaScript. Worse, if execution time exceeds internal timeouts, Googlebot may index an incomplete version.

Martin Splitt has emphasized this point for years: JavaScript performance directly impacts SEO. An optimized bundle loads faster, executes faster, and allows Google to understand content without friction.

• HTTP connection limit: 6-8 simultaneous connections per domain depending on browsers
• Recommended code splitting: Split by route or major functionality, not by individual module
• SEO impact: A loading time that is too slow slows down rendering and may compromise JS content indexing
• HTTP/2 does not solve everything: Even with multiplexing, network latency accumulates over hundreds of requests
• Cache vs. performance: Excessive unbundling optimizes cache at the expense of initial loading time

Is this recommendation consistent with on-the-ground observations?

Yes, and it’s one of the few points where Google and technical reality align perfectly. In audits of sites using aggressive unbundling (poorly configured modern frameworks), we regularly observe waterfalls of 200+ requests to load a single page. FCP spikes, LCP too, and Core Web Vitals plummet.

Teams that switched to route-based code splitting have seen their performance metrics jump by 30 to 50% on average. The gains are measurable, reproducible, and directly correlated to rankings in SERPs for competitive queries.

What nuances should be considered depending on the technical context?

With HTTP/2 and HTTP/3, multiplexing theoretically allows for the parallelization of requests without blocking connections. But network latency remains unavoidable: each additional file adds a round trip, and on mobile or slow connections, it can be quite costly.

Modern CDNs offer automatic bundling on the fly (like Cloudflare Zaraz or edge computing solutions) that can mitigate the problem. But this adds a layer of complexity — and isn’t always compatible with all frameworks. [To be verified] depending on your tech stack.

In what cases can more granularity be considered?

If you have an application site with distinctly different sections used by different user segments (e.g., admin vs. public front), finer splitting may be justified. The key is never to exceed 15-20 JavaScript files per page — beyond that, you enter a danger zone.

Progressive Web Apps (PWAs) with aggressive service workers can also tolerate more splitting, since local cache avoids network requests after the first visit. But again, the first load remains critical for SEO.

What should you check in your current configuration?

Start by analyzing the number of JavaScript requests loaded above the fold. Open DevTools, go to the Network tab, filter on JS, and count. If you exceed 10-12 files on the homepage, you likely have a problem with excessive unbundling.

Next, look at the waterfall: are the files loading in parallel or in sequence? If you see series of 6-8 requests waiting, that’s the connection limit at play. Measure the time between the start of loading and the Last Chunk Received of the last critical JS file.

How to fix overly aggressive unbundling?

If you are using Webpack, Vite, or Rollup, review your splitChunks or manualChunks rules. The goal is to group stable third-party dependencies (vendor bundle) and split only by major application routes.

For a typical e-commerce site: one bundle for listing pages, one for product sheets, one for the conversion funnel. Not one file per React or Vue component. Test with Lighthouse or WebPageTest before/after to measure the real impact.

What mistakes to avoid in implementation?

Do not fall into the opposite excess: a monolithic 2 MB bundle is not the solution either. The balance lies between 5 and 15 JavaScript files for a standard page, with a total compressed size under 200-300 KB if possible.

Another pitfall: neglecting the preloading of critical bundles. If you split by route, make sure the browser knows the priority resources in advance through <link rel="preload"> or resource hints. Otherwise, you add unnecessary latency.

• Audit the number of JS requests per page (goal: < 15 files)
• Analyze the network waterfall to detect bottlenecks of simultaneous connections
• Configure the bundler to group stable dependencies (vendor bundle)
• Split only by route or major functionality, never by individual component
• Implement preloading of critical bundles to reduce latency
• Test before/after with Lighthouse and measure FCP, LCP, TBT