When vendor and application code share the same bundle, every code change — even a single-line fix — invalidates the cached bundle for all users. Separating vendor chunks means React, lodash, and other stable libraries stay cached across deploys. Only the small application chunk changes, so returning users download a few kilobytes rather than hundreds. ISO 25010:2011 time-behaviour captures the repeated re-download cost; unconfigured chunk splitting turns every deploy into a full cache miss for your entire user base.
Medium because mixed vendor/app chunks force users to re-download stable third-party code on every deploy, eliminating long-lived cache benefits and increasing bandwidth costs unnecessarily.
Next.js production builds automatically split vendor and framework code into separate chunks — verify this by checking that .next/static/chunks/ contains both framework-*.js and main-*.js files. For custom webpack setups, configure splitChunks explicitly.
// next.config.js custom webpack (if needed)
module.exports = {
webpack(config) {
config.optimization.splitChunks.cacheGroups.vendor = {
test: /[\\/]node_modules[\\/]/,
name: 'vendors',
chunks: 'all',
}
return config
},
}
ID: performance-deep-dive.bundle-analysis.vendor-chunks-split
Severity: medium
What to look for: Count the number of chunks in the production build output. Enumerate which chunks contain vendor code vs. application code vs. framework code. Examine the build configuration, specifically webpack's optimization.splitChunks or equivalent in other bundlers. Check the build output for separate chunks: typically a vendor.js, framework.js, and app.js. The framework core (React, Vue, etc.) should be in a separate chunk from application code.
Pass criteria: The build output contains at least 3 chunks: vendor code, framework code, and application code. Vendor and framework chunks are cached separately from app chunks, so app updates don't invalidate all caches.
Fail criteria: All code is bundled into a single chunk, or vendor code is mixed with application code such that any app change invalidates the entire bundle's cache.
Skip (N/A) when: Never — chunk splitting is a best practice for all production builds.
Cross-reference: For cache-busting strategy for these chunks, see the asset-content-hash check in Regression Prevention.
Detail on fail: "Single monolithic app.js bundle contains vendor, framework, and app code (2.1MB gzipped). No chunk splitting configured in webpack" or "Vendor chunk includes app code; vendor hash changes with every app update"
Remediation: Configure chunk splitting in your build tool to separate vendor and framework code from application code.
// next.config.js — chunk splitting is automatic in Next.js production builds
// For webpack: optimization: { splitChunks: { chunks: 'all', cacheGroups: { vendor: { test: /node_modules/ } } } }