PageSpeed-Insights-Wert plötzlich besser? Lighthouse 13.6 rechnet anders – so trennst du echte Verbesserungen von Messänderungen (WordPress und Shopify)

01 / Was sich geändert hat

Was Lighthouse 13.6 in PageSpeed Insights anders rechnet.

Lighthouse ist das Open-Source-Werkzeug von Google, das hinter dem Leistungswert von 0 bis 100 in PageSpeed Insights steckt [5]. Version 13.6.0 erschien am 27. Oktober 2026. In den Release Notes kündigte das Team an, die Version innerhalb einer Woche in PageSpeed Insights und später in den Entwicklertools von Chrome 159 auszuliefern [2]. Am 2. November bestätigte Barry Pollard, Web Performance Developer Advocate bei Chrome, auf Bluesky, dass PageSpeed Insights jetzt mit 13.6.0 läuft [1].

Wichtig ist dabei das Wort Simulation. PageSpeed Insights lädt deine Seite mit voller Geschwindigkeit und rechnet dann mit einem Modell namens Lantern hoch, wie sie auf einem langsameren Gerät mit langsamerer Verbindung geladen hätte [1][3]. Genau dieses Modell hat Google überarbeitet. Zwei Änderungen fallen besonders ins Gewicht:

• Was den Seitenaufbau blockiert: Bis Version 13.5 hat Lighthouse aus der Priorität einer Datei abgeleitet, ob sie die Darstellung aufhält. Jetzt nutzt es die Angabe, die Chrome selbst zu jeder Anfrage liefert [1][2]. Ein Skript kann hohe Priorität haben, ohne das Zeichnen der Seite zu verzögern; bisher konnte es trotzdem FCP und LCP verschlechtern [3].
• Text als größtes Element: Ist das größte sichtbare Element ein Text, der im selben Moment erscheint wie der erste Inhalt, berechnet Lighthouse LCP jetzt aus denselben Anfragen wie FCP [1][2]. Vorher konnten vorab geladene Skripte den simulierten LCP nach hinten schieben, obwohl der Text gar nicht auf sie wartete [3][4].

Dazu kommen genauere Annahmen zu HTTP/2- und HTTP/3-Verbindungen, Weiterleitungen und Laufzeiten im Netz [2][3]. Pollard schreibt, die simulierten Werte für FCP und LCP seien damit genauer und fielen meist besser aus. Stärker betroffen seien Websites mit viel JavaScript, ausdrücklich nicht nur Single-Page-Apps [1]. Der Monitoring-Anbieter Calibre, der seine Testagenten am 31. Oktober umgestellt hat, erwartet ebenfalls meist bessere LCP- und FCP-Werte und damit höhere Leistungswerte; Messprofile mit echter Drosselung während des Ladens seien von den beiden Korrekturen nicht betroffen [4].

Fertig ist das Thema damit nicht: Laut Search Engine Journal untersucht ein offener Eintrag im Lighthouse-Projekt weiter Fälle, in denen der simulierte LCP bei großen JavaScript-Seiten weit über dem tatsächlich gemessenen liegt [1].

02 / Labor und Feld

Warum der Wert steigt, obwohl deine Seite nicht schneller ist.

Ein PageSpeed-Insights-Bericht enthält zwei Arten von Daten, die oft verwechselt werden [5]:

• Labordaten: ein einzelner simulierter Seitenaufruf auf einem Mittelklasse-Smartphone (Moto G4) mit Mobilfunkverbindung bzw. einem Desktop mit Kabelverbindung. Daraus entsteht der Leistungswert von 0 bis 100; ab 90 gilt er als gut [5].
• Felddaten: echte Besuche von Chrome-Nutzerinnen und -Nutzern aus dem Chrome User Experience Report (CrUX) der letzten 28 Tage, ausgewiesen als 75. Perzentil [5]. Nur hier stehen die drei Core Web Vitals LCP, INP und CLS mit dem Urteil „bestanden“ oder „nicht bestanden“.

Der Leistungswert ist ein gewichteter Durchschnitt aus fünf Labormesswerten. In der aktuellen Gewichtung zählen Total Blocking Time 30 Prozent, LCP und Cumulative Layout Shift je 25 Prozent, FCP und Speed Index je 10 Prozent [6]. FCP und LCP machen also zusammen gut ein Drittel des Werts aus. Verbessert die neue Simulation diese beiden Messwerte, steigt der Gesamtwert mit, obwohl dieselben Dateien ausgeliefert werden [3].

Die Felddaten bleiben davon unberührt. CrUX misst echte Besuche und ändert sich nicht, nur weil Lighthouse sein Modell anpasst [3]. Google selbst schreibt in der PageSpeed-Insights-Doku, dass gute Labordaten nicht bedeuten, dass auch echte Besucher eine gute Erfahrung haben [5]. Laborwerte schwanken zudem ohnehin von Lauf zu Lauf, etwa durch Netzwerk, Werbung oder A/B-Tests [6]. Shopify beziffert die Streuung eines einzelnen Lighthouse-Laufs auf 5 bis 10 Punkte [14].

Labor und Feld weichen aus weiteren Gründen voneinander ab: Lighthouse lädt mit leerem Cache, echte Wiederkehrer haben Dateien oft schon gespeichert, und Seiten aus dem Zurück-Cache des Browsers erscheinen fast sofort [9]. INP, die Reaktionszeit auf Klicks, misst Lighthouse im Labor gar nicht; PageSpeed Insights zeigt sie nur in den Felddaten [5].

03 / Praxis

So trennst du echte Verbesserungen von Messänderungen.

Lighthouse-Version im Bericht ablesen

Jeder PageSpeed-Insights-Bericht nennt die verwendete Lighthouse-Version, und zwar neben dem emulierten Gerät [1]. Bevor du einen höheren Wert als Erfolg verbuchst, prüf, ob der alte und der neue Bericht mit derselben Version entstanden sind [1]. Ein Vorher-Bericht aus dem Oktober und ein Nachher-Bericht aus dem November sind nicht vergleichbar.

Achtung bei Tests im eigenen Browser: Der Lighthouse-Reiter in den Chrome-Entwicklertools bekommt 13.6 erst mit Chrome 159 [2]. Laut Search Engine Journal ist dessen stabile Version für den 8. Dezember 2026 geplant [1]. Bis dahin kann dieselbe Seite in PageSpeed Insights und lokal in Chrome unterschiedliche Werte liefern [3].

Den Core-Web-Vitals-Bericht als Maßstab nehmen

Für die Frage „Ist meine Website für Besucher schneller geworden?“ ist der Core-Web-Vitals-Bericht in der Search Console die bessere Quelle. Er beruht auf CrUX-Felddaten und gruppiert ähnliche Seiten nach LCP, INP und CLS in „Gut“, „Optimierung erforderlich“ und „Langsam“, jeweils für Mobilgeräte und Computer [7]. Die Werte beziehen sich auf 75 Prozent der Seitenaufrufe der letzten 28 Tage [7]. Eine Optimierung zeigt sich dort also erst nach einigen Wochen.

Hast du ein Problem behoben, klickst du in den Problemdetails auf „Tracking starten“. Die Search Console beobachtet dann 28 Tage lang, ob es noch irgendwo auftritt [7]. Kleine Websites sehen im Bericht oft „Keine Daten verfügbar“, weil es in CrUX zu wenige Besuche gibt [7]. Dann bleibt dir nur der Laborwert – mit der Version im Blick.

Dashboards und Berichte mit einer Anmerkung versehen

Wer PageSpeed-Werte regelmäßig an Kunden oder die Geschäftsführung berichtet, hat jetzt einen Bruch in der Zeitreihe: Ein Diagramm kann eine Verbesserung zeigen, die niemand umgesetzt hat [3]. Harry Roberts empfiehlt, zu jedem synthetischen Messergebnis die Lighthouse- und Browserversion festzuhalten und das Umstellungsdatum in Dashboards zu markieren [3].

• Search Console: Im Leistungsbericht kannst du per Rechtsklick auf das Diagramm eine eigene Anmerkung zu einem Datum setzen, bis zu 120 Zeichen, maximal 200 je Property; alle Nutzer mit vollem Zugriff sehen sie [8]. Ein Eintrag wie „PSI nutzt Lighthouse 13.6 – Laborwerte nicht mit Oktober vergleichen“ hilft dem Team auch in einem halben Jahr noch.
• Data Studio (früher Looker Studio) oder Tabelle: Ergänz eine Spalte „Lighthouse-Version“ und einen Hinweis im Bericht ab Anfang November 2026 (Einschätzung). Wie ein schlankes SEO-Dashboard aussieht, steht im Beitrag SEO-Dashboard in Looker Studio.
• Vorher-nachher-Tests: Miss jede Seite mindestens dreimal und nimm den Median, mit gleichem Gerät und gleichen Bedingungen [14]. Ein einzelner Lauf ist kein Beleg.

04 / WordPress und Shopify

Was bei WordPress und Shopify wirklich Ladezeit kostet.

Ein besserer Laborwert ändert nichts an den Ursachen, die deine Besucher ausbremsen. Die Lighthouse-Korrekturen betreffen FCP und LCP [2][4]. Wenn dein Shop vorher wegen zu viel JavaScript träge auf Klicks reagierte, tut er das immer noch (Einschätzung). Die Stellen, an denen du ansetzen solltest, unterscheiden sich je nach System.

WordPress: Theme, Plugins, Cache und Server

• Plugins: Zahl und Qualität der Plugins haben laut WordPress-Doku einen großen Einfluss. Unnötige Plugins deaktivieren und löschen ist der einfachste Hebel; bei Verdacht einzelne Plugins testweise abschalten und messen [11].
• Theme: Ein schlankes Theme arbeitet deutlich effizienter als ein schweres, grafiklastiges [11]. Page-Builder-Themes mit vielen Modulen gehören in diese Prüfung (Einschätzung).
• Cache: Ein Cache-Plugin speichert Seiten als statische Dateien und entlastet den Server; ein dauerhafter Objekt-Cache spart Datenbankabfragen und verbessert die Serverantwortzeit [11].
• Autoload-Optionen und Server: Einstellungen, die Plugins und Themes bei jedem Aufruf laden, sollten zusammen unter 800 KB bleiben. Dazu kommen aktuelle PHP- und Datenbankversionen und ausreichend starkes Hosting [11].

Gerade Tracking-, Chat- und Cookie-Skripte von Drittanbietern laufen bei WordPress oft über Plugins. Wie du sie prüfst und absicherst, steht im Beitrag zu Drittanbieter-Skripten.

Shopify: Theme, Apps und eigener Code

Shopify nennt drei Hauptfaktoren: das Theme, die installierten Apps und zusätzlicher Code von Drittanbietern, ausdrücklich auch Tag-Manager und die Tags darin [12]. Konkret rät Shopify:

• ein aktuelles, optimiertes Theme nutzen; die Horizon-Familie und die Online-Store-2.0-Themes von Shopify sind auf Ladezeit ausgelegt [12],
• nicht zu viele Abschnitte (Sections) auf eine Seitenvorlage setzen und Seitenübergänge oder Animationen vorher und nachher messen [12],
• Apps und Tags regelmäßig auf ihren Nutzen prüfen. Wichtig: Eine App zu deinstallieren entfernt ihren Code nicht automatisch aus dem Theme [12].

Viele Hinweise aus PageSpeed Insights laufen bei Shopify ins Leere. CDN, Browser-Caching, Komprimierung und Minifizierung erledigt die Plattform bereits; Empfehlungen zu Serverkonfiguration oder Caching-Headern kannst du nicht umsetzen [12]. Relevant sind die Punkte zu Bildern, Apps und Theme. Schlechte INP-Werte entstehen laut Shopify meist durch zu viel JavaScript aus Theme, Apps oder Tag-Manager [12].

Für Felddaten hat Shopify eigene Web-Performance-Berichte im Admin. Sie erfassen echte Besuche aus Chromium-Browsern und Firefox und weichen deshalb von CrUX und PageSpeed Insights ab; der Leistungswert dort kombiniert Startseite, meistbesuchte Produkt- und Kollektionsseite der letzten 7 Tage [13]. Über die Admin-API lassen sich außerdem Ereignisse wie App-Installationen und Theme-Veröffentlichungen abrufen, bisher allerdings nur in der instabilen API-Version [14]. Weitere Shop-Einstellungen findest du im Leitfaden Shopify-SEO.

05 / Rankings

Bringt der bessere Wert bessere Rankings?

Google empfiehlt gute Core Web Vitals für den Erfolg in der Suche und schreibt, dass sie zusammen mit anderen Aspekten der Nutzererfahrung dem entsprechen, was die Ranking-Systeme belohnen wollen [10]. Gemeint sind die Core Web Vitals aus echten Nutzerdaten, nicht der Laborwert [10][7]. Weil das Lighthouse-Update nur die Simulation ändert, verändert es an deinen Rankings nichts (Einschätzung).

Umgekehrt gilt: Wenn dein Wert jetzt von 55 auf 75 gesprungen ist, ist die Arbeit nicht erledigt. Vergleich die Felddaten. Stehen LCP oder INP in der Search Console weiter auf „Optimierung erforderlich“, bleiben Theme, Plugins und Apps die Baustelle. Und wenn ein Kunde oder Dienstleister im November eine „Speed-Optimierung“ mit einem neuen Rekordwert belegt, frag nach der Lighthouse-Version beider Berichte.

FAQ

Häufige Fragen zu PageSpeed Insights und Lighthouse 13.6.

Warum ist mein PageSpeed-Score plötzlich besser?

Wenn du nichts geändert hast, liegt es wahrscheinlich an Lighthouse 13.6.0, das PageSpeed Insights seit Anfang November nutzt. Die neue Simulation berechnet FCP und LCP genauer und meist besser [1][2]. Prüf die Lighthouse-Version im Bericht.

Ändern sich auch die Core Web Vitals in der Search Console?

Nein. Der Core-Web-Vitals-Bericht beruht auf Felddaten echter Besucher aus CrUX, die vom Lighthouse-Modell unabhängig sind [3][7].

Wo sehe ich die Lighthouse-Version?

Im PageSpeed-Insights-Bericht neben dem emulierten Gerät [1]. In den Chrome-Entwicklertools kommt 13.6 erst mit Chrome 159 [2].

Quellen

Quellen

1. Search Engine Journal (Matt G. Southern): „Google Lighthouse Update Changes How PageSpeed Insights Simulates Loading“, 2. November 2026, mit Zitaten von Barry Pollard auf Bluesky – searchenginejournal.com · abgerufen 08.11.2026.
2. GoogleChrome/lighthouse: Release Notes „v13.6.0“, 27. Oktober 2026 – github.com · abgerufen 08.11.2026.
3. CSS Wizardry (Harry Roberts): „Web-Perf Wednesday 016 – Lighthouse 13.6 Can Lift Scores Without a Faster Site“, 4. November 2026 – csswizardry.com · abgerufen 08.11.2026.
4. Calibre: Changelog „Chrome 156 & Lighthouse 13.6.0“, 31. Oktober 2026 – calibreapp.com · abgerufen 08.11.2026.
5. Google for Developers: „About PageSpeed Insights“ – developers.google.com · abgerufen 08.11.2026.
6. Chrome for Developers: „Lighthouse performance scoring“ – developer.chrome.com · abgerufen 08.11.2026.
7. Search Console-Hilfe: „Core Web Vitals-Bericht“ – support.google.com · abgerufen 08.11.2026.
8. Search Console-Hilfe: „Search Console-Anmerkungen“ – support.google.com · abgerufen 08.11.2026.
9. web.dev: „Why lab and field data can be different (and what to do about it)“ – web.dev · abgerufen 08.11.2026.
10. Google Search Central: „Understanding Core Web Vitals and Google search results“ – developers.google.com · abgerufen 08.11.2026.
11. WordPress Advanced Administration Handbook: „Optimization“ – developer.wordpress.org · abgerufen 08.11.2026.
12. Shopify Help Center: „Improving your online store performance“ – help.shopify.com · abgerufen 08.11.2026.
13. Shopify Help Center: „Overview of web performance“ – help.shopify.com · abgerufen 08.11.2026.
14. Shopify Developers: „Testing for performance“ – shopify.dev · abgerufen 08.11.2026.

Alle Quellen am 8. November 2026 abgerufen. Barry Pollards Aussagen auf Bluesky vom 2. November 2026 sind über Search Engine Journal und CSS Wizardry zitiert. Aussagen ohne belastbare Quelle sind im Text als Einschätzung gekennzeichnet; die Ziffern in eckigen Klammern verweisen auf die Nummern dieser Liste.