Jeder redet über PageSpeed. Aber die meisten optimieren am falschen Ende – sie komprimieren ein paar Bilder, schieben die Lighthouse-Punktzahl von 68 auf 74, und denken das Problem sei gelöst. Dann schauen wir in die Field Data und sehen: echte Nutzer erleben 4,2 Sekunden LCP auf dem Handy, INP bei 480 ms, und die Bounce Rate zeigt genau das. Performance-Optimierung, die wirklich wirkt, ist kein einmaliger Audit-Sprint. Sie erfordert Verständnis dafür, was tatsächlich gemessen wird – und welche Hebel echten Impact haben, nicht nur Laborwerte verbessern.
Lab Data vs. Field Data: der Unterschied, der alles ändert
Das ist der erste blinde Fleck in fast allen Performance-Projekten. Lighthouse und PageSpeed Insights messen unter kontrollierten Bedingungen: simuliertes 4G, gedrosselter CPU, keine echten Nutzer. Das sind Lab Data – wertvoll für Diagnose, aber kein Abbild der Realität.
Field Data kommen aus dem Chrome UX Report (CrUX) – echten Nutzersitzungen, die Chrome an Google übermittelt. Die Werte, die Google für das Ranking heranzieht, stammen aus CrUX, nicht aus Lighthouse. Wenn euer Lighthouse-Score auf Desktop gut aussieht, eure CrUX-Daten aber schlechte Mobile-Werte zeigen, optimiert ihr gegen das falsche Bild.
Real User Monitoring (RUM) geht noch einen Schritt weiter: Tools wie Sentry, Vercel Analytics oder selbst gehostetes Plausible mit Web Vitals können euch zeigen, welche Nutzer auf welchen Geräten und Verbindungen was erleben – aufgeschlüsselt nach Seiten, Regionen, Browsers.
Erst wenn ihr beides habt – Lab für Diagnose, Field für Priorität – macht Performance-Optimierung wirklich Sinn.
Core Web Vitals 2026: Zielwerte und aktueller Stand
Google hat die Core Web Vitals seit ihrer Einführung weiterentwickelt. Die drei Metriken, die zählen:
LCP (Largest Contentful Paint): Wann ist das größte sichtbare Element geladen? Zielwert: unter 2,5 Sekunden. Häufig: Hero-Bild, großes Textelement, Video-Poster.
INP (Interaction to Next Paint): Wie lange dauert es nach einer Nutzerinteraktion, bis der Browser visuell reagiert? Zielwert: unter 200 ms. INP hat FID als Maßstab abgelöst und ist anspruchsvoller – es misst die gesamte Interaktionslatenz, nicht nur das erste Event.
CLS (Cumulative Layout Shift): Wie viel springt das Layout unerwartet? Zielwert: unter 0,1. Typische Ursachen: Bilder ohne Dimensionen, nachladende Fonts, Banner die sich einschießen.
Alle drei Werte werden von Google als Ranking-Signal genutzt – und alle drei beeinflussen direkt, wie Nutzer eure Seite erleben. Das sind keine unabhängigen Metrik-Spielereien.
Tools: wann welches
Lighthouse (Chrome DevTools / CLI)
Das klassische Audit-Tool. Gut für schnelle Diagnose, schlecht für Entscheidungen über Prioritäten. Startet damit, um zu sehen, welche Kategorien rot sind – aber verlasst euch nicht auf den Score als Wahrheit.
Wann: Entwicklungsumgebung, lokaler Check vor Deployment, CI-Integration.
PageSpeed Insights
Kombiniert Lab-Daten (Lighthouse) mit Field-Daten (CrUX) – sofern genug echte Nutzerdaten für eure URL vorhanden sind. Das macht es zum nützlichsten kostenlosen Einstiegspunkt, weil ihr sofort seht, wo Lab und Field auseinanderlaufen.
Wann: Erster Blick auf eine neue URL, Monitoring ohne aufwendiges Setup.
WebPageTest
Der Goldstandard für tiefe Performance-Analyse. Waterfallcharts, filmstrip-Ansicht, Multi-Step-Tests, reale Geräte und Verbindungen. Wenn ihr wissen wollt, warum etwas langsam ist – nicht nur dass es langsam ist – ist WebPageTest das richtige Tool.
Wann: Diagnose spezifischer Probleme, Before/After-Vergleiche, Rendering-Analyse.
Chrome DevTools (Performance Panel)
Für INP-Diagnose unverzichtbar. Das Performance Panel zeigt euch, was auf dem Main Thread passiert, welche Long Tasks eure Interaktionen blockieren, und wo JavaScript tatsächlich Zeit verbrennt.
Wann: INP-Probleme analysieren, Third-Party-Script-Impact messen, Rendering-Bottlenecks identifizieren.
Die technischen Hebel: was wirklich wirkt
Bilder: der größte LCP-Faktor
Format: AVIF ist 2026 in allen modernen Browsern breit unterstützt und erreicht deutlich bessere Kompression als WebP bei gleicher visueller Qualität. Nutzt AVIF als primäres Format mit WebP als Fallback.
Dimensionen: Jedes Bild braucht width und height-Attribute oder ein festes Aspektverhältnis via CSS. Ohne das springt das Layout (CLS) beim Laden.
Lazy Loading: Bilder unterhalb des Viewports sollen mit loading="lazy" geladen werden. Das LCP-Bild (Hero-Bild) darf das nicht haben – es muss sofort laden. Fehler hier ist häufiger als man denkt.
sizes-Attribut: Wenn ihr Bilder in responsiven Layouts habt, teilt dem Browser mit sizes mit, wie groß das Bild im jeweiligen Viewport sein wird. Ohne das lädt der Browser oft unnötig große Bilder.
Preload: Das LCP-Bild kann mit <link rel="preload"> explizit priorisiert werden. In Next.js geht das über priority auf <Image />.
Critical CSS und Render-Blocking Resources
Der Browser kann keine Pixel malen, solange CSS im <head> nicht geladen ist. Critical CSS – also die Styles, die für den First Paint gebraucht werden – sollte inlined sein, der Rest asynchron geladen werden.
Render-blocking Stylesheets und Scripts im <head> sind 2026 immer noch einer der häufigsten Performance-Sünden. Jede externe CSS-Datei ohne media-Attribut oder preload blockiert das Rendering.
JavaScript: Code Splitting, Tree Shaking, Defer/Async
Zu viel JavaScript ist der häufigste INP-Killer. Und damit meinen wir nicht nur Bundle-Größe, sondern Main Thread Blocking: JavaScript, das zur Ladezeit ausgeführt wird und den Browser daran hindert, auf Nutzereingaben zu reagieren.
Code Splitting stellt sicher, dass nur das JavaScript geladen wird, das für die aktuelle Seite gebraucht wird. In Next.js passiert das automatisch – aber "use client"-Komponenten weit oben im Component Tree können diesen Vorteil zunichtemachen.
Tree Shaking entfernt ungenutzten Code aus Libraries beim Build. Funktioniert nur bei ES-Modulen und setzt voraus, dass ihr Libraries mit sauberem ESM-Support wählt.
Defer und Async: Scripts mit defer werden nach dem HTML-Parsing ausgeführt, blockieren aber nicht. async lädt parallel, führt aber sofort aus – weniger kontrollierbar. Für die meisten Analytics- und Third-Party-Scripts ist defer die richtige Wahl.
Server-Performance: TTFB, CDN, Caching
TTFB (Time to First Byte) ist die Zeit, bis der Browser das erste Byte vom Server bekommt. Wenn TTFB über 600–800 ms liegt, habt ihr ein Server- oder Netzwerkproblem – keine Frontend-Optimierung hilft dagegen.
CDN: Statische Assets (JS, CSS, Bilder) sollten von einem CDN ausgeliefert werden, das geografisch nah an euren Nutzern sitzt. Vercel, Cloudflare, Fastly – alle mit globalen Edge-Netzwerken.
Browser Caching: Statische Assets mit langen Cache-Lifetimes (1 Jahr für hashed Assets) sorgen dafür, dass Wiederkehrsbesucher nicht alles neu laden. Server-Caching (ISR in Next.js, Stale-While-Revalidate) reduziert die Serverlast und verbessert TTFB.
Fonts: font-display, Subsetting, next/font
font-display: swap verhindert, dass der Browser den Text unsichtbar lässt, bis der Webfont geladen ist. Aber Swap verursacht CLS, wenn Fallback- und Webfont-Metriken stark abweichen.
Font Subsetting reduziert die Dateigröße erheblich: Wenn ihr nur lateinische Zeichen braucht, ladet keine arabischen Schriftzeichen mit. Tools wie glyphhanger oder Online-Subsetting-Services helfen dabei.
next/font ist 2026 der Standard in Next.js-Projekten: automatisches Subsetting, self-hosting, keine externen Requests zu Google Fonts (DSGVO-Vorteil), kein Layout Shift. Wenn ihr das noch nicht nutzt, ist das ein einfacher Gewinn.
Third-Party Scripts: der unsichtbare Performance-Killer
Tag Manager, Analytics, Chat-Widgets, A/B-Testing, Pixel – jeder dieser Scripts frisst Main Thread Zeit und blockiert potentiell eure Core Web Vitals. Die Lösung ist nicht, sie zu entfernen (meistens nicht realistisch), sondern sie lazy zu laden.
Lazy Loading für Third-Party-Scripts: Ladet Scripts erst nach dem load-Event oder nach einer Nutzerinteraktion. In Next.js gibt es dafür next/script mit strategy="afterInteractive" oder strategy="lazyOnload".
Messt den Impact jedes Third-Party-Scripts mit WebPageTest, bevor ihr darüber diskutiert. Oft lässt sich mit zwei, drei Anpassungen (z.B. Chat-Widget erst nach Scroll, Tag Manager mit Delay) 30–50 % der Main-Thread-Blockaden eliminieren.
Performance-Checkliste zum Abarbeiten
- Field Data prüfen: PageSpeed Insights, CrUX Dashboard – welche Metriken sind rot bei echten Nutzern?
- LCP-Element identifizieren: Was ist das größte Element im Viewport? Ist es ein Bild? Ist es vorgeladen? Hat es
priority? - Bilder auditieren: AVIF/WebP,
width/height, keinlazyauf LCP-Bild,sizesgesetzt? - JavaScript-Budget prüfen: Wie groß ist das Haupt-Bundle? Wie viel JS läuft auf dem Main Thread beim ersten Load?
- Third-Party-Scripts inventarisieren: Welche Scripts sind eingebunden? Mit welcher Strategie laden sie?
- Font-Setup prüfen:
next/fontoder manuell mit Subset undfont-display? - TTFB messen: Unter 600 ms? Wenn nicht – Hosting, CDN oder Server-Caching prüfen.
- CLS-Ursachen suchen: Haben alle Bilder Dimensionen? Springt etwas beim Font-Swap? Laden Banner nachträglich?
- Critical CSS: Sind alle Render-blocking Stylesheets eliminiert oder async geladen?
- INP testen: Chrome DevTools Performance Panel – gibt es Long Tasks über 50 ms beim Klicken?
Before/After aus der Praxis
Projekt: B2B-SaaS, ca. 40.000 Besucher/Monat
Ausgangslage: LCP 4,8 s mobil (Field), INP 620 ms. Hauptursache: ein Chat-Widget (Intercom), das synchron im Head lud, plus ein nicht optimiertes Hero-Bild ohne preload.
Nach Optimierung: Chat-Widget auf lazyOnload, Hero-Image mit priority und AVIF-Format. LCP 2,1 s, INP 180 ms. Keine neuen Features, kein Redesign – nur sauberes Laden.
Projekt: E-Commerce, WooCommerce Ausgangslage: 23 eingebundene Plugins, kein Caching, TTFB 2,1 s. Lighthouse-Score: 31. Nach Optimierung: Server-Caching via LiteSpeed, Bild-Lazy-Loading, Bereinigung auf 14 Plugins, CDN für Assets. TTFB 380 ms, LCP 2,8 s. Organischer Traffic +22 % in 60 Tagen, Conversion Rate +11 %.
Diese Zahlen sind keine Ausnahmen – sie zeigen, wie viel Raum bei den meisten Projekten noch liegt, wenn man systematisch vorgeht statt einmalig einen Audit zu machen und die Ergebnisse zu archivieren.
Wenn ihr wissen wollt, wo eure Website konkret steht und welche Hebel den größten Impact hätten, bieten wir eine kostenlose Performance-Analyse an: messbare Ausgangswerte, priorisierte Maßnahmen, ehrliche Aufwandsschätzung – ohne Audit-PDF, das danach in der Schublade verschwindet.