Vendor and dependency chunks separated from app code
Why it matters
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.
Severity rationale
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.
Remediation
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
},
}
DetectionPro
The detection method for this pattern is part of AuditBuffet Pro.
The full method (what to look for, pass and fail conditions, and how results get reported) ships inside the Performance Deep Dive Audit. The pattern definition, severity rationale, and remediation remain openly licensed under CC-BY-4.0.
External references
- iso-25010:2011 · time-behaviour — Time Behaviour (performance efficiency)
Taxons
History
- 2026-04-18·v1.0.0·Initial import from performance-deep-dive·automated