Tailwind CSS 4 in Astro: What Actually Changed
I upgraded a project from Tailwind 3 to 4 last week. The build went from 8 seconds to under a second. I checked my setup twice because I thought something was wrong. It wasn’t. Tailwind 4 is genuinely that fast.
The config file is gone. No more tailwind.config.js. No more content arrays listing every file path Tailwind should scan. You write CSS now, and Tailwind reads it directly. The configuration lives in the stylesheet itself using @theme blocks.
This sounds like a breaking change. And it is, technically. But it’s also the thing that makes Tailwind 4 so much faster. No more parsing a JavaScript config, merging defaults, scanning directories. The compiler just reads CSS. It’s simpler and it’s faster.
I set up Tailwind 4 in Astro using the Vite plugin. Installation is straightforward. npm install tailwindcss and @tailwindcss/vite. Then add the plugin to your Astro config under vite.plugins. That’s it. No content arrays, no postcss config, no other magic.
In your global CSS file, you import tailwindcss and define your design tokens using @theme. Colors, fonts, spacing, everything goes there. The tokens become CSS custom properties you can use anywhere with var(). This means you’re not locked into Tailwind’s utility classes. You can mix them with regular CSS freely.
The automatic content detection works well. In Tailwind 3, you had to manually list every file that might contain class names. Miss one file and your styles break in production. Tailwind 4 scans your project automatically. I haven’t found a case where it missed something yet.
Container queries are first-class now. The @container directive works as expected. You can set breakpoints on parent element sizes instead of the viewport. This is useful for component libraries and widget-style layouts. The syntax is clean and predictable.
The gradient utilities got an extra stop. You can now use via-30% to position the middle color at a specific percentage. Small thing, but it saves you from writing custom CSS for certain gradient effects.
The migration from Tailwind 3 requires deleting the config file and moving all your settings into CSS. It’s not automatic. You’ll need to go through your config and translate each setting to its CSS equivalent. The Tailwind docs have a migration guide that covers the most common cases.
Memory usage dropped from about 450 megabytes to 95. That’s the kind of change you don’t notice day to day but makes a difference on CI servers or when running multiple projects.
Hot module replacement is nearly instant. In Tailwind 3, changing a color in the config file could trigger a full rebuild. In Tailwind 4, it’s just a CSS update. The browser handles the rest.
There’s nothing revolutionary here. Tailwind 4 is still Tailwind. It still uses utility classes. You still write classes in your HTML. The difference is under the hood. Faster builds, less configuration, better performance.
If you’ve been putting off updating Tailwind because the config file was getting unwieldy, version 4 solves that problem. If you liked having explicit configuration, you’ll need to adjust. The CSS approach works, but it’s different.
Tailwind 4 doesn’t change what you do. It just makes it faster and removes a file you probably maintained more than you enjoyed. Worth the upgrade.