Ladezeit halbiert. Vor dem Launch.

Nein, und sei skeptisch gegenüber jedem, der das tut. Lighthouse ist ein synthetischer Test auf einem simulierten Gerät — er bildet nicht ab, was eure echten Nutzer erleben. Wir optimieren auf CrUX-Felddaten (die Metriken, auf die Google rankt) und reporten Lighthouse als sekundäres Signal. Was wir zusichern: messbare, dokumentierte Verbesserung bei LCP, INP und CLS für eure Top-3-Page-Templates.

Sagen wir an Tag 1. Das Audit deckt TTFB und Server-Response-Zeit ab. Wenn euer Bottleneck DB-Queries, langsame APIs oder N+1 sind, bringt Frontend-Optimierung wenig. Wir können den Sprint auf Backend-Perf umlenken — oder empfehlen, zuerst das Backend zu fixen und einen Folge-Sprint zu buchen.

Ja, zu allen vier — sie decken ca. 80 % der DACH-SMB-Websites ab. Die Muster unterscheiden sich (Server-Components bei Next, Twig-Template-Optimierung bei Shopware, Theme-/Plugin-Audit bei WordPress), aber das Ziel ist identisch: weniger JS ausliefern, schnellerer LCP, niedrigerer CLS.

Häufiges Muster. Wir gaten, defern oder ersetzen. Server-seitige Analytics (Plausible, Server-Events) statt Client-GA. Lazy-loaded Chat-Widget. A/B-Test-SDKs ersetzt durch Edge-evaluierte Flags. Trade-offs werden dokumentiert, damit das Marketing-Team nicht überrascht wird.

Ohne Guardrails regredieren sie binnen Wochen — jedes neue Feature bringt JS. Wir installieren ein Performance-Budget in eurer CI (size-limit, Lighthouse CI oder Vercel-Speed-Insights-Gate). Neue PRs, die das Budget reißen, werden geblockt oder gekennzeichnet. Die Übergabe-Doku erklärt die Wartung.

Das ist der ideale Auslöser. Bucht den Sprint so, dass er 1–2 Wochen vor dem Launch endet — das gibt Puffer für Verifikation, Marketing-Generalprobe und Übergabe an euer Team. Den Sprint einen Tag vor dem Launch enden zu lassen, ist ein Stress-Rezept; davon raten wir ab.