BrowserDevTools

Bundle budget analyzer

Point it at a build output folder and get the numbers that decide whether the site is fast: real gzip per chunk, what the first paint actually downloads versus what loads lazily, the largest assets, and an explicit verdict against the budgets you set. Nothing is uploaded — the folder is read and compressed in this tab.

Build output

Drop a dist folder here, or

The folder is read and gzipped in this tab — a dist folder is private code, so nothing is uploaded.

No build output yet — drop a dist folder or load the sample.

Your dist folder is parsed and compressed locally. That matters here more than usual: build output is minified private code, and the analyzers people usually reach for want it uploaded.

Load the sample build output, or drop your own dist folder, to see the report.

A budget tool that does not want your build

Bundle analyzers are one of the few tool categories where almost every option asks you to upload the thing you are analysing. That is a strange requirement for build output: it is the compiled, minified, source-mapped version of your private code, and a dist folder is often hundreds of megabytes. This page does the reading locally instead — the folder is parsed with the File API and each file is gzipped in the tab with `CompressionStream`, which is the same algorithm a server sends.

Three decisions shape what the tool reports:

Two honest notes about the numbers. Source maps are reported separately because visitors never download them unless devtools asks — they are huge and would otherwise dominate every “largest file” list. And your server may prefer Brotli, which is typically 15–20% smaller than the gzip shown here; if your host enables it, the real transfer is smaller than this report. What the report will not tell you is why a chunk is big — for that you still need a source-level visualiser, but you no longer need to hand your build to someone else’s server to find out which chunk to look at.

FAQ

Is my build uploaded?
No. The folder is read with the File API and compressed with CompressionStream inside your browser tab; there is no backend endpoint for the files and no share link. For a dist folder — minified private code with source maps — that is the point of using this instead of an online analyzer.
What is the difference between entry and lazy?
Entry chunks are what a visitor downloads before the page becomes interactive, including the vendor chunks imported by the entry. Lazy chunks only arrive when their route or component is used, so they affect navigation rather than first paint. The split comes from your .vite/manifest.json, which Vite writes when build.manifest is enabled.
Why does it need manifest.json?
Without it the sizes still work but the entry-versus-lazy classification cannot: the manifest is what records which output file is an entry and which is a dynamic entry. If it is missing, the report says so and falls back to classifying by file extension, which cannot tell a vendor chunk from a route chunk.
Is the gzip number real?
Yes — each text asset is actually compressed with gzip (level set by the browser) and the byte length is used. It is not an estimate from a table. Fonts, images and other pre-compressed files are excluded from that step, and the notes say so, because re-compressing them would report a smaller number than your server would send.
What budgets should I set?
Whatever your own performance budget says. A common starting point for a content site is 40 KB gzip per chunk and 200 KB of JavaScript in total, which is what this site holds itself to; the defaults here use exactly those numbers so the tool is useful before you configure anything. The point is the verdict, not the numbers.