Eine Schritt-für-Schritt-Anleitung zur Webgeschwindigkeitsmessung für Marketer

Die Messung der Webgeschwindigkeit ist eine durchaus knifflige Angelegenheit, die zudem recht häufigen Änderungen unterliegt, wie das jüngst eingeführte Google-Bewertungssystem namens Page Experience zeigt.

Menschen, die sich nicht voll und ganz mit dem Thema „Webperformance“ beschäftigen – wie Marketer, Manager oder Designer – tappen häufig in die Falle, ungeeignete Tools in den falschen Phasen der Messung zu verwenden.

Am 7. April hatte ich die Gelegenheit, auf der Konferenz SEO Restart darüber zu sprechen. Im folgenden Text gebe ich Ihnen die wesentliche Idee weiter – einen möglichst einfachen Weg, um Geschwindigkeitsdaten zu erhalten, und wie man diese den Entwicklern weitergibt.

Ich werde hier Screenshots von unserem Geschwindigkeitstester Version 3.0 zeigen, den wir kürzlich um Benutzerkonten und die Möglichkeit erweitert haben, mehrere Websites von Kunden gemeinsam mit Kollegen im Dashboard zu überwachen.

Als Beispielwebsite habe ich die Domain Mall.cz gewählt, die zwar nicht zu unseren Kunden gehört, aber aufgrund ihrer Größe und Vielfalt an Seitentypen interessant ist. Einen öffentlichen Geschwindigkeitstest von Mall finden Sie unter pagespeed.one/app/r/73f8e7b84404.

Der Kreislauf der Arbeit an der Webgeschwindigkeit#

Wir müssen mit einem recht umfassenden Blick auf den allgemeinen Prozess der Arbeit an der Geschwindigkeit beginnen.

Google definiert den Prozess in seinen Materialien als dreistufigen. Zuerst sammeln wir Daten, dann optimieren wir, und schließlich überwachen wir, da nach einigen Wochen der Optimierungen in der Regel wieder etwas schiefgeht.

Ich erlaube mir, diesen Prozess auf zwei Schritte zu vereinfachen:

1. Optimierung (in der Regel von Entwicklern durchgeführt).
2. Daten und Monitoring (auch als Datenerfassung über die Zeit bekannt – kann von Entwicklern gelöst werden, wird aber in der Regel von jemandem mit analytischem Blick übernommen, der das Projekt eher nicht-technisch und „von oben“ sieht).

Im Rahmen der Dienstleistungen des PageSpeed.ONE-Teams arbeiten wir an der Schnittstelle beider Bereiche – wir überwachen die Daten und liefern gleichzeitig den Entwicklern konkrete Optimierungsmöglichkeiten.

Google Page Experience und Seiten, Gruppen, Domains#

Zur Auffrischung für die Unkundigen: Die Geschwindigkeit einer Website wird anhand der Metriken Core Web Vitals im Rahmen der Bewertungsfaktoren bewertet, die von Google als Page Experience bezeichnet werden.

Es handelt sich um Daten aus dem Chrome UX Report (CrUX), also von tatsächlichen Nutzern Ihrer Website, nicht um Daten aus Tools wie Lighthouse oder PageSpeed Insights.

Die Nutzerdaten, die Sie benötigen, sehen Sie beispielsweise in der Google Search Console:

Für den im Artikel erwähnten Prozess ist es entscheidend, dass wir wissen, dass es drei Stufen der Bewertung von Web Vitals gibt:

• Konkrete URL – die meistbesuchten Adressen haben eine eigene Bewertung.
• Seitengruppe – wenn eine URL keine eigenen Core Web Vitals-Daten hat, verwendet Google zur Bewertung eine Gruppe. Bei einem Online-Shop könnte dies beispielsweise eine Gruppe mit Produktdetails sein.
• Domain – wenn die URL keine eigene Bewertung hat und nicht zu einer Gruppe gehört, verwendet Google für ihre Bewertung die Daten für die gesamte Domain.

In allen Fällen berücksichtigt Google den 75. Perzentil der Werte der Core Web Vitals-Metriken aller Besuche der letzten 28 Tage kumulativ. Dies sind die Daten, die Sie in allen Tools sehen, die CrUX als Datenquelle nutzen, also auch in unserem Tester auf pagespeed.one.

Ursprünglich dachte ich, dass fast jede URL zumindest in einer Seitengruppe eingeordnet ist, aber die Realität sieht wohl anders aus.

Bei unseren Kunden sehe ich, dass die Bewertung für URLs immer maximal nur einige Dutzend Adressen umfasst, bei weniger besuchten Websites eher Einzeladressen. Die Bewertung für eine Gruppe, die nur in der Search Console sichtbar ist, hat bei unseren Kunden in etwa nur die Hälfte der URLs.

Es gibt auch Extreme, große Websites wie Livesport.cz, bei denen bis zu 90 % der URLs die Domainbewertung übernehmen können. Das schließe ich aus dem Unterschied zwischen der Gesamtheit der URLs, die Google kennt, und der Anzahl der URLs, die in Seitengruppen in den Web Vitals-Berichten der Google Search Console eingeordnet sind.

Erster Schritt: Domainmessung#

Bei der Geschwindigkeitsmessung beginnen wir immer mit einem Blick auf die Daten für die gesamte Domain. Es ist der einfachste (wenn auch leicht vereinfachte) Ausdruck des Geschwindigkeitszustands der Website.

Sie können sich natürlich die PageSpeed Insights ansehen, wo Sie den Web Vitals-Status für die Domain sehen werden:

Bereits aus diesen Zahlen und Grafiken sehen wir die Metrik, die am meisten optimiert werden muss. Bei mall.cz handelt es sich um CLS (Cumulative Layout Shift).

PageSpeed Insights zeigt die korrekten Daten, also die Werte der Metriken für Nutzer kumulativ für einen Monat aus dem Chrome UX Report. Das Problem ist jedoch, dass wir hier die Entwicklung im Vergleich zum vorherigen Zeitraum nicht sehen und dass wir hier nicht mehrere Domains gleichzeitig sehen können.

Deshalb haben wir in unserem Tester ein Dashboard entwickelt, in dem Sie nach der Anmeldung beispielsweise die Zahlen aller Websites Ihrer Kunden überwachen können:

Auf dem Bild oben sehen Sie, dass die Domain mall.cz auf Mobilgeräten nicht nur die CLS nicht erfüllt (der Wert beträgt 0,13), sondern sich auch im letzten Monat verschlechtert hat.

Wir wissen also, was falsch ist, und wenn wir die Zahlen regelmäßig überwachen, erfahren wir auch, ob sie sich in letzter Zeit geändert haben. Was aber, wenn wir nur alle paar Monate zur Geschwindigkeitsmessung kommen?

Hier kann uns eine weitere Funktion unseres Testers nützlich sein – die monatlichen Daten aus dem Chrome UX Report:

Google stellt diese Zahlen mit Verzögerung zur Verfügung, und sie haben etwas andere Werte als die Daten der letzten 28 Tage, nach denen die Seiten bewertet werden. Aber sie sind großartig, weil sie die Entwicklung der Geschwindigkeit und somit den Einfluss von Optimierungen oder, nun ja, weniger optimaler Entwicklungen zeigen.

Im obigen Diagramm ist zu sehen, dass mall.cz vor einem Jahr sehr schlechte Werte für die Metriken LCP und CLS hatte, aber der Zustand ist jetzt deutlich besser. Der „grüne“ CLS-Wert im März bestätigt, dass diese Metrik auf Mobilgeräten für die gesamte Domain mall.cz bis vor kurzem in Ordnung war.

Wahrscheinlich ist also mit dem Cumulative Layout Shift auf Mobilgeräten erst im letzten Monat etwas Unschönes passiert.

Mit diesem Wissen über den Zustand der Metriken für die Domain könnten wir zufrieden sein, aber ich empfehle Ihnen noch einen weiteren Blick in die unverzichtbare Google Search Console.

Die Search Console zeigt im Abschnitt Page Experience ein Diagramm mit der Anzahl der URLs, die die Bewertungssignale dieses Bereichs erfüllen. Also neben der Geschwindigkeit auch die Nutzbarkeit auf Mobilgeräten oder das Sicherheitsniveau, was dieses kürzlich in der SEO-Community gehypte HTTPS ist.

Im Fall des obigen Diagramms kam es bei einem Kunden zu einer Verbesserung dank unserer Optimierungen, und die Werte sprangen innerhalb eines Tages von null auf hundert Prozent. Sie müssten jedoch Glück haben, um ein solches Diagramm zu sehen. Meistens ist es weit „zackiger“, die Werte ändern sich im Laufe der Zeit stark.

Dieses Diagramm unterliegt zudem starken Verzerrungen – sowohl in Bezug auf die Datenverzögerung als auch in Bezug auf verschiedene Bugs auf Googles Seite. Deshalb nehmen wir hauptsächlich die langfristige Entwicklung daraus und geraten nicht in Panik bei täglichen Schwankungen.

Wiederholen wir, was wir wissen: Die Domain mall.cz hat auf Mobilgeräten und Desktops einen schlechten Wert für die Metrik CLS. Auf Mobilgeräten hat sich dieser Wert im letzten Monat zudem erheblich verschlechtert.

Zweiter Schritt: Seitengruppen#

In dieser Messphase kommen wir praktisch nicht ohne die Search Console aus. Google stellt diese Daten nicht über seine API zur Verfügung. Ich hoffe, das gilt nur vorübergehend, und bald wird es möglich sein, vernünftig auch von außen damit zu arbeiten.

Jedenfalls ist das, was ich Ihnen jetzt zeige, im Abschnitt Web Vitals sichtbar. Dort sind Berichte für Mobilgeräte und Desktops verfügbar. Und alle beziehen sich auf die Seitengruppen, so wie Google sie intern aufgeteilt hat.

Im ersten Schritt sehen wir ein etwas verwirrendes Diagramm mit gelben, orangefarbenen und grünen Linien:

Das Problem bei diesem Diagramm ist, dass es nicht die Entwicklung der Webgeschwindigkeit zeigt, sondern nur die Anzahl der URLs in den Gruppen, die alle Metriken erfüllen (grün) oder mindestens eine orangefarbene oder mindestens eine rote haben.

Da es sich um die Anzahl der URLs handelt, können die Diagramme so aussehen, als würden sie sich verschlechtern, auch wenn beispielsweise mehr Adressen hinzukommen, die in einer Gruppe von URLs eingeordnet sind. Tatsächlich verschlechtert sich jedoch nichts, es steigt nur die Anzahl der Seiten.

Schlecht ist es jedoch, wenn es hier in einem Moment weniger Grün und mehr Orange oder Rot gibt. Das könnte ein Grund für Ihre Besorgnis über die Geschwindigkeit sein.

Natürlich gilt auch für diese Diagramme, dass es hier verschiedene Verzerrungen, Verzögerungen und wer weiß was noch gibt… Es ist einfach gut, noch andere regelmäßige Messungen zu haben, die Ihnen bestätigen, ob es wirklich zu einer sprunghaften Änderung gekommen ist.

Wenn Sie das Diagramm anklicken, sehen Sie bereits eine Aufschlüsselung für bestimmte Geräte und bestimmte Metriken:

Dieses Diagramm zeigt uns, welche Metriken auf der Domain in den Gruppen problematisch sind und wie viele URLs davon betroffen sind.

Im Fall dieses speziellen Diagramms ist es die Metrik LCP und die orangefarbenen Werte (2,5 – 4 s). Wenn wir Zugriff auf die Search Console von Mall.cz hätten, würden wir hier wahrscheinlich Probleme hauptsächlich mit CLS sehen.

Auch diesen Bericht können Sie weiter aufklicken, bis Sie auf das Kernproblem stoßen, nämlich die Liste der URL-Gruppen, die diesen Metrikwert haben:

Im obigen Bild habe ich die konkreten URL-Adressen ausgeblendet, aber Sie können sie sich sicher vorstellen.

Dies ist ein ausgezeichneter Bericht, da er uns neben den Seitengruppen auch deren Häufigkeit und den „aggregierten Metrikwert“ verrät. Je häufiger die Gruppe vertreten ist und je schlechter ihr Metrikwert ist, desto wichtiger ist ihre Optimierung.

Google Search Console gibt hier auch viele Beispiele für URLs an, sodass wir sie direkt nehmen und im Browser testen oder in ein regelmäßiges Monitoring einstellen können, was wir im nächsten Schritt tun werden.

Im zweiten Schritt haben wir also herausgefunden, welche Seitengruppen den größten Einfluss auf die schlechte Metrik haben (im Fall von Mall.cz wäre dies CLS), und daher ist ihre Optimierung prioritär.

Dritter Schritt: Konkrete URLs#

Die Auswahl der richtigen URLs, die Sie überwachen, ist entscheidend für den Erfolg der gesamten Geschwindigkeitsmessung. Ich habe ein paar Tipps für Sie:

• Finden Sie typische Seiten, die für Sie entscheidend sind und wichtigen Inhalt repräsentieren. Auf einem Online-Shop könnte dies die Startseite, Produktdetailseite, Kategorie, Blogbeitrag und vielleicht die Kontaktseite sein.
• Wählen Sie Vertreter aus häufigen Gruppen von Adressen, die Ihnen die Search Console bietet.
• Wählen Sie URLs aus, die innerhalb dieser Gruppe den höchsten Traffic haben.
• Wählen Sie idealerweise Seiten mit einer eigenen Web Vitals-Bewertung in CrUX.

Unser Tester ermöglicht das Einfügen von bis zu fünf URLs, was auch für größere Websites ausreichen sollte. Im Fall von Mall.cz wird es natürlich ein wenig aus der Hüfte geschossen sein (wir haben nämlich nicht alle Daten), aber wir haben diese Seiten ausgewählt:

Im Bild des Tests sehen wir, dass das problematische CLS insbesondere in der Kategorie (/mobilni-telefony) und dann auf der Seite /akce ist. Ein schlechter Wert ist auch auf der Startseite zu sehen, aber diese ist nur eine, sodass sie nicht so viel Einfluss auf die Domainbewertung haben wird. Wir müssen sie zwar optimieren, aber nicht prioritär.

Regelmäßiges Monitoring#

Wenn wir die Adressen im Tester so eingegeben haben, werden sie regelmäßig gemessen, in unserem Fall einmal täglich. Es ist ein kostenloser Service, den wir anbieten, also zögern Sie nicht, ihn zu nutzen.

Das Diagramm des täglichen Monitorings sieht ungefähr so aus:

Im Diagramm ist zu sehen, dass sich bei einem Kunden auf einer der Seiten die Metrik LCP verschlechtert hat. Dies geschah Anfang Februar, und wir können so leichter der Ursache auf den Grund gehen. (In diesem Fall zickt die Cookie-Leiste herum.)

So überwachen wir jetzt zusätzlich zur langfristigen Sicht auf Domains und Seitengruppen täglich konkrete URLs. Wir können so problematische Metriken, aber auch das Datum ihrer sprunghaften Verschlechterung und damit die wahrscheinliche Ursache ermitteln.

Ergebnis der Webmessung#

Wir haben jetzt die Domain, die Seitengruppen und auch konkrete URLs gemessen. Sie können den Entwicklern also für die Optimierung diesen sehr kurzen Bericht liefern:

Auf der Domain mall.cz ist die Metrik CLS problematisch:
In CrUX sind die Werte für Mobil 0,13, für Desktop 0,26.

Die wichtigsten Gruppen zur Optimierung und Beispiele in URL sind diese:
…

Links zur Messung:
Search Console: …
PageSpeed.ONE: …
PageSpeed Insight: …

Ja, so einfach könnte es sein.

Jetzt bleibt nur noch zu überlegen, wie man das behebt, nicht wahr…

Sollten sich Marketer bemühen, Entwicklern Empfehlungen zu geben?#

Ich denke, dass die meisten Marketer die Daten und deren Interpretation gut verstehen, aber nicht so tiefe Kenntnisse über die Funktionsweise von Browsern oder verschiedenen Frontend-Technologien haben.

Es gibt zwar allgemeine Ratschläge, die zum Beispiel von Lighthouse oder auch PageSpeed Insights gegeben werden, aber sie können nur bei einigen Websites gut funktionieren, in der Regel bei nicht gut optimierten.

Es ist wichtig zu erkennen, dass Lighthouse den menschlichen und technologischen Kontext Ihres Projekts nicht kennt, sodass bestimmte Ratschläge völlig danebenliegen können.

Aus unserer Erfahrung gilt auch, dass die Ratschläge von Lighthouse sehr aufwändig in der Implementierung sind. Das Ziel der Optimierung sollte es sein, nach „niedrig hängenden Früchten“ zu suchen, also Anpassungen, die mit wenig Aufwand den größten Effekt erzielen.

Solche Anpassungen sollten die Entwickler, die an dem Projekt arbeiten, finden können. Immer häufiger zeigt sich jedoch bei unseren Kunden, dass sich die Fähigkeit einer qualitativ hochwertigen und effizienten Entwicklung und die Fähigkeit zur Geschwindigkeitsoptimierung fast ausschließen.

Natürlich können Sie Glück haben, und Ihre Entwickler kümmern sich ganz von allein um die Performance (wir kennen solche!) oder Sie können noch mehr Glück haben, und diese Kenntnisse hat Ihr Marketer, Designer oder Produktmanager (auch solche kennen wir).

Andernfalls können Sie sich einfach bei uns melden, wir helfen Ihnen gerne. ;)

Tags:SEOMeasurement