UI Component Performance Benchmarks: Render Time, Bundle Size

Why UI Component Performance Actually Matters

Honestly, most developers pick a UI library based on aesthetics and docs quality — and then wonder six months later why their Lighthouse score is tanking. Performance is an afterthought until it isn't. Then it's a three-week refactor.

We ran a structured benchmark suite across five popular React UI libraries: Empire UI, shadcn/ui, Radix primitives, Material UI (MUI v6), and Ant Design v5. The goal was simple numbers. Initial render time. Time-to-interactive. Gzipped bundle contribution per component. No marketing, no vibes.

The testing environment was Node 22, React 19.1, Vite 6.2.1, running on a bare Ubuntu 24.04 VM with a fixed CPU frequency (4 cores, no turbo boost). Each component was measured across 500 render cycles, median taken. We used the React DevTools Profiler API and measured bundle sizes with rollup-plugin-visualizer v5.12.0.

If you're choosing a library for a production app — especially a SaaS dashboard or agency site — these numbers should inform your decision.

Test Setup and Methodology

Methodology matters. A lot of 'benchmarks' floating around are basically useless because they measure production vs development builds, or they test a Button while the other library tests a DataGrid. We kept it fair.

Each library was imported from its npm package at the latest stable version as of December 2026. Components tested: Button, Modal/Dialog, Dropdown/Select, Tooltip, and a 50-row Table. These five represent the most common real-world usage patterns.

Bundle size was measured by importing exactly one component per test and building with Vite 6.2.1 in production mode (mode: 'production', minify: 'esbuild'). We measured the gzipped output size of that single-component chunk. No tree-shaking heroics, just the default behavior you get when you run vite build.

For render time, we used performance.now() wrapping React's createRoot().render() call, flushed synchronously with flushSync. Numbers below are median over 500 runs, lower-quartile and upper-quartile noted where relevant.

Bundle Size Results: The Real Numbers

Here's what importing a single Button component costs you in gzipped kilobytes:

Empire UI came in at 4.2 kB gzipped for its Button — that's the component plus the Tailwind class references, which get purged aggressively. shadcn/ui clocked 3.8 kB (it's basically just Radix + styles, so no surprise). Radix's raw @radix-ui/react-primitive landed at 2.1 kB but you're wiring up styles yourself. MUI's Button? 22.6 kB gzipped — that pulls in the entire emotion runtime. Ant Design was the heaviest single-component import at 31.4 kB gzipped.

Modal/Dialog told a more dramatic story. Empire UI's Modal: 6.7 kB. shadcn Dialog: 5.9 kB. Radix Dialog alone: 4.4 kB. MUI Dialog: 38.2 kB (emotion styles, icon dependencies, Portal). Ant Design Modal: 44.1 kB. If you're building something where initial load matters — think Next.js or Astro static sites — that delta compounds fast.

The 50-row Table component gap was staggering. Empire UI's table (using native HTML table + Tailwind): 8.3 kB. MUI DataGrid (basic variant): 187 kB gzipped. Ant Design Table: 142 kB gzipped. That's not a criticism of MUI or Ant — those are feature-rich virtualized grids. But if you need a display table, you're paying a steep tax.

Render Time Benchmarks Across Components

Bundle size is about network. Render time is about runtime. Both matter, and they're not always correlated.

Button render time (median, 500 runs): Empire UI 0.31ms, shadcn/ui 0.29ms, Radix primitive 0.18ms, MUI 1.14ms, Ant Design 1.38ms. The Radix number makes sense — it's near-zero abstraction. MUI and Ant pay the emotion/CSS-in-JS runtime cost on every mount. That 1ms might sound trivial, but render 200 buttons on a settings page and you're looking at 228ms of avoidable work.

Modal open time (from trigger click to first paint of overlay, measured with PerformanceObserver and paint entry): Empire UI 4.1ms, shadcn 3.8ms, Radix 3.2ms, MUI 11.7ms, Ant Design 14.3ms. The pattern holds. CSS-in-JS runtime cost hits hardest on dynamic component mount, not on static renders.

One thing worth noting: Empire UI uses Tailwind v4.0.2 with the new Lightning CSS engine under the hood. That's not marketing copy — it's the reason the style resolution time at runtime is essentially zero. The classes exist in a static sheet. No runtime style injection, no hash computation, no style tag insertion.

How to Measure Your Own Components

Don't trust benchmarks you can't reproduce. Here's the exact snippet we used to measure component render time in isolation:

import { flushSync } from 'react-dom';
import { createRoot } from 'react-dom/client';
import { Button } from '@empire-ui/core'; // swap for any library

const container = document.createElement('div');
document.body.appendChild(container);
const root = createRoot(container);

const times: number[] = [];

for (let i = 0; i < 500; i++) {
  const start = performance.now();
  flushSync(() => {
    root.render(<Button variant="primary">Click me</Button>);
  });
  times.push(performance.now() - start);
}

times.sort((a, b) => a - b);
const median = times[Math.floor(times.length / 2)];
console.log(`Median render time: ${median.toFixed(3)}ms`);

Run this in a Vite dev server (vite serve) with React DevTools disabled and browser extensions off. DevTools alone can add 0.4–0.8ms per render. Extensions can add more. Clean environment is non-negotiable for meaningful numbers.

For bundle analysis, add rollup-plugin-visualizer to your vite.config.ts: import { visualizer } from 'rollup-plugin-visualizer' and push it into plugins. Build once, open stats.html. You'll immediately see which dependency is ballooning your bundle. Combine with bundlesize in CI to catch regressions — we recommend a hard limit of 10 kB gzipped per route-level chunk for most SaaS apps.

Tree Shaking and Import Strategies That Actually Help

Are you importing the whole library or just what you need? It sounds obvious, but the difference can be dramatic. import { Button } from 'antd' vs import Button from 'antd/es/button' used to matter a lot. Modern bundlers handle this better, but not perfectly.

With Empire UI and shadcn/ui, every component is its own file. There's no barrel index.ts re-exporting everything into one blob. That means Vite's tree-shaking works as intended. With MUI v6 and Ant Design v5, you need named imports from the main package and trust the bundler — or use their explicit sub-path imports. Check your vite build --report output. If you see a 200 kB chunk with just a Button in it, something's wrong with your import path.

One pattern that helps regardless of library: dynamic imports for heavy modal-type components. A dialog that opens on user action doesn't need to be in your initial bundle. const Modal = React.lazy(() => import('./Modal')) with a Suspense boundary knocks a meaningful chunk off your FCP score. This applies to any UI library you're using.

Also worth reading if you're evaluating the full stack: pnpm vs npm vs yarn — your package manager affects install time and can impact how well hoisting works with some UI library peer dependencies.

When Heavier Libraries Are Worth It

Here's the thing: MUI and Ant Design's bundle sizes aren't a mistake. They're a tradeoff. You get accessibility baked in, RTL support, virtualized data tables, date pickers with localization, complex form validation integration. If you need all that on day one, the 30–40 kB overhead per component is a reasonable price.

The benchmark numbers above apply to greenfield apps where you're choosing a library from scratch. They apply to agency sites where page speed is directly tied to conversion. They apply to apps targeting low-end devices or slow mobile connections.

If you're building an internal enterprise tool used by 200 employees on gigabit fiber, the difference between 4 kB and 44 kB probably won't show up in any metric you care about. That's fine. Engineering is about tradeoffs, not chasing the smallest possible number.

Empire UI hits a specific niche: 40 visual styles, Tailwind-first, genuinely small bundle. It's not trying to be a DataGrid framework. If you need what it does, it does it fast. If you need a full enterprise data platform, look at AG Grid or TanStack Table with whatever styling layer you want.

What the Numbers Don't Tell You

Render time and bundle size are real factors. They're not the only factors. What don't these benchmarks cover?

Accessibility compliance. Animation quality. Component API ergonomics. TypeScript type inference quality. Community size and issue response time. Long-term maintenance velocity. How well the library integrates with your existing glassmorphism or custom design system. These things matter enormously in a production codebase maintained by a team over two or three years.

We'd strongly recommend building a small prototype with your top two library candidates before committing. Render a realistic page — not a demo — with real data shapes, real interaction patterns, and real theme constraints. Run Lighthouse on it. Check your bundle analyzer. Then decide.

Performance benchmarks are a starting point for narrowing the field. They're not a substitute for judgment. The fastest component library that doesn't integrate with your design system is slower than the slightly heavier one that does — because you'll spend weeks fighting it instead of shipping features.

FAQ

Read next