Tailwind CSS Bundle-Analyse: Tools zum Messen der Größe

1. Warum Bundle-Analyse mehr ist als eine Dateigröße

Eine oberflächliche Bundle-Analyse beschränkt sich oft darauf, die Dateigröße des generierten Tailwind-CSS mit ls -la zu prüfen. Das liefert eine einzelne Zahl, aber keine Erklärung dafür, woher diese Zahl kommt oder ob sie ein Problem darstellt. Eine aussagekräftige Bundle-Analyse beantwortet stattdessen Fragen wie: Welche Utility-Gruppen tragen am meisten zur Gesamtgröße bei? Gibt es ungenutzte Selektoren, die trotz Content-Scanning ins finale CSS gelangt sind? Wie verändert sich die Größe über mehrere Releases hinweg?

Der Unterschied wird besonders deutlich, wenn ein Projekt über Monate wächst: Ohne systematische Bundle-Analyse bleibt unklar, ob eine neue Safelist-Regel, ein zusätzliches Utility-Plugin oder einfach mehr Komponenten für ein größeres Stylesheet verantwortlich sind. Mit den richtigen Werkzeugen lässt sich jede Größenänderung auf eine konkrete Ursache zurückführen, statt bei jedem Anstieg von vorne zu raten.

2. Grundmetriken: unkomprimiert, gzip und brotli

Der erste Schritt jeder Bundle-Analyse ist die Wahl der richtigen Metrik. Die unkomprimierte Dateigröße zeigt, wie viel Text der Browser parsen muss, während die tatsächliche Übertragungsgröße über das Netzwerk von der verwendeten Kompression abhängt. Gzip komprimiert CSS aufgrund seiner hohen Redundanz an Klassennamen und Selektoren typischerweise auf zehn bis fünfzehn Prozent der Originalgröße, Brotli erreicht oft noch etwas bessere Werte bei ähnlicher Kompressionszeit.

Für eine belastbare Bundle-Analyse sollten alle drei Werte parallel erfasst werden: unkomprimiert für Parse-Zeit-Abschätzungen, gzip als praxisnahe Baseline für die meisten CDN-Konfigurationen, und brotli als Zielwert für moderne Hosting-Umgebungen. Ein CSS-Bundle, das unkomprimiert um zwanzig Prozent wächst, kann nach Kompression trotzdem nur um fünf Prozent wachsen, wenn der Zuwachs aus stark wiederholenden Mustern besteht, die sich gut komprimieren lassen.

# Basic Tailwind bundle analysis: raw, gzip, and brotli size in one command
FILE="dist/styles.css"

RAW=$(wc -c < "$FILE")
GZIP=$(gzip -9 -c "$FILE" | wc -c)
BROTLI=$(brotli -q 11 -c "$FILE" | wc -c)

echo "Raw:    $((RAW / 1024)) KB"
echo "Gzip:   $((GZIP / 1024)) KB"
echo "Brotli: $((BROTLI / 1024)) KB"

3. PostCSS-Reports zur Utility-Verteilung

Ein PostCSS-Plugin wie postcss-reporter in Kombination mit einem eigenen Analyse-Plugin liefert für die Bundle-Analyse tiefere Einblicke als eine reine Dateigröße. Ein solches Plugin kann während der Verarbeitung jede erzeugte CSS-Regel zählen und nach Utility-Gruppen wie Farben, Spacing, Typography oder Layout kategorisieren. So lässt sich schnell erkennen, ob beispielsweise die Farbpalette mit hunderten generierten Opacity-Varianten für einen unverhältnismäßig großen Anteil des Bundles verantwortlich ist.

Für die Bundle-Analyse in bestehenden Projekten empfiehlt sich ein einfaches Node-Skript, das die PostCSS-AST des generierten Stylesheets traversiert und pro Utility-Präfix die Anzahl der Regeln sowie deren kumulierte Zeichenlänge ausgibt. Dieser Report lässt sich in wenigen Minuten selbst schreiben und liefert projektspezifische Erkenntnisse, die generische Analyse-Tools oft nicht abbilden, weil sie Tailwinds Namenskonventionen nicht kennen.

// scripts/analyze-css.mjs — group generated rules by utility prefix
import postcss from "postcss";
import fs from "node:fs";

const css = fs.readFileSync("dist/styles.css", "utf8");
const root = postcss.parse(css);
const groups = new Map();

root.walkRules((rule) => {
  // crude but effective: use the first class segment as the group key
  const match = rule.selector.match(/\.([a-z0-9]+)/i);
  const group = match ? match[1].split("-")[0] : "other";
  const size = rule.toString().length;
  groups.set(group, (groups.get(group) || 0) + size);
});

[...groups.entries()]
  .sort((a, b) => b[1] - a[1])
  .slice(0, 10)
  .forEach(([group, size]) => console.log(`${group}: ${(size / 1024).toFixed(1)} KB`));

4. Source-Map-Explorer für CSS-Bundles

Werkzeuge wie source-map-explorer, ursprünglich für JavaScript-Bundles entwickelt, lassen sich auch für die Bundle-Analyse von CSS einsetzen, sofern der Build-Prozess CSS-Source-Maps erzeugt. Der Vorteil gegenüber reinen Regel-Zählungen: Source-Map-Explorer zeigt an, aus welcher ursprünglichen Quelldatei jede CSS-Regel stammt, nicht nur, zu welcher Utility-Gruppe sie gehört. Das ist besonders in Monorepos hilfreich, in denen mehrere Pakete zum finalen Bundle beitragen.

Für eine aussagekräftige Bundle-Analyse mit Source-Maps muss die PostCSS-Pipeline explizit map: { inline: false } konfigurieren, damit eine separate .css.map-Datei entsteht, die von den Analyse-Tools eingelesen werden kann. In Produktions-Builds sollte diese Source-Map-Generierung deaktiviert bleiben, um keine unnötigen Dateien und keine potenziell sensiblen Pfadinformationen auszuliefern. Sie ist ausschließlich für lokale oder CI-interne Analyse-Läufe gedacht.

# Generate a CSS source map for analysis purposes (dev/CI only, not production)
npx tailwindcss -i ./src/input.css -o ./dist/styles.css --map

# Inspect the resulting bundle with source-map-explorer
npx source-map-explorer dist/styles.css dist/styles.css.map \
  --html dist/bundle-report.html

5. cssnano-Reports und ungenutzte Regeln finden

Der Minifizierer cssnano, der in den meisten Tailwind-Produktions-Pipelines läuft, bietet mit dem --verbose-Modus eigene Statistiken über durchgeführte Optimierungen. Für die Bundle-Analyse ist besonders interessant, wie viele doppelte Selektoren cssnano zusammenführt und wie viele Bytes durch das Entfernen redundanter Deklarationen eingespart werden. Ein hoher Anteil an Duplikaten deutet oft darauf hin, dass mehrere Komponenten dieselben Utility-Kombinationen wiederholt einzeln generieren, statt eine gemeinsame Komponentenklasse zu nutzen.

Zusätzlich zur Minifizierungs-Statistik hilft ein Vergleich zwischen dem theoretischen CSS-Umfang, der bei vollständiger Nutzung aller in der Codebasis referenzierten Utility-Klassen entstünde, und dem tatsächlich generierten Umfang. Größere Abweichungen deuten auf Content-Scanning-Lücken hin, bei denen Klassen zwar im Code stehen, aber aufgrund fehlerhafter Content-Konfiguration nicht erkannt werden. Diese Gegenüberstellung ist ein wichtiger Bestandteil einer vollständigen Bundle-Analyse, weil sie sowohl zu große als auch unerwartet kleine Bundles erklären kann.

6. Visualisierung: Treemaps für Selektor-Gruppen

Zahlen in einer Konsolenausgabe sind für eine schnelle Bundle-Analyse nützlich, aber eine visuelle Treemap-Darstellung macht Größenverhältnisse auf einen Blick erfassbar. Tools wie webpack-bundle-analyzer lassen sich mit einem CSS-zu-JSON-Adapter zweckentfremden, um Utility-Gruppen als proportional große Rechtecke darzustellen. Eine Farbgruppe, die zwanzig Prozent des Bundles ausmacht, fällt in einer Treemap sofort ins Auge, während dieselbe Information in einer Zahlenliste leicht übersehen wird.

Für Teams, die regelmäßig Bundle-Analyse-Reports in Pull Requests posten, lohnt sich die Automatisierung dieser Visualisierung über eine GitHub-Action, die bei jedem Build ein aktuelles Treemap-Bild als Kommentar anhängt. So sehen Reviewer sofort, ob eine Änderung eine neue, unerwartet große Utility-Gruppe einführt, ohne die Analyse manuell anstoßen zu müssen.

// scripts/export-treemap-data.mjs — export grouped sizes as treemap-ready JSON
import fs from "node:fs";

const groups = { colors: 18400, spacing: 9200, layout: 6100, typography: 3400 };

const treemapData = {
  name: "tailwind-bundle",
  children: Object.entries(groups).map(([name, size]) => ({ name, value: size })),
};

fs.writeFileSync("dist/bundle-treemap.json", JSON.stringify(treemapData, null, 2));

7. CI-Budgets: Regressionen automatisch abfangen

Die wertvollste Form der Bundle-Analyse ist keine einmalige Untersuchung, sondern ein kontinuierlich laufendes CI-Budget, das jede Pull-Request-Pipeline gegen einen festgelegten Größenschwellenwert prüft. Überschreitet das generierte CSS diesen Schwellenwert, schlägt die Pipeline fehl und macht das Team auf die Regression aufmerksam, bevor sie in die Produktion gelangt. Ohne ein solches Budget bleiben schleichende Größenzuwächse über viele kleine Commits hinweg oft unbemerkt, bis sie sich zu einem spürbaren Performance-Problem summiert haben.

Ein realistisches CI-Budget für die Bundle-Analyse sollte nicht nur die Gesamtgröße prüfen, sondern auch den prozentualen Zuwachs gegenüber dem letzten Merge in den Hauptbranch. Ein Sprung von fünfzig auf fünfundfünfzig Kilobyte gzip ist meist unproblematisch, während derselbe absolute Zuwachs bei einem ursprünglich zehn Kilobyte großen Bundle ein Alarmsignal darstellt. Prozentuale Schwellenwerte fangen solche relativen Regressionen zuverlässiger ab als starre absolute Grenzen.

# .github/workflows/css-budget.yml — fail the pipeline on CSS size regressions
name: css-budget
on: [pull_request]
jobs:
  bundle-analysis:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: 20 }
      - run: npm ci
      - run: npx tailwindcss -i ./src/input.css -o ./dist/styles.css --minify

      - name: Check gzip size against budget
        run: |
          GZIP_KB=$(gzip -9 -c dist/styles.css | wc -c | awk '{print int($1/1024)}')
          BUDGET_KB=60
          echo "Current gzip size: ${GZIP_KB} KB (budget: ${BUDGET_KB} KB)"
          if [ "$GZIP_KB" -gt "$BUDGET_KB" ]; then
            echo "::error::CSS bundle exceeds budget of ${BUDGET_KB} KB"
            exit 1
          fi

8. Lighthouse CI und reale Ladezeit-Metriken

Reine Dateigrößenmetriken sind für die Bundle-Analyse ein guter Startpunkt, sagen aber nichts über die tatsächliche Auswirkung auf die Nutzererfahrung aus. Lighthouse CI schließt diese Lücke, indem es echte Seitenaufrufe in einer kontrollierten Umgebung simuliert und Metriken wie First Contentful Paint und Largest Contentful Paint erfasst, die direkt von der CSS-Ladezeit beeinflusst werden. Ein wachsendes CSS-Bundle zeigt sich hier nicht als abstrakte Kilobyte-Zahl, sondern als konkrete Millisekunden-Verzögerung beim Rendern.

Die Kombination aus statischer Bundle-Analyse und Lighthouse-CI-Metriken in derselben CI-Pipeline liefert ein vollständigeres Bild: Die statische Analyse erklärt, woher eine Größenänderung kommt, während Lighthouse zeigt, ob diese Änderung tatsächlich spürbar für Nutzer ist. Manche Größenzuwächse, etwa durch zusätzliche, aber selten genutzte Utility-Klassen, wirken sich kaum auf die Ladezeit aus, während andere, etwa durch aufgeblähte kritische Above-the-Fold-Styles, deutlich sichtbare Verzögerungen verursachen.

9. Analyse-Tools im Vergleich

Je nach Projektgröße und Team-Workflow eignen sich unterschiedliche Werkzeuge für die Bundle-Analyse unterschiedlich gut. Die folgende Übersicht ordnet die vorgestellten Ansätze nach Einsatzzweck.

Ein ausgereifter Workflow kombiniert mehrere dieser Werkzeuge: ein schnelles gzip-Skript für tägliche CI-Läufe, die PostCSS-Analyse für tiefere Untersuchungen bei Bedarf, und Lighthouse CI in regelmäßigen Abständen, um die tatsächliche Nutzerauswirkung im Blick zu behalten. Diese Kombination liefert eine vollständige Bundle-Analyse, ohne bei jedem einzelnen Commit die aufwendigste Analyseform auszuführen.

10. Zusammenfassung

Eine vollständige Bundle-Analyse für Tailwind CSS beginnt bei den Grundmetriken, unkomprimiert, gzip und brotli, geht über PostCSS-basierte Utility-Gruppierung und Source-Map-Explorer bis hin zu automatisierten CI-Budgets, die Regressionen frühzeitig abfangen. Wer nur eine einzelne Dateigröße betrachtet, verpasst die Erklärung dafür, warum ein Bundle wächst und ob dieses Wachstum tatsächlich spürbar für Nutzer ist.

Lighthouse CI ergänzt statische Größenmessungen um reale Ladezeit-Metriken und macht damit deutlich, dass nicht jede Kilobyte-Zunahme gleich schwer wiegt. Ein reifer Workflow kombiniert schnelle, tägliche Prüfungen mit tieferen Analysen bei Bedarf und stellt sicher, dass die Bundle-Analyse Teil des normalen Entwicklungsprozesses wird, statt eine seltene, manuelle Notfallmaßnahme zu bleiben.

11. FAQ: Tailwind CSS Bundle-Analyse