Vite build chunk-size warning after minification: which remediation fits a large vendor chunk?

Short answer: measure first, then split by usage pattern, not by size. Use dynamic import() when the heavy code is not needed for first render; use manualChunks only to separate code with a genuinely different cache lifetime; replace the dependency when one library dominates; and raise chunkSizeWarningLimit only as a documented, monitored exception. The warning itself is a heuristic, not a diagnosis.

1. Criteria for dynamic import vs. manualChunks

Once a Rollup-compatible visualizer (run against the production build, not the dev server) shows which dependencies dominate, decide on these measurable axes:

• Startup necessity. What percentage of sessions need this code before first paint? If a charting or editor library only loads on one route or after a user interaction, dynamic import() at that boundary removes it from the critical path entirely. This is the strongest lever because it reduces bytes parsed at startup, not just bytes per file.
• Cache cadence. If the chunk mixes your fast-changing application code with a stable vendor library, a manualChunks split lets the vendor part survive deploys unchanged. If everything invalidates together anyway, the split only adds a request.
• Compressed size and timing. Compare minified and gzip/brotli sizes, request count, and route-load or LCP timings between a baseline build and each candidate split. A split that shrinks the warning chunk but leaves total compressed bytes and LCP unchanged is cosmetic.
• Waterfall risk. A dynamic import on the critical path (e.g., awaited during hydration) can regress perceived performance. Verify the deferral is genuinely off the startup path.

If one dependency dominates and has a lighter alternative or supports subpath imports, replacing or narrowing it often beats both splitting strategies, because it removes cost instead of redistributing it.

2. Confirming a manualChunks split preserved execution order

There is no documented Vite switch that proves order preservation — this is an honest gap. Validation is indirect:

• Keep side-effectful modules (polyfills, global CSS, initialization code) out of ad hoc chunk functions; split only self-contained library groups.
• Inspect the emitted chunks' import statements for cycles between your manual chunks. Circular chunk dependencies are the classic cause of "works in dev, undefined at runtime in prod" bugs.
• Run smoke or e2e tests against the built assets (vite preview or a staging deploy), exercising startup and every route touched by the split.

If your split function starts needing special cases to avoid cycles, that is a signal the split is fighting the module graph and dynamic imports are the better tool.

3. When raising the limit is legitimate

Raising build.chunkSizeWarningLimit is reasonable when composition is already understood and the size is an accepted, tracked decision — for example, a required monolithic SDK with no lighter alternative, or a legacy bundle scheduled for replacement. Make the exception visible: document the accepted byte budget and add CI bundle-size tracking so regression still trips an alarm. It is hiding the problem when it is the first response, before anyone has looked at what is in the chunk.

Version caveat

The 500 kB default and plugin behavior are version-sensitive; confirm the threshold against the Vite major you actually run before treating any number as universal. Likewise, visualizer output describes only the build you analyzed — re-check after dependency upgrades.