Seit Jahren reden alle von Page Speed. Trotzdem sehen wir in Audits immer wieder dieselben Muster: großartiges Design, tolle Copy – und eine Lighthouse-Realität, die bei mobilen Nutzern gnadenlos zuschlägt.
Google bewertet das Erlebnis heute über die Core Web Vitals messbar. Für euch bedeutet das: Technik ist kein „nice to have“, sondern Ranking- und Conversion-Faktor. Hier ist, was wirklich zählt – und wie wir das in Next.js 15 pragmatisch lösen.
LCP, INP, CLS – kurz und ohne Marketing-Deutsch
LCP (Largest Contentful Paint)
LCP misst, wann das größte sichtbare Inhaltselement im Viewport fertig gerendert ist – oft ein Hero-Bild, eine große Überschrift oder ein Video-Poster.
Wenn euer LCP bei 3–4 Sekunden liegt, fühlt sich die Seite „kaputt“ an, bevor der Nutzer überhaupt zu lesen beginnt. Für Google ist das ein klares Signal für schlechte UX.
INP (Interaction to Next Paint)
Früher hieß das ähnliche Thema „FID“. Heute ist INP der Maßstab: Wie lange braucht die Seite nach einer Interaktion (Klick, Tippen), bis der Browser das nächste sichtbare Update malt?
Schwere JavaScript-Bundles, blockierende Main-Thread-Arbeit und schlechte Event-Handler machen INP kaputt – oft ohne dass es „optisch“ auffällt.
CLS (Cumulative Layout Shift)
CLS sind die nervigen Layout-Sprünge: Banner lädt nach, Fonts tauschen, Bilder pushen Text. Nutzer klicken daneben, Formulare springen – und Google notiert mit.
CLS ist oft der Vital, den man mit konsequenter Platzierung und Font-Disziplin am schnellsten in den Griff bekommt.
Warum Next.js 15 ein starkes Ausgangsfeld ist – aber kein Automatismus
Next.js gibt euch ein moderne Architektur mit Server Components, Streaming und intelligentem Routing. Das hilft beim ersten Byte und bei der Arbeit, die ihr nicht unnötig auf den Client schiebt.
Trotzdem sehen wir häufig:
- Zu viele
"use client"-Komponenten hoch oben im Tree - Unoptimierte Bilder und layout shift durch fehlende Dimensionen
- Drittanbieter-Scripts, die vor dem eigentlichen Content laufen
Das Framework löst keine Performance-Probleme, die ihr architektonisch einbaut.
Konkrete Hebel für euer nächstes Projekt
1. Den kritischen Rendering-Pfad entschlacken
Fragt bei jeder neuen Bibliothek: Brauchen wir das auf der Startseite? Oft lässt sich Analytics, Chat oder A/B-Tools später laden – ohne dass der Nutzer einen Unterschied merkt.
In Next entscheidet die Server-vs.-Client-Grenze, wie viel Arbeit im Browser überhaupt anfällt.
2. Bilder: das klassische LCP-Killer-Thema
Größe, Format (webp/avif wo möglich), sizes korrekt setzen und priorities dort geben, wo der LCP liegt.
Wenn euer Hero-Bild ohne feste Platzhalterflächen rendert, bestraft euch CLS genauso wie ein langsames LCP.
3. Fonts: weniger Drama, weniger Shift
Nutzt font-display: swap bewusst und stellt sicher, dass Fallback und Webfont möglichst ähnliche Metriken haben – oder ihr geht den Weg über eingebaute Font-Optimization aus next/font, die wir ohnehin stark bevorzugen.
4. Daten und Struktur: schnelle HTML-Antwort
Was der Server kann, soll er tun: Daten holen, HTML bauen, Stream dort, wo es sinnvoll ist. Weniger Hydration auf dem ersten Screen bedeutet oft besseres INP später.
5. Monitoring: Lab vs. Field
Lighthouse und PageSpeed Insights sind Lab-Daten. Echte Nutzerdaten aus Chrome UX Report / RUM (z. B. über euer Hosting oder Analytics-Anbindungen) zeigen oft eine andere Realität – gerade mobil.
Wenn beides auseinanderläuft, optimiert ihr gegen das falsche Bild.
Fazit: Performance als Produktgewohnheit – nicht als einmaligen „SEO-Auftrag“
Core Web Vitals sind kein Zufallsprodukt aus „ein bisschen weniger Bilder laden“. Sie entstehen, wenn Design, Frontend-Architektur und Messung zusammenspielen.
Wenn ihr mit Next.js 15 ohnehin moderne Grundlagen habt: nutzt diese Architektur konsequent und lasst nicht wieder jede dritte Marketing-Library ohne Review in den Head.
Wollen wir gemeinsam euer Setup messen und priorisieren? Im Projekt läuft das bei uns ohne PowerPoint-Bingo: konkrete Metriken, konkrete Tickets, konkrete Ergebnisse.