When Tailwind CSS v4 came out, the headline was speed: a new engine, much faster builds. This site is built with v4, and I’ve moved several client projects across from v3. I wanted to see what the upgrade changes in practice, both for developers waiting on builds and for visitors downloading the CSS.
How I tested
The test needed both versions to generate CSS from exactly the same input, so I set up a shared corpus:
- Real project: a copy of this site’s 46 TypeScript and TSX files, plus a text file listing all 589 utility classes the stylesheet uses through
@apply. Both versions scanned the same files. - Stress test: 2,000 generated component files, 7.8 MB in all, built from the same set of real utilities with responsive and hover variants and some arbitrary values. That’s roughly the size of a large application.
- Same theme: both versions got the site’s brand blue and two font families. v3 got them through
tailwind.config.js; v4 through@theme. - Same pipeline: both ran through PostCSS, which is how Next.js uses Tailwind. The output was minified with Lightning CSS and compressed with gzip and Brotli.
Versions: tailwindcss 3.4.17 against tailwindcss 4.1.3 with @tailwindcss/postcss, on Node 23 and an Apple M1. “Cold” means a fresh Node process each time, including loading the library. I took the median of several runs.
Result 1: build speed
| Build | Tailwind v3.4 | Tailwind v4.1 | Difference |
|---|---|---|---|
| This site, cold build | 286 ms | 184 ms | v4 36% faster |
| 2,000 files, cold build | 581 ms | 273 ms | v4 53% faster |
| This site, rebuild after one change | 8.6 ms | 10.5 ms | about the same |
| 2,000 files, rebuild after one change | 30.3 ms | 38.7 ms | about the same |
The new engine pulls ahead as the project grows: about a third faster on this site and about twice as fast on the large test.
Through PostCSS, rebuilds were about the same, and slightly slower on v4. Both versions already cache their work between builds, and on a few milliseconds per rebuild nobody will notice. Tailwind’s announcement quoted much bigger gains for incremental builds. I only tested through PostCSS, not the Vite plugin or the CLI, so I can’t confirm those numbers. Through PostCSS, which is how Next.js uses it, expect faster cold builds and about the same rebuilds.
Result 2: CSS size
This is where v4 surprised me.
| Output | Tailwind v3.4 | Tailwind v4.1 | Difference |
|---|---|---|---|
| This site, minified | 35.0 KB | 53.9 KB | +54% |
| This site, gzip | 7.7 KB | 9.7 KB | +26% |
| This site, Brotli | 6.6 KB | 8.1 KB | +24% |
| 2,000 files, minified | 91.0 KB | 141.0 KB | +55% |
| 2,000 files, gzip | 15.1 KB | 18.5 KB | +23% |
For the same classes, v4 produced about half as much again before compression, and about a quarter more after. To see why, I counted what each version emitted for this site:
| In the output | v3.4 | v4.1 |
|---|---|---|
| Style rules | 675 | 764 |
@media blocks | 14 | 198 |
@supports blocks | 0 | 32 |
@property declarations | 0 | 61 |
Cascade layers (@layer) | 0 | 6 |
The extra bytes come from modern CSS features. v4 registers its internal variables with @property so they can be typed and animated. It organises everything into cascade layers. Colours with opacity get an @supports fallback for older browsers. And responsive variants are wrapped one by one instead of being grouped into a few large @media blocks, which Lightning CSS didn’t merge back together.
Does the extra size matter?
For most sites, no. Two kilobytes of compressed CSS takes about 10 ms on a slow mobile connection. It’s a real cost, but small next to images and JavaScript.
What matters more is what those features need. v4 targets modern browsers: Safari 16.4, Chrome 111 and Firefox 128 or newer. If your analytics show real traffic on older iPhones that can’t update, v3 is still the safer choice.
What else changes when you upgrade
- Configuration moves into CSS. Your
tailwind.config.jsbecomes an@themeblock. On this site that made the design tokens easier to find, because they sit next to the styles that use them. - Content detection is automatic. v4 finds your source files itself. It ignores anything in
.gitignore, which occasionally surprises people when classes in an ignored folder vanish. - Some utilities are renamed. For example,
shadow-smbecameshadow-xsandoutline-nonebecameoutline-hidden. The official upgrade tool handles most of these, but check the result visually. - Opacity uses
color-mix(). Classes likebg-black/10now compile tocolor-mix(), which is why the@supportsfallbacks appear.
My recommendation
| Your situation | Recommendation |
|---|---|
| New project | v4. Faster builds, CSS-first configuration, and it’s where development is happening. |
| Large v3 project, slow builds | Upgrade. Cold builds roughly halve as projects grow. |
| Small v3 project that works | No rush. Build times are already short, and the CSS will grow a little. |
| Users on old Safari or embedded browsers | Stay on v3 until they’re gone. |
The speed claims hold up for cold builds, and the gap grows with the project. What nobody mentions is that the CSS gets bigger. It isn’t a reason to avoid v4, but it’s worth knowing before you promise a client that the upgrade will make their site faster. It will make the build faster. That isn’t the same thing.