Tailwind CSS v4 Performance — Lightning CSS and Build Optimization

In this tutorial, you will learn about Tailwind CSS v4 Performance. We cover key concepts, practical examples, and best practices to help you master this topic.

Tailwind CSS v4 uses the Lightning CSS engine (Rust-based) for dramatically faster parsing, transformation, and minification -- achieving 10-100x speed improvements over v3's PostCSS pipeline.

What You'll Learn

You will learn how Lightning CSS improves build performance, configure production builds for minimal output, use incremental compilation, and measure build speed improvements.

Why It Matters

Build speed directly impacts developer productivity. DodaTech's v4 Migration reduced build times from 8 seconds to 0.4 seconds, making HMR near-instant.

Real-World Use

DodaZIP's CI pipeline cut deployment time by 3 minutes per build after moving from v3 to v4, saving hours of developer time weekly.

flowchart LR
    A[Override Strategy] --> B[Performance]
    B --> C[Lightning CSS]
    B --> D[Build Times]
    B --> E[Incremental Builds]
    B --> F[Bundle Size]
    style B fill:#38bdf8,stroke:#0284c7,color:#fff
    style C fill:#22c55e,stroke:#16a34a,color:#fff

Lightning CSS vs PostCSS

# v3: PostCSS pipeline
# - JavaScript-based parsing
# - Multiple plugins (autoprefixer, etc.)
# - ~500-3000ms for medium projects

# v4: Lightning CSS pipeline
# - Rust-based parsing (10-100x faster)
# - Built-in vendor prefixing
# - Built-in minification
# - ~50-200ms for medium projects

// v3: vite.config.js with PostCSS
import { defineConfig } from 'vite'
import react from '@vitejs/plugin-react'
// Separate postcss.config.js needed

export default defineConfig({
  plugins: [react()],
  css: {
    postcss: './postcss.config.js',
  },
})

// v4: vite.config.js with Lightning CSS (native in Vite)
import { defineConfig } from 'vite'
import react from '@vitejs/plugin-react'
import tailwindcss from '@tailwindcss/vite'

export default defineConfig({
  plugins: [react(), tailwindcss()],
})

Expected output: v4 builds are significantly faster. Lightning CSS handles parsing, prefixing, and minification natively without separate PostCSS plugins.

Measuring Build Performance

# Measure v4 build time
time npx vite build

# Compare CSS bundle sizes
echo "Before minification:"
wc -c dist/assets/*.css

echo "After gzip:"
gzip -c dist/assets/*.css | wc -c

# Check build details
npx vite build --debug

Expected output: Build times measured in milliseconds, gzipped CSS typically under 5KB for medium projects.

Production Configuration

// vite.config.js -- production optimized
import { defineConfig } from 'vite'
import react from '@vitejs/plugin-react'
import tailwindcss from '@tailwindcss/vite'

export default defineConfig({
  plugins: [react(), tailwindcss()],
  build: {
    cssMinify: 'lightningcss', // Lightning CSS minifier (default in v4)
    minify: 'esbuild',
    rollupOptions: {
      output: {
        manualChunks: undefined, // Let Vite handle chunking
      },
    },
  },
  css: {
    lightningcss: {
      // Lightning CSS specific options
      drafts: {
        nesting: true,
        customMedia: true,
      },
    },
  },
})

Expected output: Production builds automatically use Lightning CSS for both transformation and minification, with nesting and custom media support.

Incremental Compilation

# v4 development server with incremental compilation
npx vite

# The @tailwindcss/vite plugin caches results
# and only recompiles affected files on change

Expected output: Development HMR is near-instant. Only the changed CSS is recompiled, not the entire Tailwind output.

Reducing Bundle Size

/* v4: Only used classes are generated (same as v3 JIT) */

/* But with Lightning CSS, unused CSS is more aggressively removed */

/* Tips for minimal bundles: */
/*
1. Use @theme for all custom values
2. Avoid arbitrary values in production (they prevent caching)
3. Keep @import statements minimal
4. Use @layer for overrides
*/

# Check which classes are used most
npx vite build --profile

# Analyze CSS composition
npx lightningcss --bundle --inputs dist/assets/*.css --output analysis.css

Expected output: Production CSS bundles under 5KB gzipped. Lightning CSS removes unused styles more aggressively than PostCSS-based tools.

Caching Strategy

# Lightning CSS caches in memory during development
# Cache clears on config changes

# For CI/CD, use persistent caching:
# Set TAILWIND_CACHE=1 to enable disk caching
TAILWIND_CACHE=1 npx vite build

# Cache location: node_modules/.cache/tailwindcss
# Cache size: ~10-50MB for large projects

Expected output: Subsequent builds are faster with caching enabled. The cache stores parsed @theme values and generated utility mappings.

Common Mistakes

1. Keeping PostCSS Config in v4

PostCSS configuration is ignored when using @tailwindcss/vite. Remove postcss.config.js and autoprefixer from dependencies.

2. Not Using @tailwindcss/vite Plugin

Running Tailwind v4 without the Vite plugin means Lightning CSS is not used. The PostCSS fallback is slower.

3. Forgetting to Build Before Deploy

Development mode serves uncompressed CSS. Always run npx vite build for production deployments.

4. Overusing Arbitrary Values in Production

Each unique arbitrary value generates a new CSS rule. Repeated arbitrary values create duplicate rules. Use @theme for repeat values.

5. Not Measuring Before Optimizing

Optimizing without measuring is guesswork. Use time and size measurements to identify real bottlenecks.

Practice Questions

1. What is the performance benefit of Lightning CSS? 10-100x faster parsing and transformation compared to PostCSS-based pipelines.

2. How do you enable caching in CI/CD? Set TAILWIND_CACHE=1 environment variable during build.

3. What replaces autoprefixer in v4? Lightning CSS has built-in vendor prefixing. No separate autoprefixer plugin needed.

4. How does v4 achieve incremental compilation? The @tailwindcss/vite plugin caches processed files and only recompiles changes.

5. What is the expected production CSS size? Under 5KB gzipped for most projects, thanks to on-demand class generation and Lightning CSS optimization.

Challenge

Set up a performance benchmark: measure v4 build time vs v3 on the same project, compare gzipped CSS sizes, enable caching, and document the improvements.

FAQ

Mini Project

Set up a performance test: measure build time for a 100-component project in v3 vs v4. Compare CSS bundle sizes (raw and gzipped). Configure caching and verify HMR speed improvements.

What's Next

Now master Third-Party Integration for using Tailwind v4 with various frameworks and tools. Then explore Plugin System for extending v4.