Confession: I almost didn’t upgrade. I’d read the Tailwind v4 announcement, nodded at the “it’s faster” headline the way you nod at every “it’s faster” headline, and gone back to work. Build speed wasn’t my problem. My problem was a flaky watcher that took a second or two to repaint after every save, and I’d quietly accepted that as the cost of doing business.
Then I upgraded one Friday afternoon out of boredom, and the watcher stopped lagging. Not “improved.” Stopped. Saves repainted before I could look back up at the browser. That’s when I went and actually read what they did to the engine, and it turns out the speed isn’t a tuning pass. They rewrote the core in Rust and called it Oxide.
This post is about that rewrite specifically: what’s different under the hood, what setup looks like now, and the numbers I saw on a real project. If you want the design-token side of the migration, I wrote about the Tailwind config file I deleted separately. Here I’m staying on the engine.
What they actually changed under the hood
Tailwind v3 ran on a JavaScript pipeline. It leaned on PostCSS, scanned your files for class names, generated CSS, and handed the result down the chain. It worked, and for most projects it was fast enough that you never thought about it.
v4 throws most of that out. The new engine, Oxide, is written in Rust. Its one real dependency is Lightning CSS, itself a Rust-based parser and minifier that the Tailwind team folded in to replace the old PostCSS-plus-plugins arrangement. So the parsing, the class scanning, the generation, and the minification now happen in compiled code that uses every core your machine has instead of a single-threaded JS process.
I want to be honest about what that does and doesn’t mean. It doesn’t change a single class name. flex, pt-4, grid-cols-3 all behave exactly as they did. What changed is everything that happens between you hitting save and the CSS landing in your browser. The output is the same shape; the path to it got a lot shorter.
Setup got shorter, and that’s part of the speed
The clearest sign that something fundamental changed is how little setup v4 needs. Here’s roughly what a v3 project carried around.
// tailwind.config.js
/** @type {import('tailwindcss').Config} */
module.exports = {
content: [
"./src/**/*.{html,js,jsx,ts,tsx}",
"./components/**/*.{js,jsx,ts,tsx}",
],
theme: { extend: {} },
plugins: [],
};
// postcss.config.js
module.exports = {
plugins: {
tailwindcss: {},
autoprefixer: {},
},
};
/* main.css */
@tailwind base;
@tailwind components;
@tailwind utilities;
Three files, and that content array was a recurring source of small pain. Forget to add a new directory and your classes silently don’t generate. I lost an hour once to exactly that, staring at an unstyled component convinced I’d typo’d a class name, when really I’d just added a folder the scanner wasn’t watching.
In v4, most of that collapses:
/* main.css */
@import "tailwindcss";
That’s the whole thing for a lot of projects. No content array, because v4 does automatic content detection: it reads your .gitignore and walks the module graph to figure out which files to scan, so it finds your templates without you listing them. No separate PostCSS config in the common case either, since Lightning CSS handles the prefixing and minifying the autoprefixer plugin used to do.
Fewer moving parts is nice on its own. But it also matters for speed, because the engine isn’t re-reading a config file and reconciling a glob list on every run. It knows where to look and goes straight there.
The numbers I actually saw
The official post claims full builds up to roughly 5x faster and incremental builds over 100x faster, fast enough that they’re measured in microseconds. I’m allergic to vendor benchmarks, so I timed my own project: a mid-sized Next.js app, a few hundred components, nothing exotic.
Cold production build of the CSS went from a little under a second to around 150ms. That’s real but not life-changing; I run a full build a handful of times a day. The number that actually changed my afternoon was the incremental rebuild during development. In v3 a save triggered a repaint I could perceive, a beat where the old styles flashed before the new ones came in. In v4 I genuinely cannot catch it. The watcher result is there by the time my eyes move to the browser.
That perceptual difference is the whole point. A 700ms build you run twice a day is a rounding error. A 200ms hitch you hit four hundred times a day is a tax on your concentration, and removing it is the kind of thing you don’t notice until it’s gone and your flow stops breaking. You can read the v4 announcement for their full benchmark methodology if you want the exact rig.
Lightning CSS is quietly doing a lot of the work
It’s easy to give Rust all the credit, but a good chunk of the win comes from swapping the CSS toolchain itself. Lightning CSS parses, transforms, prefixes, and minifies in one pass, and it’s significantly faster than the PostCSS plugin stack it replaced. It also tends to minify more aggressively, so the output file came out a touch smaller for me without any effort on my part.
There’s a side benefit I didn’t expect: modern CSS features I used to reach for plugins to handle now just work. Nesting is parsed natively. Vendor prefixing happens without me wiring up autoprefixer. The engine leans on the browser’s own cascade layers and custom properties rather than faking them in the build step. So the build is doing less translation overall, which is part of why it’s quick. Less work is fast work.
If you’ve ever maintained a postcss.config.js that grew plugins like barnacles, this is the relief. Most of those plugins existed to paper over gaps that the platform and Lightning CSS now cover.
What this is good for, and where it won’t help
I don’t want to oversell it. If your CSS build was never your bottleneck, v4 won’t suddenly make your app faster for users. The generated stylesheet is comparable in size and behavior. This is a developer-experience and build-time story, not a runtime one.
There’s also a real migration cost if you’ve got a heavy custom config or a pile of community plugins, some of which assumed the old JavaScript pipeline. For a fresh project or a reasonably standard setup, the upgrade is close to painless. For a large app with bespoke tooling, budget an afternoon and read the breaking changes first. I write more about how I weigh upgrade costs like this in my project work, because “is the new version worth the migration” is a question I answer a lot.
Where it genuinely shines is the tight feedback loop. If you do a lot of design work in the browser, tweaking spacing and color and re-checking, the near-instant rebuild changes how that feels. It’s the same reason I care about responsive tooling getting out of the way, which I got into when I stopped faking responsiveness with container queries.
What to do this week
If you’re on v3 and even mildly curious, spin up the upgrade tool on a branch and time your own dev rebuild before and after. Don’t trust my numbers or theirs. Run npx @tailwindcss/upgrade on a throwaway branch, start your dev server, and save a file a few times with the network tab’s timing open. You’ll know within five minutes whether the difference is perceptible on your setup.
If you’re starting something new, just begin on v4. The one-line @import "tailwindcss" setup and automatic content detection mean there’s less to get wrong on day one, and you skip the config archaeology entirely. Either way, read the official upgrade guide before you touch a big project, because the painless path assumes a fairly standard config and the guide tells you when yours isn’t.
The thing I keep coming back to: I upgraded for no real reason and got a faster dev loop I didn’t know I wanted. That’s rare. Most version bumps cost you a day and give you a changelog. This one gave me back the half-second I’d stopped noticing I was losing.
