Dieser Artikel stammt von meinem Freund Ben, der Calibre betreibt, ein Tool zur Überwachung der Leistung von Websites. Wir verwenden Calibre hier auf CSS-Tricks, um die Dinge im Auge zu behalten. Tatsächlich bin ich gerade dort vorbeigeschaut, um mir alles anzusehen, und wurde auf einige kleine Fehler hingewiesen, die durchgerutscht sind, und ich habe sie behoben. Sehr empfehlenswert!
In diesem Artikel enthüllen wir, wie PageSpeed seine kritische Geschwindigkeitsbewertung berechnet.
Es ist kein Geheimnis, dass Geschwindigkeit zu einem entscheidenden Faktor für die Steigerung des Umsatzes und die Senkung der Abbruchraten geworden ist. Da Google nun die Seitengeschwindigkeit als Rankingfaktor nutzt, haben sich viele Organisationen intensiv auf die Leistung konzentriert.
Letztes Jahr hat Google zwei wesentliche Änderungen an seinen Algorithmen für die Suchindizierung und das Ranking vorgenommen
- Im März wurde die Indizierung auf der mobilen Version einer Seite statt auf der Desktop-Version basiert.
- Im Juli wurde der SEO-Ranking-Algorithmus aktualisiert, um die Seitenladegeschwindigkeit als Rankingfaktor sowohl für mobile Seiten als auch für Anzeigen einzubeziehen.
Daraus können wir zwei Wahrheiten ableiten:
- Die Geschwindigkeit Ihrer Website auf Mobilgeräten wirkt sich auf Ihr gesamtes SEO-Ranking aus.
- Wenn Ihre Seiten langsam geladen werden, verringert sich Ihr Qualitätsfaktor für Anzeigen, und Anzeigen werden teurer.
Google schrieb:
Schnellere Websites verbessern nicht nur die Benutzererfahrung; aktuelle Daten zeigen, dass die Verbesserung der Website-Geschwindigkeit auch die Betriebskosten senkt. So wie wir legen auch unsere Nutzer großen Wert auf Geschwindigkeit – deshalb haben wir beschlossen, die Website-Geschwindigkeit bei unseren Suchrankings zu berücksichtigen.
Um zu verstehen, wie sich diese Änderungen aus Leistungsperspektive auf uns auswirken, müssen wir die zugrunde liegende Technologie verstehen. PageSpeed 5.0 ist eine komplette Überarbeitung früherer Ausgaben. Es wird jetzt von Lighthouse und CrUX (Chrome User Experience Report) angetrieben.
Dieses Upgrade bringt auch einen neuen Scoring-Algorithmus mit sich, der es deutlich schwieriger macht, eine hohe PageSpeed-Punktzahl zu erzielen.
Was hat sich in PageSpeed 5.0 geändert?
Vor Version 5.0 führte PageSpeed eine Reihe von Heuristiken gegen eine gegebene Seite aus. Wenn die Seite große, unkomprimierte Bilder hatte, schlug PageSpeed die Bildkomprimierung vor. Cache-Header fehlten? Fügen Sie sie hinzu.
Diese Heuristiken waren mit einer Reihe von Richtlinien gekoppelt, die wahrscheinlich zu einer besseren Leistung führten, wenn sie befolgt wurden, aber sie waren lediglich oberflächlich und analysierten nicht die Lade- und Render-Erfahrung, mit der echte Besucher konfrontiert sind.
In PageSpeed 5.0 werden Seiten in einem echten Chrome-Browser geladen, der von Lighthouse gesteuert wird. Lighthouse zeichnet Metriken vom Browser auf, wendet ein Scoring-Modell darauf an und präsentiert eine Gesamtleistungsbewertung. Verbesserungsvorschläge werden basierend auf der Bewertung spezifischer Metriken vorgeschlagen.
Wie PageSpeed hat auch Lighthouse eine Leistungsbewertung. In PageSpeed 5.0 wird die Leistungsbewertung direkt von Lighthouse übernommen. Die Geschwindigkeitsbewertung von PageSpeed ist jetzt dieselbe wie die Lighthouse-Leistungsbewertung.

Nachdem wir nun wissen, woher die PageSpeed-Bewertung stammt, wollen wir uns damit beschäftigen, wie sie berechnet wird und wie wir sinnvolle Verbesserungen erzielen können.
Was ist Google Lighthouse?
Lighthouse ist ein Open-Source-Projekt, das von einem engagierten Team von Google Chrome betrieben wird. In den letzten Jahren hat es sich zum wichtigsten kostenlosen Werkzeug für die Leistungsanalyse entwickelt.
Lighthouse verwendet das Chrome Remote Debugging Protocol, um Netzwerkanfrageinformationen zu lesen, die JavaScript-Leistung zu messen, Barrierefreiheitsstandards zu beobachten und benutzerzentrierte Zeitmetriken wie First Contentful Paint, Time to Interactive oder Speed Index zu messen.
Wenn Sie an einem Überblick über die Architektur von Lighthouse interessiert sind, lesen Sie diese Anleitung aus dem offiziellen Repository.
Wie Lighthouse die Leistungsbewertung berechnet
Während Leistungstests zeichnet Lighthouse viele Metriken auf, die sich auf das konzentrieren, was ein Benutzer sieht und erlebt. Sechs Metriken werden verwendet, um die Gesamtleistungsbewertung zu erstellen. Diese sind:
- Time to Interactive (TTI)
- Speed Index
- First Contentful Paint (FCP)
- First CPU Idle
- First Meaningful Paint (FMP)
- Estimated Input Latency
Lighthouse wendet ein Scoring-Modell von 0 bis 100 auf jede dieser Metriken an. Dieser Prozess funktioniert, indem die 75. und 95. Perzentile für Mobilgeräte von HTTP Archive abgerufen und dann eine log-normale Funktion angewendet wird.
Wenn wir dem Algorithmus und den Referenzdaten zur Berechnung von Time to Interactive folgen, sehen wir, dass, wenn eine Seite "interaktiv" in 2,1 Sekunden wurde, die Time to Interactive-Metrikbewertung 92/100 wäre.

Sobald jede Metrik bewertet ist, erhält sie eine Gewichtung, die als Modifikator bei der Berechnung der Gesamtleistungsbewertung verwendet wird. Die Gewichtungen sind wie folgt:
| Metrik | Gewichtung |
|---|---|
| Time to Interactive (TTI) | 5 |
| Speed Index | 4 |
| First Contentful Paint | 3 |
| First CPU Idle | 2 |
| First Meaningful Paint | 1 |
| Estimated Input Latency | 0 |
Diese Gewichtungen beziehen sich auf die Auswirkungen jeder Metrik in Bezug auf die mobile Benutzererfahrung.
In Zukunft kann dies auch durch die Einbeziehung von nutzerbasierten Daten aus dem Chrome User Experience Report-Datensatz verbessert werden.
Sie fragen sich vielleicht, wie sich die Gewichtung jeder Metrik auf die Gesamtleistungsbewertung auswirkt. Das Lighthouse-Team hat einen nützlichen Google Spreadsheet-Rechner erstellt, der diesen Prozess erklärt.

Am obigen Beispiel sehen wir, wenn wir die interaktive Zeit von 5 Sekunden auf 17 Sekunden (die globale durchschnittliche mobile TTI) ändern, fällt unsere Bewertung auf 56 % (auch bekannt als 56 von 100).
Wenn wir jedoch First Contentful Paint auf 17 Sekunden ändern, erhalten wir 62 %.
TTI ist die wirkungsvollste Metrik für Ihre Leistungsbewertung. Daher benötigen Sie für eine hohe PageSpeed-Bewertung eine schnelle TTI-Messung.
Die Nadel bei TTI bewegen
Auf hoher Ebene gibt es zwei wesentliche Faktoren, die TTI stark beeinflussen:
- Die Menge an JavaScript, die der Seite geliefert wird
- Die Laufzeit von JavaScript-Aufgaben auf dem Hauptthread
Unser Time to Interactive Leitfaden erklärt im Detail, wie TTI funktioniert, aber wenn Sie nach schnellen Gewinnen ohne Recherche suchen, würden wir vorschlagen: Reduzieren Sie die Menge an JavaScript
Entfernen Sie nach Möglichkeit ungenutzten JavaScript-Code oder konzentrieren Sie sich darauf, nur ein Skript zu liefern, das von der aktuellen Seite ausgeführt wird. Das könnte bedeuten, alte Polyfills zu entfernen oder Drittanbieter-Bibliotheken durch kleinere, modernere Alternativen zu ersetzen.
Es ist wichtig zu bedenken, dass die Kosten von JavaScript nicht nur die Download-Zeit sind. Der Browser muss es dekomprimieren, parsen, kompilieren und schließlich ausführen, was erhebliche Zeit in Anspruch nimmt, insbesondere auf Mobilgeräten.
Effektive Maßnahmen zur Reduzierung der Skriptmenge auf Ihren Seiten umfassen:
- Überprüfen und Entfernen von Polyfills, die für Ihr Publikum nicht mehr erforderlich sind.
- Verständnis der Kosten jeder Drittanbieter-JavaScript-Bibliothek. Verwenden Sie webpack-bundle-analyser oder source-map-explorer, um die Größe jeder Bibliothek zu visualisieren.
- Moderne JavaScript-Tools (wie webpack) können große JavaScript-Anwendungen in eine Reihe kleiner Bundles aufteilen, die automatisch geladen werden, während ein Benutzer navigiert. Dieser Ansatz wird als Code Splitting bezeichnet und ist extrem effektiv bei der Verbesserung von TTI.
- Service Worker, die das Bytecode-Ergebnis eines geparsten und kompilierten Skripts cachen. Wenn Sie dies nutzen können, zahlen Besucher einen einmaligen Leistungskosten für das Parsen und Kompilieren. Danach wird dies durch den Cache gemildert.
Time to Interactive überwachen
Um signifikante Unterschiede in der Benutzererfahrung erfolgreich aufzudecken, empfehlen wir die Verwendung eines Leistungsüberwachungssystems (wie Calibre!), das das Testen mit mindestens zwei Geräten ermöglicht: einem schnellen Desktop und einem Mittelklasse-Mobiltelefon.
Auf diese Weise haben Sie die Daten für die beste und schlechteste Erfahrung, die Ihre Kunden machen. Es ist an der Zeit zu akzeptieren, dass Ihre Kunden nicht dieselbe leistungsstarke Hardware verwenden wie Sie.
Umfassendes manuelles Profiling
Um die besten Ergebnisse bei der Analyse der JavaScript-Leistung zu erzielen, testen Sie Seiten mit absichtlich langsamen Mobilgeräten. Wenn Sie ein altes Handy in einer Schreibtischschublade haben, ist dies eine großartige zweite Verwendung dafür.
Ein ausgezeichneter Ersatz für die Verwendung eines echten Geräts ist der Chrome DevTools Hardware Emulation Mode. Wir haben einen ausführlichen Leistungsanalyse-Leitfaden verfasst, der Ihnen den Einstieg in die Laufzeit-Performance erleichtert.
Was ist mit den anderen Metriken?
Speed Index, First Contentful Paint und First Meaningful Paint sind allesamt browserbasierte Paint-Metriken. Sie werden von ähnlichen Faktoren beeinflusst und können oft gleichzeitig verbessert werden.
Es ist objektiv einfacher, diese Metriken zu verbessern, da sie danach berechnet werden, wie schnell eine Seite gerendert wird. Wenn Sie die Lighthouse Performance Audit-Regeln genau befolgen, werden diese Metriken verbessert.
Wenn Sie Ihre Schriftarten noch nicht vorladen oder für kritische Anfragen optimieren, ist dies ein ausgezeichneter Ausgangspunkt für eine Leistungsreise. Unser Artikel mit dem Titel „Der kritische Request“ erklärt im Detail, wie der Browser kritische Ressourcen abruft und rendert, die zum Rendern Ihrer Seiten verwendet werden.
Verfolgung Ihres Fortschritts und Durchführung sinnvoller Verbesserungen
Die neu aktualisierte Suchkonsole von Google, Lighthouse und PageSpeed Insights bieten eine gute Möglichkeit, erste Einblicke in die Leistung Ihrer Seiten zu erhalten, reichen aber nicht aus für Teams, die die Leistung ihrer Seiten kontinuierlich verfolgen und verbessern müssen.
Kontinuierliche Leistungsüberwachung ist unerlässlich, um sicherzustellen, dass Geschwindigkeitsverbesserungen Bestand haben, und Teams werden sofort benachrichtigt, wenn Regressionen auftreten. Manuelles Testen führt zu unerwarteter Variabilität der Ergebnisse und macht Tests aus verschiedenen Regionen sowie auf verschiedenen Geräten fast unmöglich, ohne eine dedizierte Laborumgebung.
Geschwindigkeit ist zu einem entscheidenden Faktor für SEO-Rankings geworden, insbesondere da fast 50 % des Webverkehrs von Mobilgeräten stammen.
Um den Verlust Ihrer Suchpositionierung zu vermeiden, stellen Sie sicher, dass Sie eine aktuelle Leistungsabteilung verwenden, um wichtige Seiten zu verfolgen. (Psst, wir haben Calibre zu Ihrem Leistungsbegleiter entwickelt. Es hat Lighthouse integriert. Hunderte von Teams aus aller Welt nutzen es jeden Tag.)
Danke für den tollen Artikel. Wir haben viele Optimierungen an unserer Website vorgenommen, aber wenn wir eine Seite von unserer Website in PSInsights testen, werden wir durch das langsame Laden von Google AdSense JS und Bildern bestraft, das ist also ein Google-Problem.
Wissen Sie, ob Google eine andere (interne) Score-Bewertung (z. B. ohne ihre Anzeigen) für SEO verwendet, oder dieselbe? Denn wenn dieselbe, dann ist das nicht fair. Wenn wir AdSense-Anzeigen ausschalten, ist unsere Score-Bewertung viel höher.
Danke Boris! Freut mich, dass Sie es nützlich fanden ♂️
Ich glaube nicht, dass Google seine Anzeigen anders behandelt als die von Drittanbietern. Ich halte es für heuchlerisch, Websites anhand ihrer Leistung zu bewerten, aber auch Anzeigen zu verkaufen, von denen bekannt ist, dass sie die Benutzererfahrung negativ beeinflussen.
Das ist eine seltsame Situation, in die sich Google selbst bringt. Wenn sie das Gegenteil tun würden (Drittanbieter-Anzeigen bestrafen, die nicht von Google stammen), wären wesentlich mehr Leute verärgert... zumindest denke ich das.
Pagespeed/Lighthouse bevorzugt kleine statische Websites (DOM- und Skriptgröße) und aus UI-Sicht ist das nicht cool. Wenn man ein schönes Design für eine komplizierte Seite hat, ist es nie eine kleine DOM-Größe.