// stack · frontend
Tailwind CSS ist die CSS-Schicht im Frontend von siteway: kleine Utility-Klassen im Markup statt selbst erfundener Klassennamen, unsere Design-Tokens als CSS-Variablen dahinter, und ein Build, der nur das CSS ausliefert, das wirklich vorkommt. Im Browser läuft davon nichts — dort kommt eine gewöhnliche schlanke CSS-Datei an.
// definition
Tailwind CSS ist ein Utility-First-CSS-Framework: Statt eigene Klassennamen zu erfinden, kombinierst du viele kleine, eindeutige Klassen direkt im Markup. Ein Build-Schritt liest deine Dateien und erzeugt genau das CSS, das darin tatsächlich vorkommt — nicht mehr. Ausgeliefert wird eine gewöhnliche CSS-Datei; im Browser läuft keine Tailwind-Laufzeit.
Adam Wathan hat Tailwind 2017 veröffentlicht, seit Version 4 wird es in CSS konfiguriert statt in einer JavaScript-Datei. Der Unterschied zu Bootstrap ist der Ansatz: Bootstrap liefert fertige Komponenten und ein Aussehen mit, Tailwind liefert nur die Bausteine — Abstände, Farben, Größen, Zustände. Das Design kommt aus deinen eigenen Tokens, nicht aus dem Framework.
// praxis
tokens zuerst · utilities danach
Tailwind ist bei uns nicht die Design-Entscheidung, sondern ihr Werkzeug. Zuerst steht das Design-System: Flächen, Hairlines, Textstufen, Signalfarbe, Schriftgrößen, Radien — alles als CSS-Variablen in einer Datei. Erst danach kommt Tailwind dazu und spiegelt diese Variablen über die @theme-Bridge auf Utility-Namen. Aus --ink-2 wird text-ink-2, aus --line wird border-line. Es gibt keine zweite Farbliste, die irgendwann auseinanderläuft.
Dark und Light sind deshalb keine zwei Designs, sondern zwei Wertesätze derselben Variablen. Eine Klasse am html-Element schaltet um, alle Utilities ziehen den neuen Wert automatisch mit. Kein dark:-Präfix an tausend Stellen, keine doppelte Pflege — und deshalb auch kein Theme, das nach dem dritten Relaunch-Sprint nur noch halb stimmt.
Utilities nehmen wir für Layout und Abstände, weil dort jede Änderung lokal bleiben soll. Alles, was mehrfach exakt gleich aussehen muss — Buttons, Command-Palette, Karten, Prosa-Blöcke — liegt als eigene Komponentenklasse im components-Layer und nutzt dieselben Tokens. Diese Trennung ist der Punkt, an dem Utility-First in der Praxis trägt statt zu wuchern: Utilities für den Einzelfall, Komponenten für das Muster.
Gebaut wird lokal mit der Tailwind-CLI, versioniert in Git, ausgeliefert über GitHub Actions. Der Build scannt das gesamte HTML-Verzeichnis und erzeugt ein Stylesheet für die gesamte Website — kein CSS pro Seite, kein Nachladen, ein Request. Jeder Stand wird von einem Menschen geprüft, auch wenn er KI-gestützt entstanden ist.
// beleg · diese website
gemessen, nicht behauptet
Diese Website ist der einfachste Beleg: 99 Seiten teilen sich eine Stylesheet-Datei. Weil der Build nur die Klassen erzeugt, die im Markup wirklich vorkommen, bleibt sie klein — 105 KB minifiziert, über die Leitung 19,3 KB mit gzip und 16,4 KB mit Brotli.
Das ist ein Request, der einmal geladen und danach aus dem Cache bedient wird — auf jeder weiteren Seite kostet CSS nichts mehr. Zusammen mit lokalen Fonts und ohne Framework-Bundle steht die Startseite bei PageSpeed Insights 100/100/100/100 mobil. Wie wir das halten, steht unter Performance.
// bausteine · 6 details
jeder mit klarem zweck
Tailwind hat viele Funktionen. Das sind die sechs, die in unseren Projekten tatsächlich tragen — vom Token bis zum ausgelieferten Stylesheet.
// d-01prinzip
Eine Klasse macht eine Sache: Abstand, Farbe, Rahmen, Umbruchverhalten. Styling steht dort, wo die Struktur steht — und eine Änderung wirkt nur auf dieses eine Element, nicht versehentlich auf drei andere.
zweck: lokale wirkung
// d-02tokens
Unsere Design-Tokens liegen als CSS-Variablen vor und werden im @theme-Block auf Tailwind-Namen gespiegelt. Farben, Schriftgrößen, Radien und Container-Breiten haben damit genau eine Quelle.
zweck: eine quelle für werte
// d-03build
Der Build scannt das Markup und erzeugt nur die Klassen, die darin vorkommen. Ungenutzte Utilities landen nie im Bundle — es gibt keinen Aufräum-Schritt, weil nie Ballast entsteht.
zweck: klein von anfang an
// d-04theming
Zwei Wertesätze derselben Variablen, umgeschaltet über eine Klasse am html-Element. Die Utilities bleiben unverändert und ziehen den Wert des aktiven Themes — statt jede Regel doppelt zu pflegen.
zweck: ein satz regeln
// d-05zustände
Hover, Focus, Breakpoints und reduzierte Bewegung stehen als Präfix direkt an der Klasse. Der sichtbare Fokus-Zustand ist damit kein Nachgedanke, sondern Teil derselben Zeile — Grundlage für Barrierefreiheit.
zweck: zustände sichtbar
// d-06komponenten
Buttons, Command-Palette, Prosa-Blöcke: Was mehrfach exakt gleich aussehen muss, wird eine eigene Klasse im components-Layer — auf denselben Tokens. Utilities für den Einzelfall, Komponenten für das Muster.
zweck: muster statt copy-paste
// einordnung
ehrlich eingeordnet
Tailwind ist ein Werkzeug, kein Bekenntnis. Es zahlt sich dort aus, wo ein eigenes Design-System über viele Seiten konsistent bleiben soll — und es bringt wenig, wenn du nur drei Seiten mit ein paar Regeln hast. Diese drei Fragen klären das schnell.
// e-01passt
Du hast eigene Farben, Abstände und Typo und willst sie über viele Seiten und Jahre halten. Genau dafür sind Tokens plus Utilities gebaut: ein Wert an einer Stelle, sichtbar überall.
tokens + utilities
// e-02passt
Sobald eine Website wächst, wächst klassisches CSS mit — und niemand traut sich mehr, etwas zu löschen. Der JIT-Build dreht das um: Was im Markup fehlt, ist auch im CSS weg.
kein css-wildwuchs
// e-03eher nicht
Wenn niemand im Projekt einen Build ausführen kann oder will, ist handgeschriebenes CSS mit CSS-Variablen der ehrlichere Weg. Dasselbe gilt für sehr kleine Seiten mit ein paar Dutzend Regeln.
plain css genügt
// faq
Tailwind CSS ist ein Utility-First-CSS-Framework. Statt eigener Klassennamen wie „card__header“ kombinierst du viele kleine, eindeutige Klassen direkt im Markup: flex, gap-3, rounded-md, text-ink-2. Ein Build-Schritt liest dein Markup und erzeugt genau das CSS, das tatsächlich vorkommt. Adam Wathan hat Tailwind 2017 veröffentlicht; aktuell ist Version 4. Im Browser läuft keine Tailwind-Laufzeit — ausgeliefert wird reines CSS. siteway baut damit das Frontend dieser Website und der Kundenprojekte.
Utility-First heißt: Eine Klasse macht genau eine Sache. p-6 setzt Innenabstand, border-line setzt die Rahmenfarbe, max-[720px]:grid-cols-1 setzt das Layout unter 720 Pixel. Das Styling steht dort, wo auch die Struktur steht, und eine Änderung wirkt nur auf das eine Element. Der Preis dafür sind längere class-Attribute; der Gewinn ist, dass niemand mehr Klassennamen erfinden und pflegen muss und dass altes CSS nicht unbemerkt liegen bleibt.
Die class-Attribute werden länger, das stimmt. In der Praxis wiegt der Gegenwert schwerer: Du siehst am Element sofort, was es tut, ohne in eine zweite Datei zu springen. siteway hält das im Rahmen, indem wiederkehrende Muster nicht als kopierte Klassenkette leben, sondern als eigene Komponentenklasse im components-Layer — Buttons, Command-Palette, Karten. Utilities für das Layout, Komponenten für alles, was mehrfach exakt gleich aussehen muss.
So groß wie das, was du tatsächlich benutzt. Tailwind scannt beim Build die Quelldateien und erzeugt nur die vorkommenden Klassen — ungenutzte Utilities landen nie im Bundle. Konkret bei dieser Website: eine einzige app.css für alle 99 Seiten, 105 KB minifiziert, über die Leitung 19,3 KB mit gzip beziehungsweise 16,4 KB mit Brotli. Gemessen am ausgelieferten Stand im Juli 2026.
Die Tokens von siteway liegen als CSS-Variablen in tokens.css: Flächen, Hairlines, Text, Signalfarbe, Schriftgrößen, Radien. Dark und Light sind zwei Wertesätze derselben Variablen, umgeschaltet über eine Klasse am html-Element. In der Tailwind-Entry-Datei werden diese Variablen per @theme auf Tailwind-Namen gespiegelt, sodass bg-bg-1, text-ink-2 oder border-line automatisch den Wert des aktiven Themes ziehen. Es gibt keine zweite Farbliste für den Dunkelmodus — es gibt nur die Tokens.
Nein. Tailwind ist ein Build-Werkzeug: Es läuft beim Kompilieren und gibt eine gewöhnliche CSS-Datei aus. Im Browser gibt es keine Tailwind-Laufzeit, kein Framework-Bundle, keine Hydration. Deshalb ist Tailwind auch kein Widerspruch zum Frontend-Ansatz von siteway ohne JavaScript-Framework — es beschleunigt die Entwicklung, ohne die ausgelieferte Seite zu belasten.
Version 4 konfiguriert sich in CSS statt in einer JavaScript-Konfigurationsdatei. Theme-Werte stehen in einem @theme-Block, die zu scannenden Dateien werden mit @source angegeben, eingebunden wird mit einem @import. Für siteway ist das der entscheidende Punkt: Design-Tokens und Tailwind-Konfiguration liegen in derselben Sprache und derselben Datei-Welt, statt in einer JavaScript-Datei doppelt gepflegt zu werden.
// womit das zusammenhängt
stack & leistung
// stack · übergeordnet
Der ganze Ansatz drumherum: semantisches HTML5, Vanilla JavaScript, Progressive Enhancement — und warum kein React oder Vue dazwischen steht.
zum stack →
// stack · tempo
Wozu das kleine Stylesheet gehört: Core Web Vitals, lokale Fonts, ein Request statt vieler — und wie wir 100/100/100/100 halten.
zum stack →
// leistung · buchen
Das Design-System, aus dem die Tokens kommen: Oberfläche, Komponenten und Regeln — als Leistung. Hier wird gebucht.
weiterlesen →
// Frontend, das nach Jahren noch trägt?
Projekt anfragen