Bundle Size & Optimization

How It Works

DaisyUI Kit ships a dedicated package for each framework (@daisyuikit/vue, @daisyuikit/react, @daisyuikit/svelte, etc.). Each package contains only the components for that framework, and modern bundlers tree-shake the JS automatically.

JS Tree-Shaking (All Frameworks)

If you import only Button and Card, the JS for Modal, Tabs, and every other component is excluded from your bundle. This works out of the box with any Vite-based framework — no configuration needed.

CSS: Tailwind Content Scanning

CSS doesn't tree-shake the same way JS does. Tailwind CSS scans your source files for class names and generates CSS only for the classes it finds. The @source directive in your CSS file tells Tailwind where to look:

@source "../node_modules/@daisyuikit/react";

Since DaisyUI Kit components use dynamic class bindings (conditionally applying btn-primary, btn-secondary, etc. based on props), Tailwind sees all possible class names in the component source files and includes them — even if your app only uses primary. This is standard Tailwind behavior and applies to all frameworks equally.

Optimization by Framework

Nuxt: The Best Experience

Nuxt provides the most optimized experience automatically:

• Auto-imports mean you don't manage imports at all
• Per-route CSS code-splitting — Nuxt tracks which components are used on each page and generates separate CSS chunks. Page A only loads CSS for Button and Card; page B only loads CSS for Modal and Tabs
• JS tree-shaking works as expected

No configuration required — install the module and go.

Vite-Based Frameworks (React, Svelte, Solid, Preact, Qwik, Vue without Nuxt)

These frameworks get excellent JS tree-shaking through Vite. CSS is bundled into a single file based on what Tailwind finds via @source.

For most apps, this is perfectly fine — DaisyUI v5's CSS is small to begin with.

Angular, Lit, Astro

Same story: JS tree-shaking works, CSS is determined by Tailwind's content scanning. Angular and Lit use the dui- custom element prefix, which means Tailwind scans the component source files the same way.

Reducing CSS Further with Granular @source

If you want to minimize CSS output, you can point @source at only the specific components you use instead of the entire package:

@source "../node_modules/@daisyuikit/react/src/Button.tsx";
@source "../node_modules/@daisyuikit/react/src/Card.tsx";
@source "../node_modules/@daisyuikit/react/src/Badge.tsx";

This way Tailwind only scans those files for class names, producing a smaller CSS output. With DaisyUI v5 at ~15KB gzipped total, the savings are marginal for most apps — but it's available if you need it.

DaisyUI also supports including and excluding parts of the library directly from the config.

How Much Does a Component Weigh?

Each component is lightweight. Here's a worst-case breakdown using the Text component, which has the highest number of utility classes (~70):

Most components are well under 2 KB gzipped. This is the same across all frameworks — the generated components are thin wrappers around shared class computation functions from @daisyuikit/core.

Why Components Over Manual Classes?

Using DaisyUI Kit components instead of manually specifying Tailwind classes on every element:

• Consistency — components encapsulate best-practice class combinations, preventing style drift
• Maintainability — update one component, changes propagate everywhere
• Prop-driven API — declarative props like primary, lg, outline instead of remembering class names
• TypeScript support — full autocompletion and type checking for every prop in every framework
• Same API everywhere — Button, Card, and Modal work identically across Vue, React, Svelte, and all other supported frameworks

The tradeoff is that dynamic class bindings cause Tailwind to include all referenced classes, slightly increasing CSS size compared to static classes. For most apps, the productivity gains far outweigh this small cost.

Summary