Tailwind CSS v4 – Neue Features: Performance, Konfiguration und Migrationsleitfaden

35 Millisekunden – so lange brauchte Tailwind v3 für einen inkrementellen Build. In v4 sind es 192 Mikrosekunden. Nicht Millisekunden, Mikrosekunden.

Beim ersten Anblick dieser Zahl war ich skeptisch. Marketing kann jeder. Nach einer echten Migration und HMR von 340 ms auf 12 ms war klar: Tailwind meint es ernst.

Die Oxide-Engine in Rust liefert echte Verbesserungen – kein „fühlt sich etwas schneller an“, sondern: Padding ändern, speichern, Seite aktualisiert, bevor du blinzelst. Tailwind v4 ist mehr als ein neuer Motor: Konfiguration wandert von JS nach CSS, Installation wird Zero-Setup, Utility-Syntax ändert sich (Transparenz-Modifier, Container Queries, 3D Transforms …).

Dieser Artikel erklärt die Änderungen und liefert eine Migrations-Checkliste zum direkten Abarbeiten.

Oxide-Engine – warum v4 so schnell ist

Kennst du das? Farbe ändern, speichern, zwei bis drei Sekunden auf den Browser starren – besonders in großen Projekten mit Tailwind v3 und knappem Deadline-Druck.

Die Oxide-Engine in v4 zielt genau darauf. Statt den alten JS-Motor zu flicken, hat das Tailwind-Team den Compiler in Rust neu gebaut – mutig, aber mit messbarem Nutzen.

Wie viel Performance bringt es wirklich?

Offizielle Benchmarks am Catalyst-Projekt:

Der letzte Wert ist am extremsten: Nur HTML-Struktur geändert, keine neuen CSS-Klassen – v4 landet im Mikrosekunden-Bereich, praktisch nicht spürbar.

Daten aus einem Produktionsprojekt (500+ Komponenten):

HMR von 340 ms auf 12 ms verändert den Dev-Alltag spürbar – früher eine deutliche Pause, heute praktisch sofort.

Was Oxide richtig macht

Kern: Rust + Lightning CSS. Rust ist schnell, entscheidend ist aber die Architektur:

Einheitliche Toolchain. v3 hing an PostCSS, autoprefixer, cssnano … v4 baut das ein, nur noch Lightning CSS. Weniger Schritte, mehr Tempo.

Intelligente Content-Erkennung. Früher content-Array in tailwind.config.js. v4 liest .gitignore und Modulgraph, findet Dateien selbst. Weniger Config, schnellerer Scan.

Native CSS-Features. Echte @layer-Regeln, @property, color-mix() – vom Browser nativ, ohne Compile-Zwischenschritt.

Railway - Moderne Deployment-Plattform, ohne DevOps-Aufwand, in Minuten live

Jetzt starten →Anzeige

Die Details musst du nicht auswendig kennen. Ergebnis: schnellere Builds, weniger Config, besseres Dev-Erlebnis.

CSS-first-Konfiguration – Abschied von tailwind.config.js

Der größte Wandel in v4 – und der teuerste Teil der Migration.

Früher tailwind.config.js, jetzt @theme in CSS. Ungewohnt, wenn du jahrelang JS-Config gewohnt warst – nach einer Weile passt es besser zur CSS-Denkweise.

Konfigurations-Migration: Before & After

Einfachstes Beispiel – eigene Primärfarbe:

// v3: tailwind.config.js
module.exports = {
  theme: {
    extend: {
      colors: {
        primary: '#3b82f6',
      },
    },
  },
}

In v4 alles in CSS:

/* v4: app.css */
@import "tailwindcss";

@theme {
  --color-primary: #3b82f6;
}

primary wird zu --color-primary – v4 hat strikte Präfix-Regeln.

Variablen-Namensregeln

Am Anfang wirkt das umständlich – Vorteil: vorhersagbare Namen. Schriftgröße? Immer --text-*.

Komplexeres Beispiel

v3-Konfiguration:

// v3: tailwind.config.js
module.exports = {
  theme: {
    extend: {
      colors: {
        brand: {
          light: '#f0f9ff',
          DEFAULT: '#0ea5e9',
          dark: '#0369a1',
        },
      },
      fontFamily: {
        display: ['Cal Sans', 'sans-serif'],
      },
      animation: {
        'fade-in': 'fadeIn 0.5s ease-out',
      },
    },
  },
  plugins: [
    require('@tailwindcss/typography'),
  ],
}

Migration nach v4:

/* v4: app.css */
@import "tailwindcss";

@theme {
  /* Farben */
  --color-brand-light: #f0f9ff;
  --color-brand: #0ea5e9;
  --color-brand-dark: #0369a1;

  /* Schriftarten */
  --font-display: "Cal Sans", sans-serif;

  /* Animationen */
  --animate-fade-in: fadeIn 0.5s ease-out;
}

/* Plugins */
@plugin "@tailwindcss/typography";

Wichtige Änderungen:

1. Farben flach. v3: brand.light verschachtelt; v4: --color-brand-light
2. Plugins via @plugin. Kein JS-require mehr
3. Kein DEFAULT-Suffix. Standardfarbe: --color-brand

Dark-Mode-Konfiguration

v3:

// v3
module.exports = {
  darkMode: 'class', // oder 'media'
}

v4 default: media (System). Für class in CSS:

/* v4 */
@import "tailwindcss";
@variant dark (&:where(.dark, .dark *));

Bedeutung: Dark-Mode-Styles, wenn Element oder Vorfahre .dark hat.

Content-Erkennung

Früher manuell:

// v3
module.exports = {
  content: [
    './src/**/*.{js,ts,jsx,tsx}',
    './public/index.html',
  ],
}

v4 liest .gitignore, ignoriert Ausgeschlossenes, scannt den Rest. Sonderstruktur? @source:

/* v4 */
@import "tailwindcss";
@source "../node_modules/my-ui-lib";

Vorteil CSS-first: Styling-Config in einer CSS-Datei, kein Springen zwischen JS und CSS. Nachteil: Umstellungsphase für JS-Config-Gewohnte.

Installation und Integration – Zero-Setup

Tailwind v3: drei Pakete, Config-Datei, PostCSS, content-Array … v4 reduziert das drastisch.

Minimal-Installation

Mit Vite zwei Schritte:

# 1. Installieren
npm install tailwindcss @tailwindcss/vite

# 2. Eine Zeile in vite.config.js
import tailwindcss from '@tailwindcss/vite'

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

In der CSS-Datei:

/* app.css oder index.css */
@import "tailwindcss";

Das war’s. Kein tailwind.config.js, kein postcss.config.js, kein content-Array.

Drei Integrationswege

Vite (empfohlen):

Alibaba Cloud - Top-Wahl für Entwickler, exklusiv 15 % Rabatt auf Lighthouse-Server

15 % Rabatt sichern →Anzeige

npm install tailwindcss @tailwindcss/vite

// vite.config.js
import tailwindcss from '@tailwindcss/vite'

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

PostCSS:

npm install tailwindcss @tailwindcss/postcss

// postcss.config.js
export default {
  plugins: {
    '@tailwindcss/postcss': {},
  },
}

CLI:

npx tailwindcss -i input.css -o output.css --watch

Meist reicht Vite. PostCSS für Legacy-Migration, CLI ohne Build-Pipeline.

Automatische Content-Erkennung

Kein content-Array: v4 findet Dateien selbst.

Es liest .gitignore, schließt node_modules, dist usw. aus, sucht Tailwind-Klassen in den übrigen Dateien.

Voraussetzung: typische Node.js-Projektstruktur. Templates außerhalb des Projekts? Manuell:

@import "tailwindcss";
@source "../templates";  /* Scan-Pfad manuell */

Bonus: neue Dateien brauchen keine Config-Updates mehr.

Breaking Changes und Migrations-Checkliste

Kern der Migration. Die meisten Änderungen folgen Mustern; npx @tailwindcss/upgrade hilft stark mit.

Transparenz-Modifier

Größter Eingriff. v3 Hintergrund-Transparenz:

<!-- v3 -->
<div class="bg-blue-500 bg-opacity-50">...</div>

v4 in der Farbe:

<!-- v4 -->
<div class="bg-blue-500/50">...</div>

Gilt für alle Farb-Utilities:

<!-- Text-Transparenz -->
<p class="text-gray-900/75">...</p>

<!-- Rand-Transparenz -->
<div class="border-red-500/30">...</div>

bg-opacity-*? Entfernen – v4 unterstützt sie nicht.

Umbenannte Utilities

Achtung shadow/rounded: früheres shadow → shadow-sm, früheres shadow-sm → shadow-xs.

Default-Änderungen

Können visuelle Abweichungen erzeugen:

border-Default: v3 gray-200, v4 currentColor – Rand folgt Textfarbe.

<!-- v3: grauer Rand -->
<div class="border text-blue-500">Rand ist gray-200</div>

<!-- v4: Rand folgt Text -->
<div class="border text-blue-500">Rand ist blue-500</div>

ring-Default: v3 3px blue-500; v4 1px currentColor.

<!-- v3: blauer 3px-Ring -->
<button class="ring">...</button>

<!-- v4: currentColor 1px -->
<button class="ring">...</button>

<!-- v3-Effekt wiederherstellen -->
<button class="ring-3 ring-blue-500">...</button>

Vollständige Migrations-Checkliste

In dieser Reihenfolge:

1. Abhängigkeiten upgraden

   npm install tailwindcss@latest @tailwindcss/vite@latest

2. Automatisches Migrations-Tool

   npx @tailwindcss/upgrade

   Konvertiert u. a. @tailwind, Transparenz-Klassen, umbenannte Utilities.

3. CSS-Einstieg umstellen

   /* v3 */
   @tailwind base;
   @tailwind components;
   @tailwind utilities;
   
   /* v4 */
   @import "tailwindcss";

4. Config migrieren: tailwind.config.js → @theme in CSS.

5. Plugins: JS → @plugin.

   @plugin "@tailwindcss/typography";

6. Transparenz-Klassen: global nach bg-opacity, text-opacity, border-opacity suchen.

7. Umbenannte Klassen: shadow-*, rounded-*, flex-grow-*, flex-shrink-*.

8. Defaults: border-Farbe und ring-Stil prüfen.

9. Visuelle Regression: Tests laufen lassen.

Das Tool erledigt ~80 %; die restlichen 20 % – besonders Default-Änderungen – brauchen manuelle Entscheidungen.

Neue Features – Container Queries, 3D Transforms & mehr

Neben Performance und Config kommen praktische Neuerungen.

KiloClaw - Managed OpenClaw für Unternehmen: AI-Agent-Orchestrierung und smartes Modell-Routing

Jetzt starten →Anzeige

Container Queries integriert

Früher Plugin, jetzt nativ:

<!-- Container definieren -->
<div class="@container">
  <!-- Nach Containerbreite reagieren -->
  <div class="@md:grid-cols-2 @lg:grid-cols-3">
    ...
  </div>
</div>

@container ≈ container-type: inline-size; @md: ist Container-Breakpoint – ähnlich wie md:, mit @ davor.

Ideal für Komponentenbibliotheken: Layout nach Eltern-Container, nicht Viewport.

3D-Transform-Utilities

<!-- 3D-Perspektive -->
<div class="perspective-distant">
  <!-- Rotation X -->
  <div class="rotate-x-45">...</div>
</div>

<!-- Rotation Y -->
<div class="rotate-y-12">...</div>

<!-- Skalierung Z -->
<div class="scale-z-150">...</div>

Klassen u. a.: rotate-x-*, rotate-y-*, rotate-z-*, scale-z-*, perspective-*, translate-z-* – praktisch für Karten-Flip, 3D-Menüs.

@starting-style-Variante

Nutzt natives CSS @starting-style für Styles beim ersten Render:

<!-- Einblenden von transparent zu deckend -->
<div class="starting:opacity-0 opacity-100 transition-opacity">
  ...
</div>

Einblend-Animation ohne JavaScript – früher custom animate-fade-in, jetzt eine Klasse.

not-*-Variante

CSS :not():

<!-- Alle Kinder außer dem letzten -->
<li class="not-last:mb-4">...</li>

<!-- Buttons ohne disabled -->
<button class="not-disabled:opacity-100">...</button>

Direkter als Umwege über last:mb-0.

Erweiterte Gradient-API

<!-- Conic-Gradient -->
<div class="bg-conic/from-red-500 via-yellow-500 to-blue-500">...</div>

<!-- Radial-Gradient -->
<div class="bg-radial from-white to-transparent">...</div>

<!-- Interpolationsmodus -->
<div class="bg-linear-to-r from-blue-500 to-purple-500 via-oklch">...</div>

via-oklch: natürlichere Übergänge, besonders bei Farbraum-Konvertierung.

Fazit

Upgrade lohnenswert?

Bei aktiver Entwicklung: ja. HMR von Hunderten Millisekunden auf ~12 ms spart täglich Wartezeit. Kleineres CSS, weniger RAM – in großen Projekten besonders spürbar.

Migrationsaufwand: Config-Umstellung und Klassen-Änderungen. npx @tailwindcss/upgrade übernimmt vieles; mittleres Projekt (200+ Komponenten) ~ halber Tag inkl. Tests.

Neues Projekt? Direkt v4. Zero-Setup, Auto-Content, CSS-first – kein Grund zurückzubleiben.

Browser: Safari 16.4+, Chrome 111+, Firefox 128+. Alte Browser → Upgrade verschieben.

Empfehlungen:

• Neues Projekt: v4
• Bestehendes: npx @tailwindcss/upgrade
• border-Default und ring-Defaults prüfen
• Hilfe: offizielle Upgrade-Doku