Next.js Performance Lighthouse 95+ erzielen

Konkrete Techniken für maximale Next.js-Performance: LCP unter 1 Sekunde, CLS nahe null, INP unter 50ms. Mit diesen Methoden erreichen unsere Projekte dauerhaft Lighthouse-Scores über 95.

Core Web Vitals verstehen

Googles Core Web Vitals sind die entscheidenden Performance-Metriken für SEO und Nutzererfahrung: LCP (Largest Contentful Paint): Wie lange dauert es, bis das größte sichtbare Element der Seite geladen ist? Ziel: unter 2,5 Sekunden, ideal unter 1 Sekunde. INP (Interaction to Next Paint): Wie schnell reagiert die Seite auf Nutzereingaben? Ziel: unter 200ms, ideal unter 50ms. CLS (Cumulative Layout Shift): Wie stark verschieben sich Elemente beim Laden? Ziel: unter 0,1, ideal 0,02 oder weniger. Next.js bietet von Haus aus bessere Voraussetzungen für alle drei Metriken als WordPress oder klassische SPAs — aber falsche Implementierungen können diese Vorteile zunichte machen.

Google nutzt Core Web Vitals als Ranking-Faktor. Seiten mit guten Vitals ranken durchschnittlich 15–25 % besser als vergleichbare Seiten mit schlechten Vitals.

Bildoptimierung mit next/image

Bilder sind der häufigste LCP-Killer. Next.js `<Image>` löst die meisten Probleme automatisch: Automatische WebP/AVIF-Konvertierung: Next.js liefert Bilder im besten Format, das der Browser unterstützt. AVIF ist 40–60 % kleiner als JPEG bei gleicher Qualität. Lazy Loading: Bilder unterhalb des Viewports laden erst, wenn der Nutzer scrollt. Setzt `loading="lazy"` korrekt. Priority-Flag für LCP-Bilder: Das Hauptbild (oft Hero-Bild) sollte `priority` haben, damit es früh geladen wird. Fehlt dieses Flag, ist das eine häufige LCP-Ursache. Feste Dimensionen: Immer `width` und `height` setzen, um CLS durch nachlaufende Bilder zu verhindern. Blur-Placeholder: `placeholder="blur"` zeigt einen verschwommenen Platzhalter beim Laden und verhindert visuelle Sprünge.

Häufiger Fehler: Das Hero-Bild ohne priority-Flag. Fügen Sie priority zu allen Bildern above-the-fold hinzu — das verbessert LCP oft um 0,5–1,5 Sekunden.

Richtige Rendering-Strategie wählen

Next.js bietet mehrere Rendering-Modi — die falsche Wahl kostet Performance: Static Generation (SSG): Seiten werden zur Build-Zeit gerendert und als statische HTML-Dateien ausgeliefert. Schnellste mögliche Ladezeit. Geeignet für Seiten, die sich selten ändern (Landingpages, Blog-Posts). Incremental Static Regeneration (ISR): Statische Seiten werden im Hintergrund erneuert. Ideal für Seiten, die sich gelegentlich ändern (Produktseiten, News). `revalidate`-Parameter steuert die Update-Frequenz. Server-Side Rendering (SSR): Seiten werden bei jedem Request gerendert. Nötig für personalisierte Inhalte, aber langsamer. Vorsicht: SSR für alles ist ein häufiger Performance-Fehler. React Server Components (RSC): Mit dem App Router können Komponenten serverseitig rendern — ohne JavaScript an den Client zu schicken. Reduziert Bundle-Size und verbessert INP.

Performance-Probleme in Ihrem Next.js-Projekt?

Schriften und externe Scripts optimieren

next/font für Google Fonts Nie Google Fonts direkt via CDN einbinden. `next/font/google` lädt Fonts lokal und eliminiert den Netzwerk-Request zu Googles Servern — spart 200–500ms und verbessert den Datenschutz. next/script für externe Skripte Analytics, Chat-Widgets, A/B-Testing-Tools — alle mit `<Script strategy="afterInteractive">` oder `"lazyOnload"` einbinden. Niemals externe Skripte direkt im `<head>` ohne Next.js-Script-Komponente einbinden. Bundle-Analyse `@next/bundle-analyzer` zeigt, welche Abhängigkeiten den Bundle groß machen. Typische Problemkandidaten: moment.js (tree-shakeable Alternative: date-fns), lodash (native Alternativen nutzen), große Icon-Libraries (nur benötigte Icons importieren).

Caching und Deployment-Optimierungen

Full-Route Cache Der Next.js App Router cached Server-Component-Ausgaben automatisch. Das Data Cache-System steuert, wann API-Antworten ungültig werden. Korrekte `cache` und `revalidate`-Konfiguration ist entscheidend. Next.js Middleware Für schnelles Geo-Routing, Authentifizierungs-Checks und A/B-Tests: Next.js Middleware läuft serverseitig und fügt minimale Latenz hinzu. CDN-Konfiguration Bei Deployment auf Hetzner Cloud: Cloudflare als CDN konfigurieren, Cache-Control-Header für statische Assets auf 1 Jahr setzen. DSGVO-konform und kosteneffizient. Lighthouse CI einrichten Performance-Budgets in GitHub Actions: Jeder Pull Request muss einen Mindest-Lighthouse-Score erreichen. Regressionen werden verhindert, bevor sie in Produktion gelangen.

Häufig gestellte Fragen

Alles über 90 gilt als gut, über 95 als sehr gut. Unsere Projekte erzielen regelmäßig 95–100. Ein Score unter 70 deutet auf strukturelle Performance-Probleme hin, die durch gezielte Optimierung behebbar sind.

Next.js ist kein Garant für Performance — falsche Implementierungen können die Vorteile zunichte machen. Häufige Ursachen: fehlende priority-Flags bei Bildern, zu viele Client-Components statt Server Components, externe Skripte blockieren das Rendering, schlechte Datenbankabfragen bei SSR.

Ein grundlegender Performance-Audit mit Verbesserungsempfehlungen dauert 2–4 Stunden. Ein vollständiger Audit mit Implementierung der Verbesserungen nimmt je nach Projektgröße 1–5 Tage in Anspruch.

Ja, das ist durch zahlreiche Studien belegt. Google und Amazon haben gezeigt: 100ms mehr Ladezeit bedeuten 1 % weniger Konversionen. Eine Seite, die 1 Sekunde schneller lädt, konvertiert typischerweise 2–5 % besser.

Ein Performance-Audit kostet 490–990 €. Die Implementierung der identifizierten Verbesserungen hängt vom Umfang ab: 1.000–5.000 € für typische Projekte. Oft sind aber 20 % der Maßnahmen für 80 % der Performance-Verbesserung verantwortlich.