Ein plötzlicher Sprung im PageSpeed-Insights-Score wirkt auf den ersten Blick wie ein Erfolg: bessere Werte, freundlichere Diagramme, zufriedene Stakeholder. Doch genau hier liegt die Falle. Nicht jede Verbesserung in PageSpeed Insights bedeutet, dass eine Website tatsächlich schneller geworden ist. Mit dem Wechsel auf Google Lighthouse 13.6.0 hat sich die Art verändert, wie Ladeprozesse simuliert werden. Das kann insbesondere bei JavaScript-lastigen Websites zu spürbar besseren Laborwerten führen, obwohl am Code, Hosting oder Rendering nichts optimiert wurde.
Für SEO-Teams, Entwickler und Performance-Verantwortliche ist diese Änderung mehr als eine technische Fußnote. Wer Lighthouse-Scores als KPI nutzt, muss jetzt genauer hinsehen: Wurde die Seite wirklich schneller oder bewertet das Messwerkzeug denselben Zustand nur anders?
Warum plötzlich bessere PageSpeed-Werte kein Beweis für bessere Performance sind
PageSpeed Insights kombiniert unterschiedliche Datenquellen. Der sichtbare Performance-Score basiert auf einem simulierten Testlauf mit Lighthouse. Diese sogenannten Labordaten entstehen unter kontrollierten Bedingungen: ein bestimmtes Gerät, festgelegte Netzwerkprofile, ein standardisierter Ablauf. Das ist nützlich, um technische Engpässe zu erkennen, aber es bildet nicht automatisch ab, wie echte Nutzer eine Seite erleben.
Mit Lighthouse 13.6.0 wurde die Simulation angepasst. Dadurch können Messwerte wie First Contentful Paint und Largest Contentful Paint anders berechnet werden als zuvor. In vielen Fällen fallen sie günstiger aus. Genau deshalb können Berichte vor und nach dem Update nur eingeschränkt miteinander verglichen werden.
Ein typisches Szenario: Ein Onlineshop sieht am Montag einen mobilen Performance-Score von 61. Am Mittwoch steht dort plötzlich 74. Das Team hat in der Zwischenzeit keine Bilder komprimiert, kein JavaScript reduziert und keine Serverkonfiguration geändert. Der Grund kann schlicht sein, dass PageSpeed Insights nun mit einer neueren Lighthouse-Version arbeitet.
Was sich bei Lighthouse 13.6.0 technisch verändert hat
Der Kern der Änderung betrifft die Art, wie Lighthouse das Laden einer Seite unter langsameren Bedingungen abschätzt. Lighthouse lädt eine Seite zunächst unter realen Testbedingungen und rekonstruiert anschließend mithilfe einer Simulation, wie sich diese Seite bei gedrosselter Verbindung verhalten würde. Diese Simulationslogik wird unter anderem durch ein System namens Lantern gesteuert.
Lantern ist entscheidend, weil es nicht einfach nur eine Stoppuhr startet. Es bewertet, welche Ressourcen das Rendering blockieren, welche Anfragen für sichtbare Inhalte relevant sind und wie Aufgaben im Browser-Hauptthread den Aufbau der Seite beeinflussen. Mit Version 13.6.0 wurde diese Einschätzung verfeinert.
Render-blocking wird nun näher an Chrome bewertet
Eine wichtige Anpassung betrifft render-blockierende Ressourcen. Frühere Lighthouse-Versionen orientierten sich stärker an der Fetch Priority einzelner Requests. Das konnte in bestimmten Fällen zu einer zu strengen oder ungenauen Einschätzung führen. Lighthouse 13.6 nutzt nun bevorzugt die von Chrome selbst bereitgestellte Kennzeichnung, ob eine Ressource das Rendering blockiert.
Das klingt unspektakulär, hat aber praktische Auswirkungen. Wenn ein Tool realistischer erkennt, welche Datei tatsächlich den sichtbaren Seitenaufbau verzögert, kann sich die simulierte Ladezeit verändern. Besonders betroffen sind Seiten mit komplexen Frontend-Architekturen, vielen JavaScript-Modulen, Frameworks und dynamischem Rendering.
Text-LCP wird differenzierter simuliert
Auch die Bewertung des Largest Contentful Paint wurde angepasst, wenn das größte sichtbare Element ein Textelement ist. Das betrifft zum Beispiel Landingpages, SaaS-Startseiten, Magazinseiten oder Dokumentationsseiten, bei denen der Hero-Bereich vor allem aus Überschrift und Text besteht.
Wenn derselbe Textbereich sowohl für den First Contentful Paint als auch für den LCP relevant ist, kann eine ältere Simulation den LCP unnötig weit nach hinten verschieben. Lighthouse 13.6 bewertet solche Fälle realistischer, indem es stärker auf die Ressourcen und Aufgaben schaut, die auch für den ersten sichtbaren Inhalt wichtig sind. Dadurch kann der LCP-Wert deutlich besser aussehen, ohne dass sich die echte Seite verändert hat.
JavaScript-lastige Websites stehen besonders im Fokus
Die Änderung betrifft nicht ausschließlich Single-Page-Applications, doch gerade Websites mit viel JavaScript spüren sie häufiger. Dazu gehören React-, Vue-, Angular- oder Next.js-Projekte, Headless-Commerce-Systeme, interaktive Produktkonfiguratoren und Web-Apps mit umfangreicher Client-seitiger Logik.
Der Grund ist einfach: Je stärker eine Seite vom Nachladen, Ausführen und Hydrieren von JavaScript abhängt, desto größer ist der Einfluss der Simulationsannahmen. Wenn Lighthouse besser erkennt, welche JavaScript-Ressourcen tatsächlich den sichtbaren Inhalt beeinflussen und welche eher für spätere Interaktion relevant sind, können sich FCP und LCP deutlich verschieben.
Ein Praxisbeispiel: Eine Versicherung betreibt einen Tarifrechner als Single-Page-App. Der sichtbare Einstieg besteht aus einer großen Headline, einem kurzen Erklärungstext und einem Formularbereich. Im Hintergrund werden aber zahlreiche JavaScript-Bundles geladen, darunter Tracking, Validierungslogik, UI-Komponenten und Personalisierung. Frühere Simulationen konnten Teile dieser Last stärker in die LCP-Bewertung einrechnen. Mit der neuen Version kann der sichtbare Inhalt günstiger bewertet werden, wenn er faktisch früher verfügbar ist.
Mythos vs. Fakt: Was SEO-Teams jetzt richtig einordnen müssen
Mythos: Ein höherer Lighthouse-Score bedeutet immer eine schnellere Website
Fakt ist: Ein höherer Lighthouse Score kann durch echte Optimierungen entstehen, etwa durch kleinere Bilder, weniger JavaScript, besseres Caching oder schnellere Serverantworten. Er kann aber auch durch eine geänderte Messlogik entstehen. Genau deshalb ist der Versionsvergleich so wichtig.
Mythos: Labordaten reichen aus, um Nutzererfahrung zu bewerten
Fakt ist: Labordaten sind ideal für Debugging und technische Analyse. Sie zeigen reproduzierbare Bedingungen und helfen, konkrete Performance-Probleme zu isolieren. Für die echte Nutzererfahrung sind jedoch Field Data, also Felddaten aus realen Besuchen, unverzichtbar. Diese Daten stammen aus dem Chrome User Experience Report und bilden einen Zeitraum von 28 Tagen ab.
Mythos: Wenn der LCP besser wird, ist das Core-Web-Vitals-Problem gelöst
Fakt ist: Ein besserer simulierter LCP ist nur ein Signal. Entscheidend ist, ob sich der reale Largest Contentful Paint für Nutzer ebenfalls verbessert. Besonders bei internationalem Traffic, schwachen Mobilgeräten, langsamen Mobilfunknetzen oder personalisierten Seiten kann die Laborbewertung von der echten Nutzung abweichen.
Labordaten und Felddaten: Der wichtigste Unterschied für belastbare Reports
Labordaten entstehen in einem kontrollierten Test. Sie sind kurzfristig verfügbar und hilfreich, wenn Entwickler eine konkrete Änderung prüfen möchten. Wer etwa ein großes JavaScript-Bundle splittet oder eine Hero-Grafik vorlädt, kann in Lighthouse schnell sehen, ob sich technische Kennzahlen verbessern.
Felddaten zeigen dagegen, wie echte Besucher eine Website erleben. Sie berücksichtigen unterschiedliche Geräte, Netzwerke, Browserzustände, Regionen und Nutzungsverhalten. Wenn PageSpeed Insights Felddaten anzeigt, beziehen sie sich auf reale Chrome-Nutzer der letzten 28 Tage. Dadurch reagieren sie langsamer auf Änderungen, sind aber für die Bewertung der Nutzererfahrung deutlich aussagekräftiger.
Die zentrale Empfehlung lautet daher: Keine Performance-Erfolgsmeldung allein auf Basis eines Lighthouse-Sprungs erstellen. Erst wenn Laborwerte, Felddaten und technische Änderungen zusammenpassen, ist die Verbesserung belastbar.
So prüfen Sie, ob Ihre Verbesserung echt ist
Lighthouse-Version im Report kontrollieren
Jeder PageSpeed-Insights-Bericht nennt die verwendete Lighthouse-Version. Dieser Hinweis steht im Umfeld der Labordaten und des emulierten Geräts. Wenn ein alter Report mit Lighthouse 13.5 und ein neuer Report mit Lighthouse 13.6.0 erstellt wurde, vergleichen Sie nicht nur Ihre Website, sondern auch zwei unterschiedliche Messmodelle.
Für interne Reportings empfiehlt es sich, die Lighthouse-Version immer zu dokumentieren. Das gilt besonders dann, wenn Performance-Scores in Dashboards, OKRs oder Kundenreports einfließen.
Datum der Messung und Release-Wechsel markieren
Wenn Sie historische Lighthouse-Daten in Looker Studio, Google Sheets, Datadog, Grafana oder einem SEO-Tool verfolgen, markieren Sie den Zeitpunkt des Versionswechsels. Ein plötzlicher Score-Anstieg kann sonst fälschlicherweise als Ergebnis einer technischen Maßnahme interpretiert werden.
Eine sinnvolle Formulierung im Reporting wäre: „Der Performance-Score ist gestiegen, allerdings fällt der Zeitraum mit dem Wechsel auf Lighthouse 13.6.0 zusammen. Die Entwicklung der Felddaten wird separat beobachtet.“
Core Web Vitals aus echten Nutzerdaten gegenprüfen
Prüfen Sie insbesondere LCP, INP und CLS in den Felddaten. Wenn der Lighthouse-LCP deutlich besser wird, der reale LCP aber stabil bleibt, liegt die Ursache wahrscheinlich eher in der neuen Simulation als in einer tatsächlichen Verbesserung. Wenn beide Werte in die gleiche Richtung laufen, ist das ein stärkeres Indiz für echte Fortschritte.
Was das Update für technische SEO-Arbeit bedeutet
Für Technical SEO verändert sich durch dieses Update vor allem die Interpretation von Messwerten. PageSpeed Insights bleibt ein wertvolles Werkzeug, aber seine Ergebnisse müssen kontextualisiert werden. Wer Kunden, Geschäftsführung oder Produktteams berät, sollte erklären können, warum ein Score nicht isoliert betrachtet werden darf.
Gerade in der SEO-Praxis werden Lighthouse-Werte häufig als einfache Ampel genutzt. Grün wirkt gut, Rot wirkt schlecht. Doch moderne Web Performance ist komplexer. Ein Score kann steigen, obwohl Nutzer keine Verbesserung bemerken. Umgekehrt kann eine echte Optimierung in Felddaten erst verzögert sichtbar werden, während Labordaten sofort reagieren.
Für Priorisierung und Budgetentscheidungen ist das entscheidend. Ein Team sollte nicht vorschnell ein Performance-Projekt als abgeschlossen betrachten, nur weil PageSpeed Insights bessere Zahlen zeigt. Stattdessen sollten technische Maßnahmen weiterhin anhand echter Engpässe bewertet werden: Serverantwortzeiten, kritischer Rendering-Pfad, JavaScript-Ausführung, Bildstrategie, Caching, Third-Party-Skripte und Frontend-Architektur.
Agentic Resource Discovery: Eine zweite relevante Änderung in Lighthouse 13.6
Neben der Performance-Simulation wurde auch der Audit rund um Agentic Resource Discovery, kurz ARD, angepasst. Dabei geht es um die Auffindbarkeit spezieller Ressourcen für KI-Agenten und automatisierte Systeme. Lighthouse 13.6 prüft nun moderner, ob eine Website Hinweise auf eine ARD-Datei bereitstellt.
Relevanter wird dabei unter anderem ard.json. Die Prüfung kann Signale wie einen Agentmap-Eintrag, einen rel=“ard“-Link, einen entsprechenden Link-Header oder eine Datei unter /.well-known/ard.json berücksichtigen. Ältere Namenskonventionen werden nachrangiger behandelt.
Für klassische SEO-Rankings ist dieser Audit nicht mit Core Web Vitals gleichzusetzen. Dennoch zeigt er, wohin sich technische Website-Audits entwickeln: Neben Suchmaschinen-Crawlern treten zunehmend KI-Systeme, Agenten und strukturierte Discovery-Mechanismen in den Blick. Wer früh saubere technische Signale setzt, reduziert spätere Anpassungskosten.
Praktische Empfehlungen für Ihre nächsten Performance-Reports
Wenn Sie PageSpeed Insights regelmäßig nutzen, sollten Sie Ihre Bewertungsroutine anpassen. Dokumentieren Sie künftig nicht nur Score, FCP, LCP, CLS und INP, sondern auch die verwendete Lighthouse-Version. Nur so lassen sich historische Daten korrekt einordnen.
Vergleichen Sie Optimierungen möglichst innerhalb derselben Tool-Version. Falls das nicht möglich ist, ergänzen Sie den Report um einen Hinweis auf die geänderte Messgrundlage. Das schützt vor falschen Schlussfolgerungen und stärkt die Glaubwürdigkeit Ihrer Analyse.
Verlassen Sie sich außerdem nicht auf eine einzige Messung. Performance-Werte können schwanken, selbst unter Laborbedingungen. Aussagekräftiger sind mehrere Tests, Medianwerte und der Abgleich mit Felddaten. Besonders bei umsatzkritischen Seiten wie Produktdetailseiten, Checkout-Prozessen, Leadformularen oder Buchungsstrecken sollte die reale Nutzererfahrung im Mittelpunkt stehen.
Wenn eine JavaScript-lastige Website plötzlich deutlich bessere Werte zeigt, prüfen Sie besonders genau, ob echte technische Änderungen stattgefunden haben. Wurden Bundles verkleinert? Wurde Code-Splitting eingeführt? Wurde serverseitiges Rendering verbessert? Wurden Third-Party-Skripte reduziert? Wenn nicht, ist Vorsicht bei der Interpretation angebracht.
Fazit: Lighthouse 13.6 macht Messungen besser, aber Vergleiche schwieriger
Google Lighthouse 13.6.0 bringt eine realistischere Simulation für bestimmte Ladeprozesse, insbesondere bei FCP und LCP. Das ist grundsätzlich positiv, weil PageSpeed Insights dadurch in vielen Fällen näher an der tatsächlichen Rendering-Logik von Chrome liegt. Gleichzeitig entstehen Brüche in historischen Vergleichen.
Die wichtigste Erkenntnis lautet: Ein besserer PageSpeed-Insights-Score ist nicht automatisch ein Beweis für eine schnellere Website. Prüfen Sie die Lighthouse-Version, vergleichen Sie Labordaten mit Felddaten und bewerten Sie Performance immer im Kontext echter Nutzererfahrung.
Für SEO, Webentwicklung und digitales Qualitätsmanagement bedeutet das Update vor allem eines: weniger Score-Fixierung, mehr analytische Sorgfalt. Wer diesen Unterschied versteht, verhindert Fehlinterpretationen und trifft bessere Entscheidungen für nachhaltige Website-Performance.
