Warum Lighthouse Scores lügen – und was Google wirklich bewertet

Lighthouse ist eines der am häufigsten missverstandenen Tools in der modernen Webentwicklung. Teams feiern 95+, „alles grün", „Performance erledigt" – und kurz danach stagnieren Rankings, Conversions schwächeln und echte Nutzer beschweren sich, dass sich die Seite langsam anfühlt. Das ist kein Zufall und kein Pech. Es ist das vorhersehbare Ergebnis davon, auf eine Zahl zu optimieren, die eine andere Frage beantwortet als die, die Google stellt. Lighthouse misst, wie schnell deine Seite unter idealen Bedingungen sein könnte. Google misst, wie schnell sie für die Menschen ist, die sie tatsächlich nutzen. Das ist nicht dasselbe – und in der Lücke dazwischen lebt sehr viel „aber unser Score ist doch top"-Verwirrung.

Die wichtigsten Erkenntnisse

Das Kernproblem: Lighthouse misst eine kontrollierte Fantasie

Ein Lighthouse-Lauf passiert im Reinraum: ein simuliertes Gerät, ein festes, gedrosseltes Netzwerkprofil, keine Browser-Extensions, keine konkurrierenden Tabs, nichts vom Rauschen des echten Lebens. Das ist bewusst so und durchaus nützlich – es macht den Test reproduzierbar, genau das, was du fürs Debugging und Aufspüren von Regressionen brauchst. Aber es bedeutet auch, dass das Ergebnis einen kontrollierten Best Case beschreibt, nicht die chaotische Realität eines Nutzers auf einem drei Jahre alten Android-Phone, auf einer wackeligen Mobilverbindung, mit einem Dutzend offener Tabs und einem Energiesparmodus, der die CPU drosselt.

Google schaut für Ranking-Zwecke genau auf diese chaotische Realität. Das Signal kommt aus dem Field – aggregierte, anonymisierte Daten echter Chrome-Nutzer – nicht aus einem synthetischen Lauf auf deinem Laptop. Ein makelloser Lab-Score und eine schlechte Real-World-Erfahrung können also bequem nebeneinander existieren, und wenn sie das tun, ist es der Lab-Score, der lügt. Nicht böswillig; er beantwortet nur „wie schnell könnte das sein?", während du die Antwort auf „wie schnell ist das, für sie, gerade jetzt?" gebraucht hättest.

Warum hohe Lighthouse Scores oft zu schlechten SEO-Entscheidungen führen

Hier kommt der unbequeme Teil: Das Jagen nach dem Score drängt Teams aktiv zu Entscheidungen, die echten Nutzern schaden. Damit die Lab-Zahl steigt, verzögern Teams Content hinter Interaktionen, lazy-loaden über jedes sinnvolle Maß hinaus, lehnen sich an Hydration-Tricks an, kaschieren langsame Daten mit Skeleton-Screens und verzögern das Rendering auf eine Weise, die für einen synthetischen Test großartig aussieht und sich für einen Menschen schlechter anfühlt. Man kann den Hauptinhalt aus dem initialen Paint herausziehen, um eine Metrik zu schmeicheln, und dabei die tatsächliche Erfahrung verschlechtern. Die grüne Zahl steigt; das Ergebnis sinkt. Auf die Messung statt auf das Gemessene zu optimieren ist eine klassische Falle, und Lighthouse macht es ungewöhnlich leicht, hineinzutappen, weil die Belohnung (ein befriedigender Score) sofort kommt und die Kosten (schlechtere Field-Daten) verzögert und auf deinem Rechner unsichtbar sind.

Die drei Performance-Welten – und warum nur eine dich rankt

Es hilft, drei Realitäten zu trennen, die ständig vermischt werden.

Lab Metrics (Lighthouse). Synthetisch, reproduzierbar, entwicklerfreundlich. Wirklich gut zum Debuggen, zum Aufspüren von Regressionen und zum Vergleich zweier Versionen einer Änderung unter identischen Bedingungen. Begrenzt aussagekräftig für Rankings, reale UX oder Business-Ergebnisse – weil die Bedingungen nicht real sind.

Field Metrics (CrUX). Der Chrome User Experience Report: echte Nutzer, echte Geräte, echte Netzwerke. Das ist die Datenbasis von Googles Page-Experience-Signal. Wenn deine Field-Daten schlecht sind, rettet dich kein schöner Lighthouse-Score, denn Google schaut nicht auf deinen Lab-Lauf – es schaut auf deine Nutzer.

Business Metrics (die alle vergessen). Bounce Rate, Conversion, Scrolltiefe, reale Interaktionsverzögerung. Das sind die Ergebnisse, die Performance schützen soll, und sie folgen der realen Geschwindigkeit oft weit treuer als jeder Lab-Composite. Eine Seite kann „98 in Lighthouse" sein und trotzdem Conversions verlieren, weil die Erfahrung, die zählt – die, die Nutzer tatsächlich haben – nie die war, die optimiert wurde.

Die praktische Hierarchie: Im Lab debuggen, am Field beurteilen, gegen das Business validieren.

Die Lighthouse-„Erfolge", die in der Realität verlieren

Ein paar konkrete Muster wiederholen sich oft genug, um sie zu benennen.

Künstlich verzögerter LCP. Hauptinhalt verstecken, sein Rendering verzögern, einen Platzhalter zeigen – und der Largest Contentful Paint sieht im Lab besser aus. Echte Nutzer warten trotzdem auf den echten Content, und Google sieht dieses Warten im Field. Du hast den Anschein von Geschwindigkeit optimiert, nicht die Geschwindigkeit.

Übertriebenes JavaScript-Deferring. Skripte zu verzögern hebt verlässlich den Lab-Score, aber zu weit getrieben verzögert es Interaktivität, zerstört Analytics-Timing und – am wichtigsten 2026 – verursacht INP-Regressionen. Die Seite benchmarkt wunderschön und fühlt sich träge an, sobald jemand sie zu benutzen versucht. Das ist die größte Lab-vs-Field-Divergenz und verdient einen eigenen Punkt weiter unten.

CLS jagen und dabei UX zerstören. Layout-Shift-Fixes, die riesige Flächen reservieren oder das Layout unnatürlich einfrieren, können den Cumulative Layout Shift technisch senken und die Seite dabei steif oder kaputt wirken lassen. CLS ist ein Signal für Stabilität, kein Ziel, das man austricksen sollte; ein „perfekter" CLS, der durch beschädigte Nutzbarkeit erkauft ist, ist eine Niederlage im Gewand eines Erfolgs.

Die TBT-vs-INP-Falle (der Teil, den die meisten Teams übersehen)

Das ist das technische Herz davon, warum ein großartiger Lighthouse-Score und schlechte Field-Reaktionsfähigkeit nebeneinander leben können. Lighthouse kann im Lab keine echten Interaktionen messen, weil kein echter Nutzer klickt. Also nutzt es einen Proxy für Reaktionsfähigkeit: Total Blocking Time (TBT), die schätzt, wie stark der Main Thread während des Ladens blockiert war. Googles tatsächliche Ranking-Metrik für Reaktionsfähigkeit ist Interaction to Next Paint (INP) – eine Field-Messung, wie schnell die Seite über alle Interaktionen eines echten Nutzers hinweg während einer Session reagiert.

TBT und INP hängen zusammen, laufen aber regelmäßig auseinander. Eine Seite kann während des kurzen Ladefensters, das Lighthouse beobachtet, niedrigen TBT haben und trotzdem schrecklichen INP, weil die trägen Interaktionen später passieren – wenn ein Nutzer ein schweres Dropdown öffnet, eine große Liste filtert oder State-Änderungen in einer aufgeblähten Client-App auslöst. Lighthouse sieht diese Momente nie; echte Nutzer leben in ihnen. „Großartiger TBT, großartiger Lighthouse-Score, durchgefallener INP im Field" ist also kein Paradox – es ist das normale Ergebnis für interaktionslastige Single-Page-Apps. Wenn du dir eine Sache merkst: Die Reaktionszahl des Labs und die Reaktionszahl des Fields sind verschiedene Metriken, und nur die Field-Zahl rankt dich.

Pro-Tipp: Wenn dein Lighthouse-Score grün ist, Nutzer die Seite aber als träge empfinden, hör auf, auf TBT zu starren, und zieh deinen Field-INP aus CrUX oder dem Core-Web-Vitals-Bericht der Search Console. Die Lücke zwischen beiden ist fast immer der Ort, an dem sich das echte Problem versteckt.

Was 2026 wirklich zählt (Google-Realität)

Sei präzise bei den Field-Signalen, die deine Aufmerksamkeit verdienen.

Field Core Web Vitals, bewertet am 75. Perzentil. Googles drei Core Web Vitals sind LCP (Laden), INP (Reaktionsfähigkeit, hat FID im März 2024 abgelöst) und CLS (visuelle Stabilität). Die „guten" Schwellen sind LCP unter 2,5 Sekunden, INP unter 200 Millisekunden und CLS unter 0,1. Entscheidend: Eine URL gilt nur dann als „gut", wenn alle drei am 75. Perzentil der echten Besuche bestehen – das heißt, die Erfahrung deiner langsameren-als-Median-Nutzer zählt, nicht dein Best Case – aggregiert über ein rollierendes 28-Tage-Fenster in CrUX. Ein schneller Test auf deinem Rechner bedeutet dagegen nichts. (Und beachte die Granularität: Google bewertet pro URL, wo genug Daten vorliegen, und fällt auf eine Seitengruppe oder den gesamten Origin zurück, wenn eine bestimmte URL zu wenig Traffic hat – ein langsames Template kann also Seiten herunterziehen, die für sich genommen zu wenig Daten haben.)

Backend-Latenz (TTFB). Der stille Killer. Time to First Byte sitzt vor allem anderen: Ein langsames API oder ein langsamer Origin-Server verzögert den LCP, egal wie optimiert das Frontend ist, und die meisten Lab-Läufe – warm und nah am Testrechner ausgeliefert – kaschieren das. Nutzer in echten Netzwerken bekommen diese Höflichkeit nicht. Langsame Backends deckeln still deinen LCP und damit deine Rankings.

Interaktion unter Last (INP). Wie oben bestraft INP schwere Client-Logik, übergroße JavaScript-Bundles und zustandslastige UIs, die den Main Thread blockieren. Es ist die Metrik, an der 2026 die meisten Seiten scheitern, und sie zu reparieren ist kein Tweak – es bedeutet, lange Tasks aufzubrechen, unkritische Arbeit zu verschieben und dem Main Thread Platz zu geben, also einen echten Wandel in der Architektur des Frontends. In einem Lighthouse-Score taucht sie selten auf.

Vorhersehbarkeit. Google bevorzugt Seiten, die sich konsistent verhalten – die unter Last nicht einbrechen und Nutzer nicht überraschen. Performance-Volatilität ist selbst ein Risiko: Eine Seite, die an einem guten Tag schnell ist und unter Traffic auseinanderfällt, sieht in aggregierten Field-Daten schlechter aus als eine, die bloß stetig ist.

Eine Kalibrierung, die man klar aussprechen sollte, weil sie in beide Richtungen schneidet: Core Web Vitals sind ein bestätigtes, aber moderates Ranking-Signal. Google ist konsistent dabei geblieben, dass Content-Relevanz, Qualität und E-E-A-T mehr zählen – CWV wirken vor allem als Tiebreaker zwischen ansonsten vergleichbaren Seiten, mit dem deutlichsten Effekt in umkämpften Nischen und auf Mobile. Das Ziel ist also nicht, die Field-Zahlen ebenso anzubeten wie die Lab-Zahlen; es ist, aufzuhören, Nutzer zu verlieren und Wettbewerbern einen leichten Vorteil zu schenken. Erwarte nicht, dass grüne CWV dünnen Content retten – und lass nicht zu, dass schlechte CWV still Content benachteiligen, der gewinnen sollte.

Lighthouse ist ein Tool – kein KPI

Richtig eingesetzt ist Lighthouse wirklich hilfreich – für lokales Debugging, für den Vorher-Nachher-Vergleich einer konkreten Änderung, für das Aufspüren von Regressionen in CI. Falsch eingesetzt ist es aktiv gefährlich – als Performance-Nachweis, als SEO-Beweis oder als Zahl im Kundenreport, mit der man Performance für „erledigt" erklärt. Zwei klare Sätze zum Merken: Ein grüner Lighthouse-Score bedeutet keine schnelle Seite, und eine wirklich schnelle Seite scort nicht immer grün. Behandle es als Instrument, nicht als Urteil.

Warum das bei modernen Frameworks noch kritischer ist

Frameworks wie Next.js schneiden in beide Richtungen. Sie machen es leicht, Lab-Metriken zu spielen – zu verzögern, zu verstecken und das Rendering so zu inszenieren, dass der synthetische Test begeistert ist – und genauso leicht, durch Server-Rendering, sinnvolles Code-Splitting und disziplinierten Datenfluss echte schnelle Systeme zu bauen. Das Framework ist weder Bösewicht noch Held; die Architektur ist es. Dasselbe Tool, mit dem du Latenz hinter einem Skeleton versteckst, lässt dich diese Latenz auch an der Quelle beseitigen. Was du bekommst, hängt davon ab, ob das Team die Zahl optimiert oder die Erfahrung.

Was erfolgreiche Teams stattdessen tun

Die Teams, die in Suche und Conversion konsistent gewinnen, teilen eine Haltung. Sie überwachen CrUX, nicht Lighthouse, als ihre Quelle der Wahrheit. Sie messen Real-User-Core-Web-Vitals kontinuierlich, statt einen Test vor dem Launch zu fahren und ihn dann zu vergessen. Sie setzen explizite Performance-Budgets, damit Regressionen an der Tür abgefangen werden. Sie optimieren Datenfluss und Backend-Latenz, nicht Animationen und eitle Mikro-Optimierungen. Sie behandeln Performance als geteilte Backend-und-Frontend-Verantwortung, weil TTFB und INP an entgegengesetzten Enden des Stacks leben. Und ein praktischer Kraftverstärker: Sie reparieren Templates, nicht einzelne URLs – ein einzelnes LCP-Problem in einem Blog-Template betrifft jeden Beitrag, also repariert ein Fix Hunderte Seiten auf einmal. Kurz: Sie hören auf, Zahlen zu feiern, und beginnen, Systeme zu kontrollieren.

Pro-Tipp: Setze ein Performance-Budget in CI, das an field-relevante Metriken gekoppelt ist, nicht nur an eine Lighthouse-Schwelle. Ein Budget, das den Build scheitern lässt, wenn ein Bundle aufbläht oder ein langer Task einschleicht, fängt INP-Regressionen ab, bevor sie je echte Nutzer erreichen.

Der H-Studio-Ansatz: Performance ohne Illusionen

Bei H-Studio behandeln wir einen Lighthouse-Score nicht als Erfolg. Wir schauen auf reale Nutzer-Core-Web-Vitals, Backend-Latenz, Regressionsrisiko, echte SEO-Auswirkungen und Business-Ergebnisse. Wenn Lighthouse sich als Nebeneffekt davon verbessert – wunderbar. Wenn nicht, interessiert es uns deutlich weniger – weil es Google weitgehend auch nicht interessiert. Der Sinn von Performance-Arbeit ist keine befriedigende Lab-Zahl; es ist eine Seite, die für echte Menschen schnell ist, konsistent, unter den Bedingungen, die sie tatsächlich nutzen.

Und das Fazit ist eigentlich der ganze Artikel in einer Zeile: Lighthouse lügt nicht absichtlich. Es beantwortet nur präzise die falsche Frage. Die richtige Frage ist der einzige Score, der verlässlich zählt – wie schnell ist deine Seite für echte Nutzer, konsistent, am 75. Perzentil, auf den Geräten und in den Netzen, die sie tatsächlich haben? Beantworte das, und die Lab-Zahl folgt meist von selbst. Jag die Lab-Zahl, und du kannst ein Quartal damit verbringen, sie grün zu machen, während die Erfahrung, die dich rankt, und die Erfahrung, die konvertiert, still schlechter wird.

— Anna

Performance-Audit auf Basis echter Daten

Wenn deine Lighthouse-Scores grün sind, Rankings oder Conversions aber wegrutschen, optimierst du für die falschen Metriken – und die Lösung ist, das zu messen, was Google und deine Nutzer tatsächlich erleben. Wir beginnen mit React-Performance-Optimierung für die INP- und Main-Thread-Probleme, die Lab-Scores verstecken, kombinieren sie mit Core Web Vitals und Technical SEO, um die Field-Signale zu reparieren, die Rankings bewegen, und greifen bis ins DevOps und Cloud Engineering hinauf, wenn TTFB und Backend-Latenz die eigentliche Decke sind. Sieh dir all unsere Engineering-Services an oder nimm Kontakt auf – wir auditieren, was deine echten Nutzer erleben, nicht was dein Laptop reportet.

FAQ

Ist ein hoher Lighthouse-Score schlecht für SEO?

Nicht von Natur aus – aber darauf zu optimieren kann es sein. Lighthouse ist ein Labortest unter Idealbedingungen; Google rankt auf Field-Daten echter Nutzer (CrUX). Taktiken, die den Lab-Score schmeicheln (Content verstecken, JS überdeferrieren), können die reale Erfahrung verschlechtern, die Google misst.

Was nutzt Google tatsächlich zum Ranken – Lighthouse oder Core Web Vitals?

Field Core Web Vitals von echten Chrome-Nutzern, bewertet am 75. Perzentil über ein rollierendes 28-Tage-Fenster. Lighthouse ist ein Lab-Tool, das nicht direkt in Rankings einfließt.

Wie lauten die Core-Web-Vitals-Schwellen 2026?

LCP unter 2,5 Sekunden, INP unter 200 Millisekunden, CLS unter 0,1 – und alle drei müssen am 75. Perzentil bestehen, damit die Bewertung „gut" ist. INP hat FID als Reaktionsmetrik im März 2024 abgelöst.

Warum sieht mein Lighthouse-Score großartig aus, aber die Seite fühlt sich träge an?

Meist ist es die TBT-vs-INP-Lücke. Lighthouse nutzt Total Blocking Time (einen Lab-Proxy) für Reaktionsfähigkeit; Google nutzt INP (echte Interaktionen über eine Session). Interaktionslastige Apps können beim Laden guten TBT haben und später, wenn Nutzer tatsächlich interagieren, schlechten INP.

Wie stark beeinflussen Core Web Vitals die Rankings?

Sie sind ein bestätigtes, aber moderates Signal – ein Tiebreaker zwischen ansonsten vergleichbaren Seiten, am stärksten in umkämpften Nischen und auf Mobile. Content-Relevanz und Qualität zählen mehr, aber schlechte CWV können dich gegenüber ähnlichen Wettbewerbern trotzdem etwas kosten.