Performance ist eine Zahl in der GuV, keine Zeile im Lasttest-Report. Wer Core Web Vitals als Frontend-Detail behandelt, das die Entwickler schon irgendwie hinbekommen, verschenkt zwei Dinge gleichzeitig: Sichtbarkeit bei Google und Conversion im Funnel. Beides lässt sich in Euro beziffern, und genau deshalb gehört das Thema auf die Entscheiderebene und nicht in ein Jira-Backlog.
Der Grund, warum das gerade jetzt relevant ist: Die Metriken haben sich verschoben. Seit März 2024 misst Google nicht mehr nur, wie schnell eine Seite reagiert, wenn man sie zum ersten Mal antippt, sondern wie reaktiv sie über die gesamte Sitzung bleibt. Gleichzeitig hat sich die Frontend-Architektur weiterentwickelt: Server Components und inkrementelles Rendering verschieben die Last weg vom Browser. Wer heute eine Plattform-Entscheidung trifft, entscheidet mit über die Performance-Decke, die das Projekt jemals erreichen kann. Diese Decke lässt sich später kaum noch anheben.
Warum Core Web Vitals Umsatz sind und nicht nur Technik
Core Web Vitals übersetzen ein subjektives Gefühl – "die Seite fühlt sich langsam an" – in drei messbare Größen, die Google aus echten Nutzerdaten erhebt. LCP (Largest Contentful Paint) misst, wann der größte sichtbare Inhalt geladen ist; gut ist alles unter 2,5 Sekunden. INP (Interaction to Next Paint) misst die Reaktionslatenz bei Interaktionen über die gesamte Sitzung; gut ist alles unter 200 Millisekunden. CLS (Cumulative Layout Shift) misst das visuelle Verrutschen des Layouts; gut ist alles unter 0,1. Gemessen wird am 75. Perzentil und getrennt nach Mobile und Desktop. Das ist wichtig, weil Ihre Desktop-Werte im Büro Sie über ein schlechtes Mobilerlebnis hinwegtäuschen können.
Der entscheidende Punkt für die Vorstandsetage: Diese Zahlen korrelieren mit Geschäftskennzahlen. Die von Google beauftragte und von 55 und Deloitte durchgeführte Studie Milliseconds Make Millions untersuchte Ende 2019 über 30 Millionen Sessions auf 37 Marken-Sites. Eine Verbesserung der Ladezeit um 0,1 Sekunden korrelierte im Retail mit +8,4% Conversion und +9,2% durchschnittlichem Bestellwert, im Travel-Segment mit +10,1% Conversion. Pinterest berichtete nach einem Performance-Rebuild von +15% Signup-Conversion und +15% SEO-Traffic – laut eigenem Engineering-Blog der größte User-Acquisition-Gewinn des Teams in jenem Jahr.
Diese Zahlen sind belastbar genug, um eine Investition zu begründen, aber sie sind keine Naturgesetze. Dazu später mehr. Für den Moment reicht die Einordnung: Performance ist ein Hebel mit messbarer Wirkung auf zwei Umsatztreiber – Sichtbarkeit und Abschluss.
INP hat FID abgelöst: Was sich seit 2024 geändert hat
Wer noch mit dem mentalen Modell von 2023 arbeitet, optimiert die falsche Metrik. Am 12. März 2024 hat Google INP offiziell zum Core Web Vital gemacht und damit FID (First Input Delay) ersetzt. Der Unterschied ist nicht kosmetisch. FID maß nur die Verzögerung der allerersten Interaktion – ein gnädiger, fast immer grüner Wert. INP misst die Reaktionslatenz über alle Interaktionen einer Sitzung und nimmt einen der schlechtesten Werte. Das deckt genau die Frustration auf, die Nutzer real erleben: Der zehnte Klick im Checkout, der hängt, nicht der erste.
Für Architekturentscheidungen heißt das: JavaScript, das den Main Thread blockiert, wird teurer. Jede schwere Client-seitige Berechnung, jeder überdimensionierte State-Manager, jede Hydration eines ganzen Seitenbaums schlägt jetzt sichtbar auf INP durch. Das ist der Grund, warum Architekturen, die weniger JavaScript an den Browser senden, struktureller im Vorteil sind. Nicht, weil sie modern sind, sondern weil sie weniger Arbeit in den Main Thread legen, der INP bestimmt.
Diese Verschiebung ist auch eine Warnung an alle, die ihre Performance-Werte vor März 2024 abgenommen haben. Eine Seite, die unter FID grün war, kann unter INP rot sein. Wer seitdem nicht neu gemessen hat, kennt seinen tatsächlichen Stand nicht. Und Google misst kontinuierlich aus dem Chrome User Experience Report mit – Sie sehen die Verschlechterung also nicht, bevor sie im Ranking ankommt.
Wie Next.js Server Components die Ausgangsbedingungen verbessern
Hier wird die Plattform-Entscheidung konkret. Die meisten Performance-Probleme entstehen, weil zu viel JavaScript an den Browser geht und dort interpretiert, ausgeführt und hydratisiert werden muss. Genau an diesem Punkt setzen React Server Components in Next.js an. Komponenten rendern standardmäßig auf dem Server; nur was explizit mit 'use client' markiert ist, landet samt seinem Import-Graph im Client-Bundle. Die Next.js-Dokumentation belegt explizit eine Verbesserung des First Contentful Paint, weil weniger JavaScript gesendet wird. Weniger Client-JavaScript ist die direkteste Hebelwirkung auf INP, die eine Architektur bieten kann.
Dazu kommt ISR (Incremental Static Regeneration). Statt jede Anfrage live zu rendern, liefert Next.js für die meisten Requests vorgerenderte statische Seiten aus und regeneriert sie im Hintergrund nach dem stale-while-revalidate-Muster: Der Nutzer bekommt die fertige Seite sofort, die Aktualisierung passiert asynchron. Das senkt die Serverlast und stabilisiert den LCP, weil die teure Render-Arbeit nicht im kritischen Pfad des Nutzers liegt. Cache-Control-Header werden automatisch gesetzt; das Cache-Verhalten lässt sich über den x-nextjs-cache-Header beobachten.
Wie weit das trägt, zeigt der Skalierungsfall: Für Sites mit Millionenpublikum ist genau diese Kombination aus Vorrendern und schlankem Client-Bundle der Grund, warum ein Stack aus Sanity und Next.js Millionen Besucher ohne Performance-Einbruch bedient. Und weil Google am Mobile-Perzentil misst, zahlt jede dieser Optimierungen direkt auf die Werte ein, die ranken – ein Argument, das eng mit konsequentem Mobile-First-Design zusammenhängt. Die next/image-Optimierung läuft dabei auch self-hosted mit Zero-Config über next start und liefert per Default moderne Formate und passende Bildgrößen – der häufigste einzelne LCP-Killer, der hier ab Werk adressiert ist.
Der unbequeme Punkt: Next.js macht gute Werte möglich, nicht automatisch
Jetzt der Teil, den Ihnen ein Dienstleister, der Next.js verkaufen will, ungern sagt. Das Framework ist eine Voraussetzung, keine Garantie. Falsch eingesetzt ist eine Next.js-Seite so langsam wie jede andere – manchmal langsamer, weil das Framework-Gewicht hinzukommt.
Die typischen Fehler sind bekannt und wiederholen sich in jedem Audit. Ein Team markiert zu viel mit 'use client' und schiebt damit halbe Seitenbäume ins Client-Bundle, womit der Server-Component-Vorteil verpufft. Es baut Render-Wasserfälle, bei denen eine Datenabfrage auf die nächste wartet, statt parallel zu laden, und treibt so den LCP nach oben. Es bindet ungeprüfte Bilder ein, statt die Bild-Optimierung zu nutzen. Es zieht eine schwere Client-seitige State-Bibliothek ein, wo Server-State gereicht hätte, und blockiert den Main Thread – mit direktem Schaden am INP. Next.js verhindert keinen dieser Fehler. Es macht sie nur leichter vermeidbar, wenn das Team weiß, was es tut.
Und dann die Studien. Die berühmte Faustregel "Amazon: 100 ms Verzögerung kosten 1% Umsatz" hat keine offizielle Amazon-Quelle. Sie stammt aus einer Stanford-Präsentation eines Ex-Engineers von 2006 – rund zwanzig Jahre alt und kontextabhängig. Die oft zitierten Walmart-Zahlen stammen aus einer Velocity-Präsentation von 2012, nur über Sekundärquellen belegt. Selbst die Deloitte/Google-Uplifts von Ende 2019 sind branchenspezifische Korrelationen, kein universelles Gesetz "0,1 Sekunde = +X% überall". Wer diese Zahlen als feststehende Kausalregel im Vorstand präsentiert, wird beim ersten kritischen CFO entzaubert. Zitieren Sie sie als Größenordnung mit Datum und Vertikal-Kontext. Das ist seriöser und hält im Zweifel.
Der ehrliche Zielkonflikt: Performance ist nur ein Faktor
Eine These ist nur dann etwas wert, wenn sie ihre eigene Grenze kennt. Hier ist die Grenze: Core Web Vitals sind ein Rankingfaktor unter vielen, und sie korrelieren nicht eins zu eins mit Umsatz. Google selbst stellt in der Search-Dokumentation klar, dass es kein eigenständiges Boost-Signal gibt und Relevanz sowie Content-Qualität primär bleiben. Ein perfekter LCP rettet kein schwaches Angebot, keinen verwirrenden Funnel und keine Seite, die das Falsche verkauft.
Das relativiert die Investition nicht, es schärft sie. Performance ist Hygiene, kein Wachstumshebel im luftleeren Raum. Bei zwei inhaltlich gleichwertigen Seiten gibt das Page-Experience-Signal den Ausschlag; bei einer schlechten Seite ändert die schnellste Ladezeit nichts. Der ehrliche Rahmen lautet deshalb: Erst muss das Angebot stimmen, dann der Funnel, dann zahlt Performance auf beides ein. In dieser Reihenfolge.
Wer das umdreht und die letzten 100 Millisekunden optimiert, während der Checkout drei überflüssige Pflichtfelder hat, betreibt Mikro-Optimierung am falschen Ende. Die richtige Frage im Lenkungskreis ist nicht "wie schnell sind wir", sondern "wo im Funnel kostet uns Langsamkeit konkret Abschlüsse". Diese Frage führt zu priorisierten, begründbaren Investitionen statt zu einem grünen Lighthouse-Score als Selbstzweck. Es gibt im Übrigen auch Fälle, in denen Next.js die falsche Wahl ist: Eine reine Content-Site ohne Interaktivität trägt Framework-Gewicht, das ein leichteres Setup nicht hätte.
Was Performance über die Zeit kostet und einbringt
Die TCO-Perspektive fehlt in den meisten Performance-Diskussionen, gehört aber genau dort hin. Performance ist kein einmaliges Projekt, sondern ein Betriebszustand, der gepflegt werden muss. Jedes neue Feature, jedes Tracking-Skript der Marketing-Abteilung, jede eingebundene Drittanbieter-Komponente kann die Werte verschlechtern. Ohne kontinuierliches Monitoring aus echten Nutzerdaten merken Sie die Verschlechterung erst, wenn das Ranking nachgibt – und dann ist die Erholung teuer.
Auf der Architekturseite gilt eine Faustregel, die wir in eigenen Projekten konsistent sehen: Eine saubere Erstimplementierung ist eine Investition, die sich über die Laufzeit auszahlt, weil die Performance-Decke hoch liegt und Optimierungen billig bleiben. Eine schlampige Implementierung verschiebt die Kosten nach hinten, wo sie als technische Schuld mit Zinsen anfallen. Wer den Unterschied in Zahlen sehen will, findet die Logik im TCO-Vergleich zwischen einem klassischen CMS und einem Sanity-plus-Next.js-Stack durchgerechnet.
Der Betriebsaufwand für ein gut gebautes self-hosted Setup liegt erfahrungsgemäß bei wenigen Stunden im Monat für Updates, Monitoring und Backups. Das ist überschaubar gegenüber dem, was schlechte Performance auf der Umsatzseite kostet, wenn die Größenordnungen der Studien auch nur ansatzweise auf Ihr Geschäft zutreffen. Die Rechnung geht selten knapp aus.
Was ich Entscheidern rate
Behandeln Sie Performance als Geschäftsgröße mit eigenem Reporting, nicht als Frontend-Nebenprodukt. Lassen Sie sich die Core Web Vitals Ihrer wichtigsten Funnel-Seiten aus echten Nutzerdaten zeigen, getrennt nach Mobile und Desktop, am 75. Perzentil – und nicht den geschönten Lighthouse-Score vom Entwickler-Laptop. Wenn die Mobile-Werte rot sind, haben Sie ein quantifizierbares Umsatzproblem, kein Technik-Detail.
Bei der Plattform-Wahl wählen Sie eine Architektur, die wenig JavaScript an den Browser sendet und vorrendern kann. Next.js mit Server Components und ISR ist dafür eine der stärksten verfügbaren Ausgangsbedingungen – aber bestehen Sie darauf, dass das Team weiß, wo 'use client' hingehört und wo nicht. Die ausführliche Architektur-Argumentation, warum dieser Stack als Performance-Fundament taugt, finden Sie auf unserer Next.js-Pillarseite. Die Plattform allein kauft Ihnen nichts. Das Können des Teams, das sie einsetzt, entscheidet, ob die Decke erreicht wird.
Und behalten Sie die Reihenfolge im Kopf: Angebot, Funnel, dann Performance. Wer sie umdreht, optimiert Millisekunden an einer Seite, die aus anderen Gründen nicht verkauft. Wer sie einhält, verwandelt Performance in genau das, was sie sein sollte – einen messbaren Beitrag zum Umsatz, den Sie vor jedem CFO verteidigen können.
