Vite plugins, by scenario
There are thousands of Vite plugins, and “which is best” is the wrong question — the useful one is “which fits this job, and what does it cost”. Six scenarios, the plugins that are actually maintained, and the caveat that turns each one into a decision.
A Vite plugin is a build-time dependency with the same supply-chain weight as any other: it runs on every build, on every machine, in CI. So this page does not rank them. It groups them by the job you are trying to do, names the one or two that are maintained, and states the caveat that most articles leave out — because the caveat is usually the part that decides.
Everything below is a project you install into your own repository; the only thing this site hosts is the Vite tools it builds itself. None of these links is paid, and there is no affiliate arrangement behind any of them.
Scenario 01
PWA and offline
What you want: An installable app that still opens when the network does not.
| Package | What it does | Caveat |
|---|---|---|
| vite-plugin-pwa | Workbox under the hood: one config generates the web manifest and a service worker, with precaching and runtime caching strategies. | The plugin is easy; the caching strategy is not. A wrong runtime rule can serve stale HTML for days. Start with generateSW, and only move to injectManifest when you actually need custom routing. |
| @vite-pwa/assets-generator | Produces the whole icon set — including maskable icons — from one source image, at build time. | Generated icons still need looking at: check the 16 px favicon and the maskable safe zone, which is what our icon generator exists for. |
Our take: Add PWA support when you have a concrete offline requirement; a service worker you do not test is a caching bug waiting for a deploy.
Scenario 02
Image optimisation
What you want: Smaller images without hand-exporting every size.
| Package | What it does | Caveat |
|---|---|---|
| vite-imagetools | Import an image with query parameters (width, format, quality) and get the resized, re-encoded variants emitted at build time. | It depends on sharp, a native binary — CI images must be able to install it. And it only pays off if you actually ship <img srcset>; resizing without using the variants is pure build cost. |
| vite-plugin-image-optimizer | Runs sharp/svgo over the assets Vite already emitted, shaving bytes without changing your import code. | It runs on every build, so the win should be measured: our bundle analyzer reports the before/after size per asset. |
Our take: Image bytes usually dominate a page, so this is one of the few plugin categories where the trade-off is easy to justify — but measure, do not assume.
Scenario 03
SSR, SSG and prerendering
What you want: HTML that arrives rendered, for SEO or for first-paint speed.
| Package | What it does | Caveat |
|---|---|---|
| vike | A file-based SSR framework built on Vite (formerly vite-plugin-ssr): routing, data loading and server rendering, without adopting a full meta-framework. | SSR is an application architecture, not a checkbox: you now have a server, hydration mismatches and two environments to reason about. If you only need static HTML, reach for SSG instead. |
| vite-ssg | Prerenders your Vue app to static HTML at build time. | It prerenders the routes you enumerate. Anything dynamic still needs a server or a client-side fetch, which is exactly where a naive “we added SSG” claim falls apart. |
Our take: Decide which problem you have — search visibility or first paint — before picking between SSR and prerendering; they solve different halves of it.
Scenario 04
Bundle analysis
What you want: To see what is actually in the build.
| Package | What it does | Caveat |
|---|---|---|
| rollup-plugin-visualizer | Emits an interactive treemap of the bundle so you can see which module is responsible for a chunk. | It shows the graph, not a verdict: it will not tell you whether 220 KB of JavaScript is acceptable, and it wants your build output. For the budget question, our own analyzer reads the folder locally and compares it with limits you set. |
Our take: Use a visualiser to find the culprit, then a budget tool to decide whether it matters — and keep the budget numbers in the repository so they survive the next refactor.
Scenario 05
Developer experience
What you want: Less boilerplate in every component file.
| Package | What it does | Caveat |
|---|---|---|
| unplugin-vue-components | Auto-imports components on use, including resolver-driven UI kits, so you stop writing import lines. | Magic imports hide where a name comes from — which is fine for a design system you did not write, and less fine for your own components, where an explicit import is documentation. |
| unplugin-auto-import | Auto-imports APIs such as ref and computed, and writes the type declarations they need. | Commit the generated .d.ts, or your editor and CI will disagree about what exists. It also makes a missing import look like a runtime mystery instead of a compile error. |
Our take: These two are the most popular and the most reversible: adopt one, live with it for a sprint, and keep it only if the diff gets quieter.
Scenario 06
Legacy browsers and transfer size
What you want: Support an older browser, or pre-compress for the server.
| Package | What it does | Caveat |
|---|---|---|
| @vitejs/plugin-legacy | Emits an additional legacy bundle with the polyfills old browsers need, delivered through a nomodule fallback. | It roughly doubles the output and pulls in terser. Build for the browsers your analytics actually show — supporting IE-era browsers costs every modern visitor a little. |
| vite-plugin-compression | Pre-compresses assets to .gz or .br at build time, for hosts that serve the pre-compressed file directly. | Useless if your host compresses on the fly (Vercel and Netlify both do), and it multiplies the files in your deploy. Check what your platform already does before adding it. |
Our take: Both of these are answers to “can we afford it?” — so answer with data: the browsers in your analytics, and the transfer size from a real build.
Checking the result of a change
Every plugin above changes your config or your bundle, and our own Vite tools exist for exactly those two moments: they run in the browser, so you can use them on a build you have not pushed anywhere.
Vite Config Generator
Tick what your project needs and get a clean vite.config.ts — aliases, dev proxy with rewrite and ws, build target, manual chunks — plus the install command.
Code generation
Vite Config Checkup
Paste vite.config.ts and package.json: a plugin imported but never installed, a define value that is not stringified, an empty envPrefix, an es5 target — found before your build runs.
Code generation
Bundle Budget Analyzer
Drop your dist folder: per-chunk sizes, real gzip, entry vs lazy, and which chunk blows the budget — without uploading your build.
Code generation
Vite .env Validator
Check a Vite .env against .env.example: missing, extra and empty variables, duplicate keys, and secrets you accidentally exposed to the client.
Data & config
On links and money
There is no affiliate relationship behind any package named here, and no ranking was sold — this site is funded by display advertising and its /advertising page commits to exactly that. If a recommendation is wrong, the repository is the source of truth, and so is the package’s own changelog.
FAQ
- How do I tell whether a plugin is still maintained?
- Three signals: the date of its last release, whether it supports the current Vite major versions (peerDependencies is usually explicit), and whether it has an official counterpart. A plugin that has not been updated across two Vite majors is a liability, however many stars it has.
- Do all of these work together?
- In practice yes, but not necessarily in the order you install them: legacy and compression both touch the emitted files, image tools hook into asset handling, and the DX plugins rewrite imports. Add one at a time, look at the build output after each, and run the config checkup so a missing package.json entry cannot slip through.
- Where do I find plugins that are not listed here?
- The awesome-vite list is the community index, and npm search with the “vite-plugin” keyword works surprisingly well. Before installing anything, look at Vite’s own plugin API: a surprising share of “plugin” needs are fifteen lines in a config, and a local function has no supply chain.
- Which of these do you use on this site?
- This site is Astro plus Vue islands, so its plugin surface is small: the framework plugins and a static build. That is also why the tools here are framework-agnostic — they are for your build, not ours.
- Are the recommendations paid?
- No. There are no affiliate links and no sponsored placements on this page; the packages are named because they are the ones that come up in real projects. Check them yourself — a recommendation from a page like this one is a starting point, not a guarantee.
BrowserDevTools