Das leidige Thema mit der Page Performance: Ein Leitfaden

Die Optimierung der Page Performance kann schon mal ausufern und birgt auch so manches Konfliktpotenzial zwischen SEO und Entwicklern. Mit diesem Artikel möchte ich Dir helfen, auf die richtigen Metriken zu schauen und Dich vor allem auf die richtigen Scorings und Optimierungen zu fokussieren. So gelingt es Dir, gemeinsam mit den Entwicklern gute Performance-Metriken im Wettbewerb zu erzielen, ohne permanent Ressourcen zu vergeuden. Das spart Zeit und eine Menge Nerven – auf allen Seiten. In diesem, ersten Teil fokussiere ich mich auf die Metriken und die Analyse von Optimierungspotenzialen. Im zweiten schauen wir uns dann die konkrete Vorgehensweise an.

Die Pageperformance im Team optimieren

Bevor sich der eine oder andere jetzt denkt, „Na toll, schon wieder ein Artikel über Pagespeed“, möchte ich gleich vorausschicken, dass es in diesem Beitrag nicht um die Erklärung einzelner Metriken geht, sondern um das Gesamtbild der Page Performance und die Fokussierung auf die Optimierung. SEOs haben in der Regel ein eigenes Toolset oder auch Prozesse zur Analyse aufgebaut und zur Verfügung, um den Problemen auf den Grund zu gehen. Manchmal hapert es an Hintergrundwissen, zum Beispiel wie welche Metriken interpretiert werden sollten oder was genau optimiert werden muss.

In den vergangenen Jahren seit der Einführung der Core Web Vitals (CWV) durch Google Anfang des Jahres 2020 ist dieses Thema in meinen Augen auch etwas ausgeufert und sorgt für Spannung zwischen uns SEOs, Websitebetreibern und Entwicklerteams. Nicht selten wird sich auf die falschen Messwerte versteift, was am Ende zu überzogenen Maßnahmen, schlechter Stimmung im Prozess und auch gerne mal enttäuschten Rankingerwartungen führt. Ich möchte unterstützen und helfen, die richtigen Hebel zu identifizieren und relevante Maßnahmen zu ergreifen, damit Du gerade bei technischen Optimierungen die richtige (und wichtige) Priorisierung von Maßnahmen vornehmen kannst. Ich zeige Dir vor allem auch auf, wie Du ein gutes Scoring für Deine Website bestimmen kannst an welchem Du die Performance vergleichen kannst.

Da es auch für die Messung verschiedene Methoden und Tools im Netz gibt, möchte ich auch hier auf die wichtigsten eingehen und aufzeigen, welche Informationen für die Pagespeed-Optimierung wirklich relevant sind und wie diese in die Maßnahmen einfließen können.

Um mich nicht zu wiederholen oder etwas auszulassen, möchte ich an dieser Stelle einmal auf die bisherigen Artikel und Videos zum Thema Pagespeed und deren Messwerte auf seokraktie.de hinweisen. Hier findest Du sehr gute Einführungen in die verschiedenen Ladezeit-Metriken:

• Julian erklärt die Grundlagen der Core Web Vitals in diesem Beitrag und für Lesefaule auch mit Video. 😊
• Timo erklärt in seinem Blogbeitrag ausführlich den neu eingeführten, für das Ranking relevanten, Messwert INP: „Core Web Vitals: Neuer Messwert INP (Interaction to Next Paint) ersetzt FID“
• Karin erläutert den First Contentful Paint.
• Nora zeigt Dir, wie Du grundlegend das Online Tool Pagespeed Insights von Google nutzen und zur Optimierung einsetzen kannst: „Ladezeit überprüfen und sofort verbessern mit PageSpeed Insights“
• Robin stellt die Total Blocking Time (TBT) vor – eine sehr wichtige Metrik für SEO-Experten.

Die Metriken der Page Performance – Was ist eigentlich wichtig?

An dieser Stelle kommt das erste klassische SEO-Statement: Kommt darauf an. Denn diese Frage hängt sehr stark davon ab, was wir betrachten und fokussieren wollen. Wenn es dabei um die rankingrelevanten Metriken geht, dann führt Google hier die folgenden drei Messwerte für die Core Web Vitals auf:

• Largest Contentful Paint (LCP): misst die Ladeleistung. Für eine gute Nutzerfreundlichkeit muss der LCP innerhalb von 2, 5 Sekunden nach dem ersten Laden der Seite ausgeführt werden.
• Interaction to Next Paint (INP): misst die Interaktivität. Für eine gute Nutzerfreundlichkeit müssen Seiten eine INP von 200 Millisekunden oder weniger haben.
• Cumulative Layout Shift (CLS): misst die visuelle Stabilität. Für eine gute Nutzererfahrung sollte ein CLS-Wert von 0,1 oder weniger beibehalten werden.

Screenshot der drei Messwerte der Core Web Vitals: LCP, INP und CLS.

Diese drei Kennzahlen sind eine weitere Berechnungsgrundlage für die Positionierungen neben den vielen anderen Rankingfaktoren, die von Google oder auch anderen SEOs genannt werden. Du solltest berücksichtigen, dass auch andere, nicht rankingrelevante Metriken die Nutzererfahrung trüben können und somit viele User direkt wieder zu den Suchergebnissen bei Google zurückkehren (Return to SERPs), was dann indirekt das Ranking beeinflussen kann.

Zur Erinnerung: Die Nutzererfahrung beschreibt im Wesentlichen die Wahrnehmung und Erfahrung von Websitebesuchen im Umgang mit der Website. Bei einer langsamen Website, muss man häufig warten bis man eine Aktion ausführen kann, was das Nutzungserlebnis trüben kann

Aber was genau verbirgt sich hinter diesen Core-Web-Vital-Kennzahlen und wie kannst Du diese optimieren?

Hinweis: Wir wollen uns an dieser Stelle auf die Performance-Daten fokussieren, da die Metriken zu Barrierefreiheit, Best Practices und SEO-Faktoren als Fleißarbeit und korrekte Umsetzung des Frontends betrachtet werden können. Hier gibt uns der Lighthouse-Test bereits aussagekräftige Hinweise zur Umsetzung, die für Entwickler gut nachvollziehbar und umsetzbar sind.

Ich zeige an dieser Stelle einmal beispielhaft die Hinweise aus dem Test auf. So kannst Du sehen, dass dieser schon sehr konkrete Umsetzungshinweise gibt – die für Entwickler häufig nicht noch extra erklärt werden müssen.

Barrierefreiheit

Der Lighthouse-Test gibt Dir gute Hinweise, wie Du Deine Website hinsichtlich der Barrierefreiheit optimieren kannst.

Best Practices

Screenshot zu den Best Practices im Lighthouse-Test.

SEO (Hints)

Der Lighthouse-Test gibt Dir grundlegende Tipps für die Suchmaschinenoptimierung Deiner Seite.

Die SEO Hints des Lighthouse-Tests können als eher performanceunabhängige Optimierungsmaßnahmen interpretiert werden, die die Zugänglichkeit für einen Crawler und allgemeine Bewertung von Website beschreiben.

Explizite Gegenüberstellung: Lighthouse-Test vs. Core Web Vitals

Im Lighthouse-Test werden Dir in der Ansicht zur Performance (Leistungen) noch mehr Metriken angezeigt als in den Core Web Vitals. LCP und CLS sind auch hier vorhanden, aber der INP fehlt, was verwirrend sein kann. Stattdessen werden der FCP (First Contentful Paint), die TBT (Total Blocking Time) und ein SI (Speed Index) angezeigt. Der INP ergibt sich letztlich aus den anderen genannten Indikatoren.

Welche Pageperformance-Metriken sind wirklich rankingrelevant?

Wie bereits beschrieben, sind die dargestellten CWV rankingrelevant. Da jedoch die Metrik für den INP im Lighthousetest nicht explizit angezeigt wird, sollten wir uns genauer anschauen, wie sich dieser zusammensetzt und wie er optimiert werden kann.

Google stellt uns mit dem Pie-Chart der einzelnen Gewichtungen ein schönes Tool zur Verfügung, um das Scoring und vor allem die Zusammensetzung besser analysieren zu können. Mit einem Mouseover über das Pie-Chart des Performance Scoring können wir nun auch dessen Zusammensetzung analysieren und sehen, welche Metrik hier ausschlaggebend für das Scoring ist beziehungsweise welche bei der Optimierung dringend berücksichtigt werden sollte.

Screenshot des Lighthouse-Test für das Performance Scoring.

So kannst Du die Scoring für die Ladezeiten berechnen lassen

Vor allem der Rechner den Google direkt beim Scoring verlinkt, ist eine gute Hilfe, um Dir ein Bild von den notwendigen Maßnahmen zu machen und eine entsprechende Priorisierung vorzunehmen.

Im Lighthouse Scoring Calculator kannst Du per Regler die einzelnen Metriken bewegen und so sehen, wie Du den Score Deiner Website verbesserst.

Spielerisch kannst Du hier die einzelnen Metriken per Schieberegler bewegen und so direkt sehen, wie sich der vermeintliche Score verbessert oder verschlechtert. Das gibt Dir direkt einen guten Indikator, welche Metrik Du verbessern solltest. Auffällig ist hier auch, dass sich der Score deutlich schneller verbessert, wenn Du den Regler im Millisekundenbereich bewegst. Das heißt, wenn Du die TBT von 4 auf 3 Sekunden optimierst, gewinnst Du weniger, als wenn Du sie von 1000 auf 400 Millisekunden optimierst. Das sagt uns eigentlich schon, dass bei der „Standardperformance“ die entsprechenden Werte schon im Millisekundenbereich liegen sollten. Wenn Du von 6 Sekunden auf 5 Sekunden optimierst (z. B. beim TBT oder LCP), dann fühlt sich die UX immer noch schlecht an und es ist nicht viel gewonnen. Du solltest also darauf achten, wie viel Zeit Du mit welcher Maßnahme gewinnst.

TBT – Die Total Blocking Time

Eine der aus meiner Sicht wichtigsten Metriken ist die bereits angesprochene TBT (Total Blocking Time). Diese steigt immer dann an, wenn eine Nutzeraktion aufgrund von Renderprozessen nicht ausgeführt werden kann oder verhindert wird. Dies trübt das Nutzungserlebnis, da der User entsprechend lange warten muss, bis er mit der Seite interagieren kann. Da Nutzende, wie auch ich, eher ungeduldig sind, solltest Du den Aufwand für den Main-Thread, also das Rendern der notwendigen Prozesse und Scripte, genau unter die Lupe nehmen und die Optimierung auf das notwendige Maß begrenzen.

Hier ist der Main-Thread von Google im Detail:

Screenshot eines Beispiels Main Thread Work, Google zeigt hier die einzelnen relevanten Prozesse auf

Kurz erläutert:

Der Ablauf des Main Thread lässt sich vereinfacht so erklären: Beim Seitenaufbau muss der Browser (Client)

• alle Ressourcen laden, prüfen bzw. evaluieren.
• alle Styles hinzufügen, die nachträglich das HTML ändern.
• das HTML und CSS parsen.
• alles kompilieren und parsen.
• und zuletzt die Speichernutzung bereinigen.

Die „Wartezeit“ bis zur Fertigstellung des Renderns ist daher für viele Faktoren immer entscheidend und sollte daher so kurz wie möglich gehalten werden.

Wichtig: Optimiere die Javascript-Nutzung

Häufig werden für den Aufbau eines Website-Dokuments sehr viele Scripte und Prozesse geladen, die für die Funktion der Website eigentlich nicht notwendig sind und die Du durch eine entsprechende Priorisierung beim Rendern optimieren kannst. Gerade das Laden großer JavaScript-Bibliotheken wie Reacts.js, vue.js, jquery.js, die viele MB groß sein können, obwohl Du vielleicht nur eine Funktion benötigst, macht den Code zu 99,9 Prozent unnötig und Du verschwendest Ladezeit. Wie Robin in seinem Artikel zur TBT bereits ausführlich aufgezeigt hat, solltest Du Dir also alle der folgenden Prozesse genauer anschauen:

• Die Auswirkungen von Drittanbieter-Code auf die Ladezeit analysieren und optimieren.
• Die Ausführzeit von JavaScripts optimieren.
• Die Aufgaben im Main Thread verringern.
• Die Anfragen nach Dateien in der Anzahl und Größe verringern.

Häufig ist der Aufwand für den Main Thread am größten. Heißt also, dass Du genau hier schauen solltest, wie Du Messwerte wie INP oder FID wirklich reduzieren kannst. Da JavaScript mittlerweile von kaum einer Seite wegzudenken ist – ermöglicht es doch all die dynamischen Prozesse und funky Visualisierungen auf der Page – solltest Du Dich als Entwickler und SEO-Experte immer fragen: „Ist es wirklich notwendig?“ Musst Du also eine ganze JavaScript-Bibliothek laden und prozessieren, wenn Du nur fünf Prozent des Codes nutzt? Hier kann Code Splitting Abhilfe schaffen, also ausschließlich den für die Darstellung notwendigen Code laden und prozessieren. So lassen sich zum Beispiel Requests für Ressourcen verringern oder gänzlich einsparen, das Ladevolumen verringern beziehungsweise das Parsen und Ausführen verkürzen.

Zudem sollte Code, der nicht für die konkrete Darstellung oder Interaktion benötigt wird, depriorisiert, also nach allen wichtigen Elementen wie Scripts, CSS, etc., die für die initiale Darstellung und Interaktion wichtiger sind, geladen und verarbeitet werden. Wie das Laden von Ressourcen depriorisieren kann, erkläre ich Dir im weiteren Verlauf dieses Beitrags.

Um hier weitere Informationen zu gewinnen, setze Dich dafür mit den Entwicklern zusammen und besprich die Problematik. Meisten kennen die Entwickler hier schon direkt die Antworten auf Deine Fragen.

Und was ist nun mit der TTFB-Metrik (Time To First Byte)?

Die Relevanz des TTFB solltest Du nicht unterschätzen, ist sie doch ein sehr gutes Kriterium, um zu bestimmen, ob die Daten schnell genug bereitgestellt werden können. Bei großen Websites (mit Hunderttausenden und Millionen von URLs) ist die Relevanz sicherlich höher, dieser Wert wird auch von Google zur „Crawling-Aussteuerung“ herangezogen. Bereits 2015 hat John Muller (Google) darauf hingewiesen, dass Ladezeiten beziehungsweise Antwortzeiten von über zwei Sekunden zu einer Drosselung des Crawlings führen können. Wenn wir jetzt sehen, dass die Reaktionszeit einer Website, also der TTFB, eine Sekunde oder mehr beträgt, kann man sich direkt schon ausmalen, dass die Marke von drei Sekunden für die Ladezeit schnell überschritten wird. Dies ist besonders ärgerlich, wenn täglich viele Dokumente aufgrund von Aktualisierungen (Indexierung, Deindexierung, Änderung der Inhalte) gecrawlt werden müssen. Große Newspublisher wie spiegel.de, focus.de oder vor allem auch Plattformen wie ebay.de, kleinanzeigen.de oder autoscout24.de stehen vor genau solchen Herausforderungen.

Nutze ein Chaching

Aber auch für kleinere Websites, Plattformen oder Shops ist dieser Wert ein guter Indikator, ob die Infrastruktur (Server, Hardware, etc.) performant aufgestellt ist. Eine gute Abhilfe kann zum Beispiel die Verwendung eines HTML-Cache sein. Dabei werden alle Dokumente „vorgerendert“ und im RAM des Servers abgelegt, sodass bei einem Request die Seite aus dem Cache abgerufen werden kann und nicht erst komplett neu gerendert werden muss, inklusive Datenbankabfragen und Co.

Wie definiere ich (m)ein Pageperformance-Benchmark?

Häufig fällt in der Entwicklung und gerade bei Relaunches auf, dass sich Entwickler, Geschäftsführer oder Manager und gerne auch mal wir SEOs auf Metriken bzw. Scorings versteifen, was eigentlich nicht notwendig ist. Hier ist es wichtig einen aussagekräftigen Benchmark zu etablieren und sich an diesem zu messen. Dieser sollte sich dann am entsprechenden Marktsegment orientieren. Beispielsweise am direkten und indirekten Wettbewerb. Müssen dann unbedingt die 100 Punkte für die Performance im Lighthousetest angestrebt werden, um besser als der Rest des Marktumfeldes zu sein?  In den meisten Fällen eher weniger! Vor allem ist es aufgrund verschiedenster Faktoren, gerade bei großen Plattformen, kaum möglich die 100 Punkte zu erreichen. Das dies zwar machbar ist, wurden schon oft genug bewiesen, aber praktikabel ist das wie gesagt eher weniger, geschweige denn sinnvoll. Wer möchte schon seine gesamte Infrastruktur inkl. Daten, Businessmodellen etc. an Google und dessen Infrastruktur auslagern? (= maximale Abhängigkeit)

Entwickle Deinen Benchmark und berücksichtige technische Hürden

Nehmen wir einmal an, Du betreibst einen Onlineshop. Du hast ein Produktsortiment von ca. 70.000 – 100.000 Produkten, d.h. Daten dynamisch abzubilden könnte schon mal aufgrund des Data Fetching, also das aggregieren aller Daten für die Darstellung und dem Rendern des Frontends benötigt werden, schon etwas zeitintensiver sein. Zudem gibt es hier im Markt so einige große Player mit entsprechenden technischen Ressourcen, mit denen man somit im direkten Wettbewerb steht. Also wird die Pageperformance ein entscheidender Faktor sein. Nicht selten kann gerade für hart umkämpfte Suchterme die Performance das Zünglein an der Waage spielen.

Definiere daher konkret Deinen Wettbewerb: Das kannst Du mit den beliebten SEO- und Marketing-Tools, wie Sistrix, SEMrush, Similarweb, etc. machen. Du solltest aber auch manuell abfragen machen. Eben so, als wenn Du eine Wettbewerbsanalyse vorbereiten möchtest. Setze den Fokus aber nicht nur auf ein paar direkte Wettbewerber, sondern erweitere Deinen Fokus, damit Du ein aussagekräftiges Bild bzw. einen aussagekräftigen Benchmark schaffst. Berücksichtige aber ebenfalls, was Du für ein System nutzt und wie dieses aufgebaut ist. Nehmen wir hier mal als klassisches Beispiel shopify, dann wissen wir zwei Dinge. Wir sind mit der Infrastruktur abhängig von Shopify, da dies mehr oder weniger ein closed System ist, wir also gerade auf Server, Backendcode, etc. keinen direkten Zugriff haben können. (Ja ja ich weiß, eingesetzt im Headless Ansatz, haben wir auch hier weitere Möglichkeiten, aber bleiben wir mal beim allg. üblichen Einsatz und nutzen auch das Shopify-Frontend). Zudem wird sich mit jeder Anbindung von Drittanbeiter-Apps die Ladezeit etwas verschlechtern, da Ressourcen von weiteren externen Quellen eingebunden werden müssen. Somit muss man sich hier wohl oder übel damit anfreunden keine 80, 90 oder gar 100 Punkte zu erreichen. Aber das ist vll. auch gar nicht nötig.

Erstes Fazit: Schaue auf die richtigen Metriken

Ich habe Dir nun einige wichtige Metriken aufgezeigt und eine Möglichkeit vorgestellt, wie Du ein gutes Scoring für die Page Performance bestimmen kannst. Vor allem aber habe ich Dir auch eine Lösung präsentiert, wie Du Dich auf die richtigen Metriken fokussierst. Im zweiten Teil meines Blogbeitrags krempeln wir die Ärmel hoch und schauen uns an, wie Du bei der Optimierung vorgehen kannst.

Bildnachweis: Titelbild: TarikVision/stock.adobe.com; Bild 2: Seokratie GmbH: Screenshot Google for Developers; Bild 3 – 7: Seokratie GmbH: Screenshots Google Lighthouse-Test; Bild 8: Seokratie GmbH: Screenshot Main Threat Work, Google Developer