Ladegeschwindigkeit messen und verstehen. Messwerte und Tools
Die Ladegeschwindigkeit einer Website ist seit ca. 2010 ein Ranking-Signal für Suchmaschinen. Allerdings besteht die Ladegeschwindigkeit nicht aus einem einzigen Messwert. In diesem Blog-Beitrag sehen wir uns an das Messen der Ladegeschwindigkeit genauer an. Du erfährst, welche wichtigen Messwerte es für die Ladegeschwindigkeit gibt, wie sie voneinander abhängen und wie du sie misst. Schließlich erfährst du, was du ohne Programmierkenntnisse tun kannst, um die Geschwindigkeit deiner Website zu optimieren.
- Die Ladegeschwindigkeit einer Seite ist ein Ranking-Signal
- Ist der Page Speed Score ein Ranking-Signal?
- Die Core Web Vitals sind Ranking Signale
- Die drei Kategorien für die Ladegeschwindigkeit einer Seite
- Ladegeschwindigkeit einer Website messen
- Optimieren der Ladegeschwindigkeit
- Zusammenfassung
Die Ladegeschwindigkeit einer Seite ist ein Ranking-Signal
Google hat 2010 in einem Blog-Beitrag angekündigt, dass die Ladegeschwindigkeit einer Seite ein Ranking Signal wird.
Nun liegt das Jahr 2010 schon etwas weiter zurück. Damals lag der Fokus noch auf der Ladegeschwindigkeit für den Desktop, aber seit 2018 berücksichtigt Google ausschließlich die Geschwindigkeit deiner Seiten auf mobilen Endgeräten.
Allerdings schreibt Google im Blog-Beitrag von 2010 auch sehr deutlich, dass die Ladegeschwindigkeit einer Seite als Ranking Signal nicht so wichtig wie die inhaltliche Relevanz einer Seite ist.
Das gilt auch heute noch, denn Google wird eher eine langsame Seite mit relevantem Inhalt in den SERPs anzeigen als eine irrelevante Seite, die schnell lädt.
Eine bessere Geschwindigkeit wird deine Seite also nicht auf einmal um 20 Plätze nach oben katapultieren. Sie kann aber nützlich sein, um Seiten mit gleich oder ähnlich relevanten Inhalten in den Suchergebnissen zu überholen.
Ist der Page Speed Score ein Ranking-Signal?
Ungefähr 95 % aller Anfragen für einen Pagespeed Audit beziehen sich auf den Page-Speed Score, der im Pagespeed Tool mittlerweile als Leistung angezeigt wird.
Pagespeed Score unter “Leistung” im Google Pagespeed Tool
Das ist kein Ranking-Signal. Der Leistungswert ist vielmehr ein berechneter Wert, dem viele andere Messwerte zur Ladegeschwindigkeit einer Seite zugrunde liegen. Die wichtigsten davon lernst du in diesem Artikel noch kennen.
Für die Bewertung der Ladegeschwindigkeit als Ranking-Signal zieht Google die sogenannten Core Web-Vitals heran.
Die Core Web Vitals sind Ranking Signale
Für die Ladegeschwindigkeit verwendet Google die sogenannte Core Web Vitals als Ranking Signal. Das sind drei Messwerte aus den sogenannten _Web Vitals (ohne_Core). Das sind wiederum standardisierte Messwerte, um die Ladegeschwindigkeit einer Website zu messen. Die reinen Web Vitals sind allerdings keine Ranking-Signale.
Sie können aber die drei Messwerte der Core Web Vitals beeinflussen.
Die drei Core Web Vitals sind:
- Der Largest Contentful Paint (LCP). Dieser Wert wird in Sekunden gemessen und sollte schneller als 2.5 Sekunden sein
- Die Interaction to next Paint (INP). Er wird in Millisekunden gemessen und sollte unter 200 Millisekunden liegen
- Die kumulative Layoutverschiebung (cumulative Layout Shift; CLS) wird als Faktor gemessen und sollte kleiner als 0.1 sein.
Bevor ich nun näher auf die Core Web Vitals eingehe, sehen wir uns einige Messwerte zur Ladegeschwindigkeit an und wie sie die Core Web Vitals beeinflussen können.
Die drei Kategorien für die Ladegeschwindigkeit einer Seite
Die Ladegeschwindigkeit ist etwas mehr als einfach nur die Zeitspanne, bis eine Seite geladen wurde. Sie lässt sich in drei Kategorien unterteilen:
- Die technische Ladegeschwindigkeit.
- Die Darstellungsgeschwindigkeit.
- Die Reaktionsgeschwindigkeit
Die technische Ladegeschwindigkeit einer Website
Die technische Ladegeschwindigkeit ist die Zeitspanne vom Start des Ladevorgangs bis zu dem Zeitpunkt, an dem der Browser zunächst die HTML-Seite und danach alle notwendigen Ressourcen wie Bilder, JavaScript, CSS-Dateien und Schriftarten vom Server geladen hat.
Diese Kategorie ist die Wichtigste, um die Ladegeschwindigkeit zu messen und zu analysieren. Denn wenn es schon eine halbe Ewigkeit dauert, bis der Browser die HTML-Datei vom Server geladen hat, wird die Seite bei den anderen Messwerten der anderen Kategorien und bei den Core Web Vitals keine guten Werte erzielen.
Die Messwerte der technischen Ladegeschwindigkeit
Leider sind sich die Tool-Hersteller bei der Benennung der Messwerte dieser Kategorie nicht ganz einig. Manche verwenden dafür den Begriff Download-Zeit, andere nennen es Netzwerk-Zeit und wieder andere ganz einfach die Ladegeschwindigkeit. Ich bleibe beim Begriff technische Ladegeschwindigkeit.
Die wichtigsten Messwerte für diese Kategorie sind:
- Die Domain-Suchzeit oder kurz DNS-Zeit. Das ist die Zeitspanne, die dein Browser benötigt, um aus dem Domain-Namen deiner Website die IP-Adresse deines Webservers zu ermitteln, von dem er die HTML-Datei oder eine Ressource wie ein Bild, eine CSS-Datei, eine Schriftart oder eine Javascript-Datei laden soll.
- Die Server-Verbindungszeit wird manchmal als Connect-Zeit bezeichnet. Das ist die Zeitspanne, in der dein Browser eine verschlüsselte Verbindung mit HTTPS zum Server aufbaut, von dem eine Datei geladen werden soll.
- Mit der Redirect-Zeit misst du die Zeit, die dein Server für alle Arten von 3xx Umleitungen wie 301 oder 302 benötigt.
- Die *Warte-Zeit, *manchmal einfach nur als Wait bezeichnet, ist die Zeitspanne, die ein Server braucht, um die Anfrage zum Herunterladen der HTML-Datei zu verarbeiten. Das ist die Summe der drei vorherigen Messwerte: der Domain-Suchzeit, der Server-Verbindungszeit und der Redirect-Zeit.
- Die *Time-to-first-Byte *(kurz TTFB) ist die Zeitspanne vom Senden der Anfrage des Browsers an den Server, bis der Browser das erste Byte einer Datei, wie einer HTML-Seite, empfangen hat. Sie setzt sich also aus der Domain-Suchzeit, der Server-Verbindungszeit, der Redirect-Zeit und der Warte-Zeit zusammen.
- Mit Receive wird die Zeitspanne gemessen, die der Browser braucht, um die gesamte Datei (HTML-Datei, Bild-Datei, Schrift-Datei, etc.) zu empfangen.
- Der Messwert Anzahl der Anfragen gilt nur für die HTML-Datei und sagt dir, wie oft der Browser eine Anfrage an einen Server schicken muss, um alle benötigten Ressourcen einer HTML-Datei wie Bilder, JavaScripte, CSS-Dateien oder Schriftarten zu laden
Jeder einzelne der ersten 4 Messwerte der technischen Ladegeschwindigkeit sollte für sich betrachtet im niedrigen Millisekunden-Bereich liegen und deutlich weniger als 100 Millisekunden betragen.
Sieh dir von diesen Messwerten als Erstes den TTFB (Time-to-First-Byte) an. Er sollte bei maximal 800 Millisekunden liegen. Zumindest erwähnt Google die 0,8 Sekunden für TTFB auf web.dev. Allerdings gibt es auch Aussagen, dass dieser Wert bei 600 Millisekunden liegen sollte. Ich arbeite bei meinen technischen SEO-Audits immer mit dem Wert 600 Millisekunden. Liegt der Wert über 600 Millisekunden, ist das der erste Ansatzpunkt, um die Ladegeschwindigkeit zu optimieren. Einige Ideen für Maßnahmen findest du weiter unten im Artikel im Kapitel technische Ladezeit optimieren.
Core Web Vitals & die technische Ladegeschwindigkeit
Bei den Core Web Vitals gibt es keine direkte Entsprechung für die technische Ladegeschwindigkeit. Allerdings beeinflusst die technische Ladegeschwindigkeit insbesondere den Core Web Vitals Messwert namens Largest Contentful Paint (LCP).
Die Browser-Zeit oder Darstellungszeit
Hat ein Webbrowser die HTML-Datei geladen, analysiert er die Seite und lädt Ressourcen wie Bilder oder CSS-Dateien. Sobald genügend Ressourcen geladen wurden, beginnt der Browser, die Seite im Browser darzustellen.
Die Zeitspanne vom Beginn des Ladevorgangs einer Seite bis zur Darstellung im Browser-Fenster wird als *Browser-Zeit *oder Darstellungszeit bezeichnet. In dieser Zeit ermittelt der Browser zunächst das Layout der Seite. Parallel dazu wird auch gleich ermittelt, wie Elemente auf der Seite dargestellt werden.
Messwerte für die Browser-Zeit
Für die Browser-Zeit gibt es vier wichtige Messwerte, die auf dem Lighthouse-Tool basieren. Dieses Tool ist die Grundlage des Google Pagespeed-Tools.
- Erste Inhalte gezeichnet (engl. First Contentful Paint, kurz FCP) ist die Zeitspanne, die der Webbrowser benötigt, um den ersten Inhalt wie etwa einen Text oder ein Bild darzustellen.
- Der Speed Index misst, wie schnell Inhalte beim Seitenaufbau dargestellt werden.
- Der Largest Contentful Paint ist Teil der Core Web Vitals und misst, wie lange es dauert, bis das größte Element der Seite above the fold dargestellt werden kann.
- Die Kumulative Layoutverschiebung (engl. Cumulative Layout Shift, kurz CLS) ist ebenfalls ein Teil der Core Web-Vitals und misst anhand eines Index, wie stark sich das Layout einer Seite während des Ladens noch ändert.
Die Browser-Zeit in den Core Web Vitals
Die Browser-Zeit beeinflusst am ehesten den Largest Contentful Paint (LCP) und die kumulative Layoutverschiebung (CLS).
Die Interaktionszeit
Die dritte und letzte Kategorie misst, wie lange es dauert, bis deine Website nach dem Beginn des Ladens auf Benutzereingaben, etwa auf einen Klick auf einen Link, reagiert. Verwendet deine Website etwa ein sehr komplexes Layout oder sehr viel Javascript, kann das die Reaktionsfreudigkeit deiner Seite beeinflussen.
Messwerte der Interaktionszeit
Für die Interaktionszeit gibt es folgende zwei Messwerte:
- Die Total Blocking Time (TBT) ist die Zeitspanne nach dem First Contentful Paint und der Darstellung der Website, während der es zu Verzögerungen bei der Interaktion kommen kann.
- Die Interaction to next Paint ist ein Messwert der Core Web Vitals. Mit diesem Messwert wird erfasst, wie schnell eine Seite auf Nutzereingaben wie Klicken oder Tastaturinteraktionen reagiert. Während die Total Blocking Time nur beim Laden der Seite gemessen wird, berücksichtigt die Interaction to next Paint die Interaktionsfreudigkeit deiner Seite während der gesamten Zeit, während Menschen mit ihr interagieren.
Die Interaktions-Zeit und die Core Web Vitals
In den Core Web Vitals wird die Reaktionsfreudigkeit deiner Website mit dem Messwert Interaction to next Paint gemessen.
Ladegeschwindigkeit einer Website messen
Nachdem du nun die wichtigsten Werte zum Messen der Ladegeschwindigkeit kennst, geht es im nächsten Schritt darum, die angezeigten Messwerte richtig zu interpretieren. Dafür gibt es wiederum 3 Kategorien von Messwerten.
Eine erste Kategorie einer Messung mit einem Pagespeed Tool ergibt in der Regel einen sogenannten Lab-Wert. Das ist eine Messung zu einem bestimmten Zeitpunkt, die schon in der nächsten Minute anders sein kann. Etwa, weil dein Webserver dann nicht mehr so stark ausgelastet ist. Nimm Lab-Werte eines Pagespeed-Tools als das, was sie sind: nämlich Hinweise.
Beachte beim Durchführen einer Messung bitte auch den Standort deines Servers und den Standort, von dem aus du die Messung durchführst. Das kann teils drastische Unterschiede in den Ergebnissen bewirken. Deswegen bieten viele Pagespeed-Tools eine Standortauswahl, von der aus du die Messung durchführen kannst.
In GTMetrix kannst du in der kostenlosen Version durch einen Klick auf das Feld einen Standort auswählen. Verwende dabei den Standort, der deinen Besuchern und Besucherinnen am nächsten ist.
Serverstandort in GTmetrix auswählen
Speziell bei den Core Web Vitals gibt es noch zwei Kategorien von Messwerten, die du berücksichtigen solltest. Neben den Lab-Daten gibt es noch die Felddaten und bzw. oder die Ursprungsdaten (Origin).
Die Felddaten stammen aus dem Chrome UX Report und werden von Nutzer:Innen auf der ganzen Welt erhoben, die den Chrome-Browser verwenden. Felddaten für Core Web Vitals siehst du allerdings nur dann, wenn Google genügend Daten erfasst hat. Dafür braucht jede Seite ein paar 1000 Besucher oder Besucherinnen pro Monat.
Hat die getestete Seite nicht genügend erfasste Felddaten, siehst du die sogenannten Ursprungsdaten (Origin). Das ist ein Mittelwert für jede Seite deiner Website. Gibt es auch nicht genügend Messwerte für Ursprungsdaten, siehst du nur den Lab-Wert.
Ob für eine Seite im Pagespeed Tool Felddaten oder Ursprungsdaten angezeigt werden, siehst du rechts unterhalb des Eingabefeldes. Hier ist entweder der Text* diese URL (=Felddaten)* hervorgehoben oder Ursprung.
Felddaten und Ursprungsdaten im Google Pagespeed Tool
Ursprungsdaten siehst du beispielsweise auch im SEO-Tool Screaming Frog. Im folgenden Screenshot siehst du am Beispiel des Largest Contentful Paint und der kumulativen Layoutverschiebung die Ursprungsdaten. Sie sind für jede URL gleich.
Ursprungsdaten (Origin) zum Pagespeed im Screaming Frog
Tools um die Ladezeit zu messen
Das Google Pagespeed-Tool ist wohl das bekannteste Tool, um die Ladegeschwindigkeit einer Seite zu messen.
Es gibt aber noch andere Möglichkeiten:
- Mit dem Screaming Frog, indem du eine API-Verbindung mit dem Page-Speed Tool herstellst.
- Mit dem online Tool GTMetrix
- Direkt aus dem Chrome Browser, indem du die Entwickler-Tools öffnest und auf das Tab Lighthouse klickst.
- Mit dem Multi-Page-Speed Test von experte.de
- Mit der kostenlosen Variante des Website Speed Tests von Pingdom.
- Direkt in der Google Search Console
Mit Ausnahme des Screaming Frog sind alle oben genannten Tools browserbasiert. Damit kannst du eine Ladegeschwindigkeit einer einzelnen Seite oder einer Handvoll Seiten messen.
Mit dem Screaming Frog kannst du allerdings alle Seiten deiner Website sowohl auf die Core Web Vitals als auch die anderen Messwerte testen.
In der Google Search Console hingegen siehst du die für deine Website erfassten Messwerte für die Core Web Vitals aus dem Chrome UX Bericht für Desktop und für mobile Endgeräte
Core Web Vitals in der Google Search Console
Optimieren der Ladegeschwindigkeit
Bei den Tipps zur Optimierung der Ladegeschwindigkeit beschränke ich mich auf Tipps, die du mit ein wenig technischem Know-how selbst und ohne Programmierkenntnisse durchführen kannst.
Gehe bei der Optimierung strukturiert vor und beginne idealerweise mit der Optimierung der technischen Ladegeschwindigkeit. Das ist in vielen Fällen der größte Hebel.
Optimieren der technischen Ladegeschwindigkeit
Wie du die technische Ladegeschwindigkeit optimierst, hängt natürlich von deiner Content-Management-Lösung ab
- Nutze für WordPress ein Caching-Plug-in. Dadurch müssen die Seiten nicht bei jeder Anfrage von WordPress neu erstellt und ausgeliefert werden.
- Prüfe mit einem passenden Tool die Warte-Zeit. Eine Wartezeit über 500 Millisekunden, kann auf ein Datenbank-Problem bei deinem Content-Management hindeuten oder darauf, dass du zu viele Plug-Ins verwendest, die eine Seite noch verändern, bevor sie vollständig an den Browser gesendet wird.
- Reduziere die Anzahl der Ressourcen auf deinen Seiten und schmeiße alles raus, was nicht zum Engagement oder zur Conversion beiträgt: überflüssige Bilder, CSS-Dateien, JavaScript, Widgets und Schriftarten.
- Reduziere die Größe der Ressourcen auf deiner Website, insbesondere die Größe der Bilder. Lade dazu die Bilder in der maximal benötigten Auflösung hoch und komprimiere sie vorher noch mit Tools wie etwa tinify.com
- Vermeide interne 3xx Weiterleitungen für häufig aufgerufene Seiten. Setze interne links direkt auf die Zielseiten.
- Verwende ein Content-Delivery-Network (CDN) wie Cloudflare. Verwendet dein CMS-Anbieter schon ein CDN für Bilder wie etwa Jimdo und Squarespace, ist der Effekt eines zusätzlichen CDN für die HTML-Datei trotzdem spürbar!
Optimieren der Browser-Zeit
Ohne Eingriffe in das HTML, CSS und Javascript Code einer Seite hast du leider nur sehr wenig Optimierungsmöglichkeiten für die Browser-Zeit, nämlich:
- Verwende ein möglichst einfaches Template und verzichte auf komplexe Layouts.
- Reduziere die Anzahl der Widgets und Plug-ins, die Javascript verwenden. Falls du JavaScript basierende Widgets verwenden möchtest, verwende das "defer" oder "async" Attribut im Script-Tag.
- Reduziere die Inhalte, speziell above the fold, auf das Wesentliche.
- Verwende so wenig Schriftarten wie möglich. Das spart sowohl bei der Netzwerk-Zeit als auch bei der Browser-Zeit. Versuche, dich auf 2 Schriftarten zu beschränken.
Optimieren der Interaktionszeit
Die Tipps zum Optimieren der Interaktions-Zeit sind ähnlich den Tipps zum Optimieren der Browser-Zeit.
- Vermeide komplexe Layouts. Ein komplexes Layout kann die Anzahl der HTML-Elemente (der DOM-Elemente) erhöhen. Jedes zusätzliche DOM-Element kann die Berechnung des Layouts verlangsamen.
- Vermeide übermäßige CSS-Änderungen, in dem du in deinem CMS händische CSS-Styles angibst.
- Vermeide Widgets. Widgets, die unmittelbar nach dem Laden einer Seite eingefügt werden, wie ein Widget für deine letzten Instagram-Posts. Das verursacht eine Änderung des HTML deiner Seite. Das kann wiederum zur Folge haben, dass der Browser das Layout erneut berechnet werden muss und deine Seite nicht zeitnah auf Benutzereingaben reagieren kann.
Zusammenfassung
In diesem Blog-Beitrag hast du gelesen, wie du die Ladegeschwindigkeit richtig misst und analysierst. Der wichtigste Punkt aus diesem Artikel ist, dass die Ladegeschwindigkeit sich nicht mit einem Messwert erfassen lässt. Vielmehr hängen die für die Ladegeschwindigkeit wichtigen Messwerte für die Core Web Vitals von anderen Messwerten ab.
Beginne die Optimierung der Ladegeschwindigkeit stets mit der technischen Ladegeschwindigkeit. Das ist in den meisten Fällen der größte Hebel.
Bedenke aber bitte auch, dass der größte Hebel zu einem besseren Ranking noch immer der Content ist. Eine Suchmaschine wird eher relevanten Content anzeigen, der etwas langsamer lädt als weniger relevanten Content, der schnell lädt.