Slow initial load & refresh in dev mode after migrating from Webpack

[buondevid]

Hello,

We recently migrated our project from Webpack to Vite and noticed a significant slowdown in the DX. Specifically, the initial load or a full page refresh takes about 2–4 seconds.

This isn’t about HMR (which works fine) — the issue is with the very first load or when refreshing the app. In our workflow, we often need to refresh the page to re-run queries, and waiting several seconds each time is disruptive.

With Webpack, only the modules for the current view were loaded. In Vite, it seems the entire codebase is loaded in dev, which makes page navigation snappy but makes refreshes quite slow for us (we end up loading ~40MB of JS). To be clear, this doesn't happen in production where only the files needed for the view are loaded.

I’m wondering if there are solutions or ongoing work in this area. I came across related discussions:

• Page reload very slow, unbundle DX for large web app is not satisfactory #13697
• How to optimize large projects with dynamic imports and code splitting in ViteJS? #17730

From what I understand, one workaround is to switch to dynamic imports for all components, e.g.:

const MyComponent = () => import('./components/MyComponent');

But that feels like a cumbersome change just for improving dev-time reloads.

Is there any recommended approach, or possibly a config/setting planned that could address this?

Thanks in advance!

---

EDIT: Some correction to what I wrote: after some investigation, it looks like it's loaded everything in prod too, but since it's bundled together and super minified and compressed, it does in half second rather than 4. Then I'm not sure how Webpack was solving this problem for the dev server but it was a better experience.

[nicholas-greenwood]

i'd start with the route imports, since you found that production loads everything too

if they're all coming through something like pages/index.ts, that can pull in every page even when you only import 1 of them. try a direct import and see how much disappears from the network tab

then i'd lazy-load the routes, rather than each component. for react, with a default export:

import { lazy, Suspense } from "react"

const Reports = lazy(() => import("./pages/Reports"))

function ReportsRoute() {
  return (
    <Suspense fallback={<div>loading...</div>}>
      <Reports />
    </Suspense>
  )
}

the () => import(...) in your example needs to go into lazy, rather than being the component itself. your router may have its own way to do this too

also check that devtools' "disable cache" is unchecked when comparing refreshes. if it's still slow, vite --debug plugin-transform will help find expensive transforms

server.warmup can speed up transforms, but won't stop the browser loading those modules

can you share how your routes are imported? that should help narrow down where the 40mb is coming from

vite's performance guide, react's lazy reference

[mujtbabbas]

This is the classic Webpack→Vite difference, and HMR being fast is the clue: in dev, Vite serves your app as unbundled ES modules, so on first load (and every full refresh) the browser has to fetch your entire eagerly-imported module graph before first paint. Webpack was bundling — and in your case evidently code-splitting — so a refresh felt instant by comparison. HMR only swaps the changed modules, which is why it feels fine.

In rough order of impact:

1. Route-level code splitting (usually the big one). Make sure pages/views are lazily loaded — your router's lazy route feature or React.lazy + Suspense — instead of statically imported into the root component tree. If everything is imported eagerly at the top, the browser must download all ~40MB up front. With lazy routes, the initial load drops to the app shell plus the current route.
2. Kill barrel files on hot paths. index.ts files that re-export a whole folder pull the entire folder into the graph even when you import one thing. Import from the source file directly for the heavy modules.
3. Pre-bundle heavy CommonJS deps explicitly with optimizeDeps.include, so esbuild converts them once instead of per-request transformation — and check for duplicated copies of large libraries (charting, editors) in node_modules.
4. server.warmup.clientFiles for your entry files, so the first hit isn't also paying the transform cost.

Measure with the Network tab on a refresh: count the requests. Dev-mode Vite apps commonly load hundreds (or thousands) of module requests — the fixes above are about shrinking that graph, not about server speed. Your production build (Rollup) bundles everything, which is why this only shows up in dev.