Tailwind Performance Optimization: JIT, Content Configuration, and Production Bundle Size Control

It was 3 AM. I stared at that 3.5MB CSS file in Chrome DevTools, completely frozen.

The new feature page we just launched had gone from loading in 800ms to 3.2 seconds. After hours of debugging, I found the culprit: that CSS file was packed with Tailwind classes we never even used.

Honestly, I was pretty frustrated. Tailwind claims to be “performance-friendly,” yet here it was dragging us down.

Railway - Modern deployment platform, zero-config, go live in minutes

Start Now →Ad

Turns out, the problem wasn’t Tailwind itself—it was the configuration. Once I understood how JIT mode actually works, fixed the content config, and applied production build optimizations, our CSS dropped from MB-level to KB-level. Netflix’s website uses just 6.5KB of CSS.

Let me walk you through the pitfalls I stumbled into.

1. JIT Mode: Tailwind’s Performance Revolution

1.1 The Problem with Traditional Mode

Before that night with the 3.5MB CSS file, my understanding of Tailwind was just “utility-first CSS framework.”

Then I learned that Tailwind v2’s “traditional mode” pre-generates every possible class combination—every color, every spacing value, every variant (hover, focus, disabled, etc.). A moderately complex project could end up with 10MB+ of CSS in development.

A 10MB CSS file seems harmless in local dev—bandwidth isn’t an issue. But the browser still has to parse that massive stylesheet, which impacts memory and DevTools performance.

I ran into this exact problem debugging in Firefox: changing one class name caused DevTools to freeze for seconds. Refreshing the page was painfully slow.

What’s worse, traditional mode made us hesitant to modify config. Adding a new breakpoint or enabling focus-visible variant meant calculating “how many more class combinations will this add?” Teams were forced to choose between performance and flexibility.

1.2 How JIT Actually Works

JIT (Just-in-Time) mode was introduced in Tailwind v2.1 and enabled by default in v3+. Simply put: generate on demand.

Traditional mode pre-generates every possible class combination at build time, even ones you’ll never use. JIT reverses this—it first scans your template files (HTML, JSX, Vue, etc.), finds which classes you’re actually using, then generates only those styles.

Here’s an example. Traditional mode would generate CSS like this:

.bg-black { background-color: #000 }
.hover\:bg-black:hover { background-color: #000 }
.focus\:bg-black:focus { background-color: #000 }
.disabled\:bg-black:disabled { background-color: #000 }
/* ... plus dozens of variant combinations */

Even if your project only uses bg-black, all those other dozens of variant styles get generated anyway.

JIT mode is different. It scans your templates, finds you only use bg-black and hover:bg-black, and generates just those two:

.bg-black { background-color: #000 }
.hover\:bg-black:hover { background-color: #000 }

This drops dev environment CSS from 10MB-level to KB-level—and it matches production size.

1.3 Real Benefits of JIT

The first time I enabled JIT in a project, the page refresh speed felt unreal—previously I had to wait several seconds, now it was instant.

Build speed: Full builds used to take 2-3 minutes, now they finish in seconds. JIT doesn’t need to pre-generate all styles, just scan template files to extract class names.

Dev experience: DevTools stopped freezing. Before, modifying a class meant waiting for the browser to re-parse that 10MB stylesheet. Now with just a few KB of CSS, changes are nearly instant.

Arbitrary values: This was a pleasant surprise. In traditional mode, using arbitrary values like text-[#facc15] required enabling safelist in config. JIT supports them directly:

// No need to pre-define in config, just use it
<h1 class="text-[2.5rem] mt-[1.35rem] text-[#facc15]">
  JIT makes everything simple
</h1>

Dynamic classes: Traditional mode couldn’t detect concatenated class names like 'text-' + color. JIT still has limitations, but with safelist it handles dynamic scenarios more flexibly.

After all this, you might wonder: how do I enable JIT mode? Actually, in Tailwind v3+ it’s already the default, no extra config needed. If you’re still on v2, enable it like this:

// tailwind.config.js
module.exports = {
  mode: 'jit',  // v2 requires manual enable
  content: ['./src/**/*.{html,js,jsx,ts,tsx}'],
  // ...
}

2. Content Configuration: The Key to Precise Scanning

JIT mode is great, but only if content config is correct.

Content determines which files Tailwind scans to extract class names. Wrong config means either missing styles (too narrow scan scope) or CSS bloat (too wide scope).

2.1 Content Config Basics

Basic syntax is straightforward:

// tailwind.config.js
module.exports = {
  content: [
    './src/**/*.{html,js,jsx,ts,tsx}',  // Scan all template files in src
  ],
  // ...
}

Here ** means any level of directory nesting, *.{html,js,jsx,ts,tsx} matches files with these extensions.

If you’re using a specific framework, you might need to adjust paths:

// Next.js project
content: [
  './pages/**/*.{js,ts,jsx,tsx}',
  './components/**/*.{js,ts,jsx,tsx}',
  './app/**/*.{js,ts,jsx,tsx}',  // App Router
]

// Astro project
content: [
  './src/**/*.{astro,html,js,jsx,ts,tsx}',
]

The key is: cover all files that use Tailwind class names. Missing one directory means styles in that directory won’t generate.

Alibaba Cloud - Top choice for developers, exclusive 15% off for Lighthouse servers

Get 15% Discount →Ad

2.2 Pitfalls I Hit

Pitfall 1: Overly broad glob patterns

I wanted “simple” config and used this approach:

content: [
  './**/*.js',  // This scans node_modules!
]

Result: Tailwind scanned every JS file in node_modules, build time exploded, and it generated piles of nonsensical styles.

The right approach is limiting scope:

content: [
  './src/**/*.js',      // Only scan src directory
  './components/**/*.js', // Only scan components directory
]

Pitfall 2: Missing component directories

Once during a refactor, I moved components to ./lib/components/. Forgot to update content config, and styles for the new location completely disappeared.

Debugged for hours before finding the issue. Lesson learned: when changing project structure, always sync content config.

Pitfall 3: Dynamically constructed class names

Like this approach:

const color = 'red';
const className = `text-${color}-500`;  // JIT can't detect

JIT sees the template string when scanning, not the complete class name. Result: production build strips this style.

Solution: use safelist (covered later) or switch to object syntax:

const colors = {
  red: 'text-red-500',
  blue: 'text-blue-500',
};
const className = colors[color];  // Complete class name, detectable

2.3 Safelist and Dynamic Classes

Some scenarios genuinely need dynamic class names. That’s where safelist comes in.

// tailwind.config.js
module.exports = {
  safelist: [
    'text-red-500',
    'text-blue-500',
    'bg-red-500',
    // Or use regex to match a group of class names
    {
      pattern: /text-(red|blue|green)-(500|600)/,
      variants: ['hover', 'focus'],  // Also preserve variants
    },
  ],
}

Safelist forces Tailwind to generate these styles, even if they don’t appear directly in template files.

But note: more safelist entries = larger CSS file. Use it only in necessary scenarios, don’t treat it as a “safety box” stuffing every possible class name.

3. Production Bundle Size Control: Four-Layer Optimization Strategy

JIT makes small dev CSS possible, but production builds need further optimization.

I organized a four-layer optimization strategy, from config to compression, each layer building on the previous.

3.1 Layer 1: Precise Content Configuration

This is foundational, covered earlier.

Core principle: only scan files that actually use Tailwind classes. More precise scope = faster builds = smaller CSS.

// Good: precise scope
content: [
  './src/components/**/*.jsx',
  './src/pages/**/*.tsx',
]

// Bad: too broad
content: [
  './**/*.js',  // Scans node_modules
]

3.2 Layer 2: PurgeCSS Auto-Removal

Tailwind v3+ automatically enables PurgeCSS in production builds, removing unused styles.

Key is ensuring build commands correctly distinguish dev/production:

# Dev build (won't remove unused styles)
npm run dev

# Production build (auto PurgeCSS)
npm run build

If using PostCSS, you can explicitly control in config:

// postcss.config.js
module.exports = {
  plugins: {
    tailwindcss: {},
    autoprefixer: {},
    ...(process.env.NODE_ENV === 'production' ? { cssnano: {} } : {}),
  },
}

3.3 Layer 3: cssnano Minify

After PurgeCSS removes unused styles, cssnano further compresses CSS.

Compression includes: removing comments, merging duplicate rules, simplifying selectors, compressing values, etc.

# Tailwind CLI direct minify
npx tailwindcss -i ./src/input.css -o ./dist/output.css --minify

# Or via PostCSS (shown above)

Real data from my project: dropped from 150KB (after PurgeCSS) to 45KB (after minify).

3.4 Layer 4: Brotli/Gzip Network Compression

This layer isn’t CSS optimization itself, but network transfer.

Server using Brotli or Gzip to compress static assets can shrink CSS files another 60-80%.

# Nginx Brotli config (requires ngx_brotli module)
brotli on;
brotli_comp_level 6;
brotli_types text/css application/javascript;

# Or use Gzip (Nginx default support)
gzip on;
gzip_comp_level 6;
gzip_types text/css application/javascript;

Comparison data: 45KB CSS file becomes ~8KB after Brotli compression.

So when Netflix says their CSS is 6.5KB, that’s Brotli-compressed transfer size, not original file size.

4. Real-World Cases and Data Comparison

4.1 My Before/After Optimization Comparison

Honestly, seeing these numbers surprised even me.

4.2 Common Problem Troubleshooting

Styles missing?

First: check content config, confirm all files using Tailwind classes are in scan scope.

Second: if you have dynamic class names, check if safelist is needed.

Third: check build command, confirm using production build (npm run build), not dev build.

CSS still large?

Check if safelist is excessive. Check if third-party library CSS mixed into Tailwind build output. Check if content scope is too broad.

Vultr - High-performance NVMe VPS with 32 global locations, one-click Docker deploy

View Pricing →Ad

DevTools freezing?

Confirm Tailwind version ≥3 (JIT default enabled). Check if content config is precise. If still on v2, upgrade or manually enable JIT mode.

5. Tailwind v4 New Features Preview

After covering current optimizations, let’s look at Tailwind v4 (released late 2024) changes.

5.1 Oxide Engine

This is the most exciting update: Tailwind rewrote the underlying engine in Rust.

Official data: incremental build speed increased 182x. Basically, before changing a class meant waiting seconds for recompilation, now it’s millisecond response.

The principle: Oxide engine caches file scan results, only re-processing changed parts. This is especially useful for large projects—we have one with 200+ component files, previously each build took ~10 seconds, now it’s basically instant.

5.2 Zero-Config Goal

Tailwind v4 pushes a new philosophy: most projects don’t need tailwind.config.js.

Default config already covers common needs: modern CSS features, container queries, reasonable breakpoints, complete color system. Only write config file when deep customization is needed.

This means new projects start faster, fewer chances of config errors.

Note for v4 migration: config syntax changed. For example, previous theme.extend.colors now needs CSS custom properties. Review official upgrade guide before migrating.

Summary

After that 3 AM meltdown, I reorganized the project’s Tailwind config from scratch.

JIT mode makes dev and prod use equally small CSS, content config determines scan scope, four-layer optimization compresses CSS from MB to KB. Plus Tailwind v4’s Oxide engine, build speed is no longer a bottleneck.

If your project still uses traditional mode, or content config has issues, start by checking these points:

1. Is Tailwind version ≥3 (JIT default enabled)
2. Does content config precisely cover all template files
3. Is PurgeCSS and cssnano enabled in production build
4. Is Brotli/Gzip compression configured on server

After these changes, you’ll likely see significant performance improvement.

Feel free to comment with questions, or check Tailwind official docs on JIT and production optimization—they’re quite clear.

References

• Tailwind CSS Just-in-Time Mode Docs
• Optimizing for Production Docs
• Just-In-Time: The Next Generation of Tailwind CSS
• Tailwind CSS v4.0 Release
• Tailwind CSS Best Practices for Performance Optimization

10 min read · Published on: Mar 30, 2026 · Modified on: Mar 30, 2026

Easton

Technology