{"slug": "optimizing-vite-build-output-a-practical-guide-to-tree-shaking", "title": "Optimizing Vite Build Output: A Practical Guide to Tree-Shaking", "summary": "This article explains how to optimize Vite build output through effective tree-shaking, which is the elimination of unused code from ES modules. The author describes common mistakes like using namespace imports (`import * as`) and passing namespace objects to functions, which prevent the bundler from identifying and removing dead code. The key solutions include using precise named imports, avoiding ambiguous signals to the bundler, and implementing lazy-loading for different pages to reduce initial bundle size.", "body_md": "I used to think bundle optimisation was someone else's problem. I'd write code using convenient namespace imports like import * as utils from './utils'\n, run npm run build\n, and ship whatever came out. My bundles kept growing: 200KB, 300KB, 450KB, but I assured myself it was fine. After all, browsers were getting better, internet connections were faster, and devices were becoming more powerful.\nThen I tested my 450KB utility library on a 3G connection. Four seconds to download. Lighthouse gave me an embarrassing performance score. That's when I learned I was shipping 60% unused code.\nThis article covers what I discovered about tree-shaking in Vite, the mistakes I was making, and how I fixed them.\nTree-shaking is dead code elimination for ES modules. When you use import and export, you create a static dependency graph. Vite (via Rolldown) traces through this graph and removes exports that aren't being consumed. Basically, tree-shaking only works when the bundler can prove code is unused. If you give it ambiguous signals, it keeps everything safe.\nTake a utility component called dashboard.utils.ts as a real example. It exports eight standalone functions: hasActiveFilters\n, mapApplicationToTableData\n, resetPagination\n, updateFilterState\n, updatePagination\n, mapJobStats\n, normalizeFilter\n, and buildPagination\n. I only needed one, but here's how I used to import it\nVite can statically analyse and determine that only resetPagination\nis accessed here, and drop the rest, but that's the bundler doing you a favour, not you writing intentional code. You've imported the entire module and handed the cleanup responsibility to your build tool. It works until it doesn't.\nAnd it stops working the moment you do something like this:\nOnce the namespace object is passed to console.log\nor spread into another structure, the bundler can no longer prove at build time which properties will be accessed at runtime. It has no choice but to keep all eight exports: hasActiveFilters\n, mapJobStats\n, buildPagination\n, and everything else, just in case.\nThis is a trap because the first version looks harmless. It gets past your linter, the build succeeds, and you move on. Then three weeks later, someone adds a debug log, passes the namespace to a utility, and suddenly your bundle is carrying dead weight you didn't notice.\nEight dashboard utility functions imported. One actually used. Seven along for the ride on every page load.\nThis provides a clear signal to the bundler: only resetPagination\nis needed. mapJobStats\n, buildPagination\n, normalizeFilter\n, and the rest can be safely removed from the final output.\nSwitching from namespace imports and over-importing to precise named imports was the single biggest improvement.\nI noticed /* @\\_\\_PURE\\_\\_ */\ncomments in my build output. These tell the minifier a function call has no side effects, meaning if the return value is never used, the entire call can be safely removed.\nIn the snipper above, both resetPagination\nand buildPagination\njust take input, compute a value, and return it. No HTTP calls, no mutations, no DOM access. They have zero side effects. That's exactly what Vite looks for when deciding whether to annotate a call as pure:\nImagine your project grows and you have a helpers/\ndirectory with multiple utility files, date.helper.ts\n, dashboard.utils.ts\n, and others. The temptation is to import them all eagerly:\nEvery page component, all its dependencies, and all its templates are now bundled together and loaded on the first request, regardless of which page the user is actually visiting.\nInstead, lazy-load each page so that it becomes its own separate chunk:\nA user who only visits the dashboard never downloads the profile management or jobs page. The router calls loadPage('dashboard')\non navigation, and everything else stays unloaded until it's needed.\n1. Named imports only\nNo import * as\nunless necessary.\n2. Don't pass namespace objects to functions\nLog specific properties, not the whole namespace.\n3. Dynamic imports for optional features\nIf it's not needed for the initial render, lazy-load it.\n4. Review dependencies\nReplace non-tree-shakable libraries when possible.\nVite's tree-shaking is powerful, but it only works with your cooperation. Write code that gives the bundler clear signals about what's actually used.\nCheck your bundle. You might be shipping more dead code than you think.", "url": "https://wpnews.pro/news/optimizing-vite-build-output-a-practical-guide-to-tree-shaking", "canonical_source": "https://dev.to/avwerosuoghene/optimizing-vite-build-output-a-practical-guide-to-tree-shaking-1fm", "published_at": "2026-05-22 17:53:18+00:00", "updated_at": "2026-05-22 18:03:44.815540+00:00", "lang": "en", "topics": ["developer-tools"], "entities": ["Vite", "Rolldown", "Lighthouse"], "alternates": {"html": "https://wpnews.pro/news/optimizing-vite-build-output-a-practical-guide-to-tree-shaking", "markdown": "https://wpnews.pro/news/optimizing-vite-build-output-a-practical-guide-to-tree-shaking.md", "text": "https://wpnews.pro/news/optimizing-vite-build-output-a-practical-guide-to-tree-shaking.txt", "jsonld": "https://wpnews.pro/news/optimizing-vite-build-output-a-practical-guide-to-tree-shaking.jsonld"}}