Wie streng sollte das Performance-Budget am Anfang sein?

Lieber realistisch und konsequent als ambitioniert und ignoriert. Wenn Ihre Site aktuell bei LCP 2,8 s liegt, ist eine Schwelle von 1,8 s utopisch — sie wird sofort verletzt und das CI-Gate kommentarlos abgeschaltet. Realistischer Startpunkt: aktueller Wert minus 10 Prozent als Schwelle, alle 4 Wochen die Schwelle um weitere 10 Prozent reduzieren bis zum Zielwert. Das Team lernt mit der Zeit, was geht.

Was tun, wenn Stakeholder neue Tracking-Scripts fordern?

Mit Trade-off-Transparenz arbeiten: jedes neue Drittanbieter-Script bekommt eine Performance-Kosten-Schätzung (Lighthouse-Audit auf einem Branch mit dem Script vs. ohne). Wenn das Script 200 kB kostet, ist das eine Geschäftsentscheidung — keine technische. Oft entscheidet sich Marketing dann gegen den fünften Tracking-Pixel.

Hilft ein CDN gegen schlechte Performance?

Ja, aber nur an einer Stelle: Time-to-First-Byte. Ein CDN verkürzt die geografische Latenz zwischen User und Server-Edge — typisch 50–200 ms je nach Distanz. Den eigentlichen Render-Pfad (LCP, INP, CLS) verändert ein CDN nicht. Wer eine schwerfällige Site auf ein CDN packt, hat eine geografisch näher schwerfällige Site.

Sind Server-Components automatisch performanter als Client-Components?

Meist ja. Server-Components rendern auf dem Server, schicken nur HTML — kein JavaScript landet im Bundle für die Komponente. Das spart Initial-JS und reduziert TBT/INP. Aber: Server-Components dürfen keine Interaktivität, kein State, keine Hooks. Wer sie für interaktive Bereiche zwingt, bricht die Funktionalität. Sinnvoll: Layout, statische Inhalte, Daten-Fetching im Server-Component; Buttons, Forms, Animations im Client-Component.

Was ist der häufigste Performance-Killer bei Tailwind-CSS-Sites?

Nicht Tailwind selbst — sondern unbeschnittene Tailwind-Bundles. Default-Tailwind ist ~3 MB. Mit aktiviertem Purge/JIT-Mode aber unter 50 kB für eine typische Site. Wer nicht purgt, schleppt 95 Prozent ungenutzte Klassen mit. Bei Tailwind v4 ist Purge automatisch — Performance-Issue weitgehend gelöst, sofern die Konfiguration nicht zu breit gesetzt ist (Globs auf Build-Output statt Source-Dateien sind ein häufiger Fehler).

Wie messe ich Performance auf einer Site mit Login?

Lighthouse-CI mit Cookie-Auth oder einer mock-Session. In `.lighthouserc.json` lässt sich ein `puppeteerScript` angeben, der vor jedem Run einen Login durchführt und das Cookie setzt. Für SPA-Bereiche hinter Auth: separate Audit-URLs definieren, die mit den eingeloggten Cookies laufen.

Lohnt sich Edge-Functions für statische Marketing-Sites?

Selten. Statische Marketing-Sites profitieren am stärksten von ISR (Incremental Static Regeneration) auf einem CDN — der Output ist HTML, kein Edge-Code-Lauf nötig. Edge-Functions sind interessant für: A/B-Test-Routing, Geo-IP-basiertes Content-Switching, Server-Side-Personalisierung. Für eine klassische Cornerstone-Site mit FAQ-Sektion meist Overkill.

Was kostet Performance-Optimierung als Beratungsdienstleistung?

Initiales Performance-Audit + Optimierung mittelständischer Marketing-Site typisch 3.000–8.000 € — abhängig davon ob ein Re-Build von Hero-Sektionen nötig ist oder nur Konfigurations-Tuning reicht. CI-Setup zusätzlich 800–1.500 €. ROI-Punkt liegt meistens nach 2–4 Monaten, wenn die Site nennenswerten Conversion-relevanten Traffic hat.

← Blog·Web Performance·9. Juni 2026·12 Min Lesezeit

Performance-Budget einhalten — die JS-Diät für Marketing-Sites

Jede zusätzliche Kilobyte JavaScript verzögert Hydration und kostet Conversions. Akamai-Studien dokumentieren rund 7 Prozent Conversion-Verlust pro 100 Millisekunden Mehr-Ladezeit. Ein Performance-Budget zwingt zur Disziplin — wie es realistisch aussieht, welche fünf Hebel das meiste sparen, und wie Sie Lighthouse-CI in den Build einbauen, damit Regressions niemals heimlich live gehen.

Von Andrea Otten·Geschäftsführerin · Tagleuchte

Warum ein Budget den Unterschied macht

Performance ist das Ergebnis von kontinuierlichen Mini-Entscheidungen — nicht eines einmaligen Optimierungs-Sprints. Jede neue Komponente, jede zusätzliche Tracking-Library, jeder Hero-Slider mit voller Bibliotheks-Abhängigkeit erodiert die Performance Schritt für Schritt. Ohne erklärte Schwelle merkt das niemand, bis die Site spürbar langsam ist.

Ein Performance-Budget ist eine schriftlich fixierte Obergrenze für definierte Metriken — typischerweise initial JavaScript, Largest Contentful Paint (LCP), Total Blocking Time (TBT) und Total Page Weight. Jedes Pull-Request, das diese Schwellen verletzt, wird vom CI-System gestoppt — bevor es live geht. Die Entscheidung verlagert sich vom „in 6 Monaten merken wir's“ zum sofortigen Trade-off-Bewusstsein.

Marketing-Sites haben das beste Verhältnis aus Aufwand und Effekt für Budgets, weil sie typisch keine extreme Interaktivität brauchen — kein E-Commerce-Cart-State, kein Real-Time-Dashboard. Das macht aggressive Schwellen realistisch.

Realistisches Budget für Marketing-Sites

Werte, die wir bei mittelständischen Marketing-Sites als Hard-Limits setzen. Drei Stufen: ambitioniert, realistisch, akzeptabel — letzteres ist die rote Linie, ab der das Build-System bricht.

Metrik	Ambitioniert	Realistisch	Hart-Limit
LCP (Mobile)	< 1,5 s	< 2,0 s	< 2,5 s
INP	< 100 ms	< 200 ms	< 500 ms
CLS	< 0,03	< 0,05	< 0,1
Initial JS (gzip)	< 80 kB	< 130 kB	< 170 kB
Total Page Weight	< 600 kB	< 1 MB	< 1,5 MB
Hero-Image (mobile)	< 60 kB AVIF	< 100 kB	< 200 kB
Web-Fonts (gesamt)	< 50 kB	< 80 kB	< 120 kB

Die fünf Hebel mit dem meisten Effekt

Sortiert nach Impact pro Aufwand. Wer einen einzigen Hebel umsetzt: Hero-Bild als priority + AVIF. Spart auf vielen Sites 1–2 Sekunden LCP in einem Atemzug.

01
Hero-Image als next/image priority + AVIF
Das LCP-Element ist auf 70–80 Prozent der Marketing-Sites das große Hero-Bild. Mit AVIF statt JPEG/PNG sparen Sie 30–50 Prozent Dateigröße bei gleicher visueller Qualität. `priority`-Flag in next/image triggert Preloading. Sizes-Property korrekt setzen, damit kein 4000-px-Bild für ein 600-px-Container ausgeliefert wird. Ergebnis: 800–1500 ms LCP-Verbesserung auf vielen Sites.
02
JavaScript-Bundle aggressiv tree-shaken
Barrel-Exports (`import { Foo } from 'lib'`) ziehen oft die ganze Library mit, selbst wenn nur eine Funktion benutzt wird. lucide-react und ähnliche Icon-Libraries können dadurch 80–200 kB ungebundenen JS-Ballast bringen. In Next.js mit `experimental.optimizePackageImports` als Liste explizit auflisten — Tree-Shaking funktioniert dann pro Symbol. Pro Library typisch 20–80 kB Initial-JS-Einsparung.
03
Web-Fonts self-hosten + display:swap + variable Fonts
Google-Fonts-CDN ist langsamer als ein eigener Server (zusätzlicher DNS-Lookup, Cross-Origin-Connection) und außerdem DSGVO-Risiko. `next/font/local` mit Variable-Fonts: ein Datei pro Family statt vier (Regular, Medium, Semibold, Bold). `display: swap` verhindert FOIT (Flash of Invisible Text). Nur die zwei kritischsten Weights preloaden. Resultat: 100–300 ms LCP-Verbesserung plus DSGVO-Compliance ohne Cookie-Banner-Gymnastik.
04
Drittanbieter-Scripts deferred laden
Tag-Manager, Analytics, Chat-Widget, Cookie-Banner — alle laden gerne synchron im Head und blockieren dadurch den Critical-Path. Defer-Strategy: gtag und Co. nach `load`-Event, Chat-Widget nach 5 s Idle, Cookie-Banner-Bibliothek nur falls Banner überhaupt gerendert wird. Pro deferreten Script typisch 50–200 ms Time-to-Interactive-Verbesserung.
05
Layout-Shift-Quellen rigoros eliminieren
Bilder ohne `width`/`height`, Embeds ohne Aspect-Container, dynamisch nachgeladener Content über bereits sichtbarem Inhalt, Cookie-Banner der nach Page-Load Layout pusht — alle vier sind häufige CLS-Quellen. Lösung: jeder Bild-Tag bekommt explizite Dimensions oder CSS aspect-ratio. Embeds in fixe Aspect-Container. Skeleton-States statt nachträglicher Inserts. Cookie-Banner als Overlay (Position: fixed), nie Layout-pushend.

Lighthouse-CI in den Build einbauen

Ohne CI-Gate ist das Performance-Budget eine schöne Tabelle, die niemand einhält. Lighthouse-CI bricht den Build, wenn definierte Schwellen verletzt werden — das schafft die Disziplin.

Setup mit GitHub Actions

GitHub Actions installiert Lighthouse-CI per `npx lhci autorun`, das eine Konfigurations-Datei `.lighthouserc.json` liest. Drei Sektionen: `collect` definiert welche URLs gegen welche Schwellen laufen, `assert` definiert die Schwellen, `upload` pusht Reports an einen Lighthouse-Server oder GitHub-Storage.

Pro Pull-Request läuft der Job: lighthouse fährt die definierten URLs gegen jeweils 3 Runs ab (gemittelt für Robustheit gegen Network-Jitter), vergleicht gegen die Asserts, und postet den Report als Kommentar zurück.

Welche URLs ins CI-Gate gehören

Drei reichen für die meisten Marketing-Sites: Homepage, eine Cornerstone (z. B. die wichtigste Service-Seite), eine Detail-Seite (Blog-Artikel oder Case-Study). Mehr URLs verlängern Build-Zeit ohne entsprechenden Erkenntnisgewinn — Performance-Probleme treten meist sektion-weit auf, nicht pro Einzel-URL.

Wichtig: Die URLs werden auf dem Vercel-Preview-Build geprüft, nicht auf Production. Vercel gibt jedem PR einen eigenen Preview-Deploy mit eindeutiger URL — Lighthouse-CI nimmt diese URL und checkt dort.

Wann das Gate brechen darf

Performance-Regressions sollen den Build immer brechen — keine Ausnahmen, keine `--allow-fail`. Sonst gewöhnt sich das Team daran, das Gate zu ignorieren, und es ist sinnlos. Wenn ein PR die Schwelle wirklich verletzen muss (z. B. neue große Library mit Geschäftswert), wird die Schwelle bewusst diskutiert und in einem separaten Commit in der `.lighthouserc.json` angepasst.

Real-User-Monitoring danach

Lab-Daten (Lighthouse) und Field-Daten (echte User) divergieren oft. Field-Daten sind, was Google für Rankings nutzt — daher in Production kontinuierlich messen.

01web-vitals-Library installieren — Google's offizielle Library, ~3 kB gzipped, misst LCP, INP, CLS aus realen User-Sessions und schickt sie an einen Endpoint Ihrer Wahl. Plausible, Umami, GA4 oder ein eigener Endpoint — egal.
02Search Console — Core-Web-Vitals-Bericht — Aggregiert die Field-Daten aller URLs einer Property. Zeigt schwache URL-Cluster auf, die im PSI-Einzeltest nicht auffallen würden. Wöchentliche Stichprobe reicht für die meisten Sites.
03Alerting bei Regressions — Wenn LCP auf einem URL-Cluster über 2 Wochen mehr als 15 Prozent steigt: Slack/Mail-Alert. Verhindert, dass schleichende Performance-Drift wochenlang unentdeckt bleibt — die häufigste Form von Performance-Regression.
04PageSpeed-Insights als Cross-Check — Monatlich für die Top-5-URLs prüfen. PSI nutzt CrUX-Felddaten der letzten 28 Tage und gibt einen anderen Blickwinkel als ein Live-Lab-Test. Inkonsistenzen zwischen PSI und web-vitals-Library deuten meist auf Bot-Traffic-Verzerrung in einer der beiden Quellen hin.

Quellen & weiterführend

Häufige Fragen zu Web Performance

Wie streng sollte das Performance-Budget am Anfang sein?
Lieber realistisch und konsequent als ambitioniert und ignoriert. Wenn Ihre Site aktuell bei LCP 2,8 s liegt, ist eine Schwelle von 1,8 s utopisch — sie wird sofort verletzt und das CI-Gate kommentarlos abgeschaltet. Realistischer Startpunkt: aktueller Wert minus 10 Prozent als Schwelle, alle 4 Wochen die Schwelle um weitere 10 Prozent reduzieren bis zum Zielwert. Das Team lernt mit der Zeit, was geht.
Was tun, wenn Stakeholder neue Tracking-Scripts fordern?
Mit Trade-off-Transparenz arbeiten: jedes neue Drittanbieter-Script bekommt eine Performance-Kosten-Schätzung (Lighthouse-Audit auf einem Branch mit dem Script vs. ohne). Wenn das Script 200 kB kostet, ist das eine Geschäftsentscheidung — keine technische. Oft entscheidet sich Marketing dann gegen den fünften Tracking-Pixel.
Hilft ein CDN gegen schlechte Performance?
Ja, aber nur an einer Stelle: Time-to-First-Byte. Ein CDN verkürzt die geografische Latenz zwischen User und Server-Edge — typisch 50–200 ms je nach Distanz. Den eigentlichen Render-Pfad (LCP, INP, CLS) verändert ein CDN nicht. Wer eine schwerfällige Site auf ein CDN packt, hat eine geografisch näher schwerfällige Site.
Sind Server-Components automatisch performanter als Client-Components?
Meist ja. Server-Components rendern auf dem Server, schicken nur HTML — kein JavaScript landet im Bundle für die Komponente. Das spart Initial-JS und reduziert TBT/INP. Aber: Server-Components dürfen keine Interaktivität, kein State, keine Hooks. Wer sie für interaktive Bereiche zwingt, bricht die Funktionalität. Sinnvoll: Layout, statische Inhalte, Daten-Fetching im Server-Component; Buttons, Forms, Animations im Client-Component.
Was ist der häufigste Performance-Killer bei Tailwind-CSS-Sites?
Nicht Tailwind selbst — sondern unbeschnittene Tailwind-Bundles. Default-Tailwind ist ~3 MB. Mit aktiviertem Purge/JIT-Mode aber unter 50 kB für eine typische Site. Wer nicht purgt, schleppt 95 Prozent ungenutzte Klassen mit. Bei Tailwind v4 ist Purge automatisch — Performance-Issue weitgehend gelöst, sofern die Konfiguration nicht zu breit gesetzt ist (Globs auf Build-Output statt Source-Dateien sind ein häufiger Fehler).
Wie messe ich Performance auf einer Site mit Login?
Lighthouse-CI mit Cookie-Auth oder einer mock-Session. In `.lighthouserc.json` lässt sich ein `puppeteerScript` angeben, der vor jedem Run einen Login durchführt und das Cookie setzt. Für SPA-Bereiche hinter Auth: separate Audit-URLs definieren, die mit den eingeloggten Cookies laufen.
Lohnt sich Edge-Functions für statische Marketing-Sites?
Selten. Statische Marketing-Sites profitieren am stärksten von ISR (Incremental Static Regeneration) auf einem CDN — der Output ist HTML, kein Edge-Code-Lauf nötig. Edge-Functions sind interessant für: A/B-Test-Routing, Geo-IP-basiertes Content-Switching, Server-Side-Personalisierung. Für eine klassische Cornerstone-Site mit FAQ-Sektion meist Overkill.
Was kostet Performance-Optimierung als Beratungsdienstleistung?
Initiales Performance-Audit + Optimierung mittelständischer Marketing-Site typisch 3.000–8.000 € — abhängig davon ob ein Re-Build von Hero-Sektionen nötig ist oder nur Konfigurations-Tuning reicht. CI-Setup zusätzlich 800–1.500 €. ROI-Punkt liegt meistens nach 2–4 Monaten, wenn die Site nennenswerten Conversion-relevanten Traffic hat.

Wir helfen bei Web Performance mit ehrlicher Einschätzung.

Schriftliche Einschätzung in zwei Werktagen — kostenlos, ohne Verkaufsgespräch.

Erstanalyse anfordernhallo@tagleuchte.de