Bericht „Technische“

Der Bericht „Technische“ überwacht nicht die Benutzer-Metriken, sondern technische Indikatoren wie Datenvolumen oder die Anzahl der Anfragen.

Wir nehmen alle URLs, die Sie über die Testeinstellungen eingeben, und ermitteln täglich den Median der Tests, um Ihnen diese Daten anzuzeigen.

Ein gelegentlicher Ausschlag ist nicht schlimm, aber wenn es schlechter wird und nicht mehr zurückkehrt, sollte man innehalten und nachdenken.

Technische Indikatoren betrachten wir nicht als Hauptmetriken, sie sollen Ihnen jedoch helfen, die Ursachen von Problemen mit Benutzer-Metriken Core Web Vitals zu finden, die Ihnen von der Wächter gemeldet werden oder die in Googles Daten (Chrome UX Report) im Bericht Domains oder Seiten sichtbar sind.

🔐 Der Bericht „Technische“ ist nur in den PLUS Tests verfügbar.

Warum ist es sinnvoll, technische Indikatoren bei der Webgeschwindigkeit zu messen?#

Das moderne Fachgebiet der Webgeschwindigkeitsoptimierung überwacht diese technischen Indikatoren nicht mehr als primäre Metriken.

Aus der Praxis unserer Webgeschwindigkeitsberatung wissen wir sehr gut, dass auch Websites, die große Datenmengen herunterladen, dank einer guten Optimierung der ersten Ansichten letztlich für den Nutzer schnell sein können.

Dennoch verfolgen wir in unserem „Technische“ genau diese sekundären Indikatoren. Datenvolumen, Anzahl der Anfragen und andere Metriken sind aus folgenden Gründen wertvoll:

• Sie eignen sich zur Ermittlung von Zusammenhängen zwischen Änderungen der Benutzer-Metriken (z.B. LCP, CLS, INP) und Änderungen bei der Webentwicklung (z.B. Datenvolumen von Bildern oder Größe blockierender JavaScripts).
• Datenvolumen zu sparen betrachten wir als Höflichkeit gegenüber den Nutzern, die möglicherweise eingeschränkte Datenressourcen auf Mobilgeräten haben.
• Oft gilt, je weniger Daten übertragen werden, desto mehr spart der Website-Betreiber an Infrastrukturkosten.

In den PLUS Tests sehen Sie den Bericht „Technische“ für alle typischen Seiten, die Sie in die Testeinstellungen eingeben.

Aus dem unten stehenden Diagramm geht hervor, dass wir sowohl den aktuellen Stand der Metriken als auch deren Entwicklung im Laufe der Zeit anzeigen. Besonders für Mobilgeräte und Desktops.

Basierend auf unserer Beratungserfahrung haben wir diese Informationen und Berichte in den Bericht „Technische“ aufgenommen:

Datenvolumen HTML#

Das Diagramm zeigt die Entwicklung des Datenvolumens von HTML für einzelne Seiten. Es handelt sich um den Zustand, in dem das HTML in den Testbrowser gelangt, also beispielsweise bereits nach der Kompression mit Gzip oder Brotli. Je kleiner das Datenvolumen des HTML, desto besser.

Wir empfehlen eine Größe von bis zu 20 kB. Dies beeinflusst Metriken zum Laden wie FCP oder LCP.

Anzahl der DOM-Knoten#

Entwicklung der Anzahl der DOM-Knoten für einzelne Seiten im Laufe der Zeit. Ein komplexer DOM-Baum erschwert die Arbeit von JavaScript und kann somit Metriken wie TBT oder INP beeinflussen.

Wir empfehlen als Maximum 1.500 DOM-Knoten pro Seite, was manchmal ein ehrgeiziges Ziel ist, aber es ist wichtig, es anzustreben.

Datenvolumen CSS#

Entwicklung des Datenvolumens von CSS-Dateien für einzelne Seiten im Laufe der Zeit. Es handelt sich um den Zustand nach einer möglichen Kompression mit Gzip oder Brotli auf Ihrem Server. CSS ist in der Regel eine Ressource, die das erste Rendering blockiert, und seine Größe beeinflusst daher Metriken wie FCP oder LCP. Idealerweise sollte das Datenvolumen von CSS unter 50 kB liegen.

Anzahl blockierender JS#

Entwicklung der Anzahl der JS-Dateien, die das erste Rendering blockieren. JavaScript muss nicht blockierend sein, im Gegensatz zu CSS.

Je weniger blockierende JS Sie haben, desto besser für Metriken wie FCP oder LCP.

Datenvolumen JS#

Entwicklung des Datenvolumens von JS-Dateien für einzelne Seiten im Laufe der Zeit. Hier sind sowohl Dateien aufgeführt, die das erste Rendering blockieren, als auch solche, die nicht blockieren. Im Diagramm sehen Sie den Zustand nach einer möglichen Kompression mit Gzip oder Brotli auf Ihrem Server.

Je kleiner das JS, desto weniger Code muss vom Browser verarbeitet und ausgeführt werden. Dies hat Auswirkungen auf Interaktionsmetriken wie TBT oder INP. Blockierendes JS beeinflusst zudem FCP und LCP, also das erste Rendering.

Datenvolumen JS von Drittanbietern#

Entwicklung des Datenvolumens von JavaScript-Dateien von Drittanbietern für einzelne Seiten im Laufe der Zeit. In diese Kategorie fällt JS, das außerhalb Ihrer Hauptdomain ausgeführt wird, sodass es sein kann, dass Sie hier auch Ihre eigenen Dateien sehen, die außerhalb der Hauptdomain platziert sind.

In der Regel finden Sie hier das Datenvolumen von fremdem Code für Komponenten wie Analysetools, Chats, A/B-Tests, Werbung usw.

Auch dieser Code hat Einfluss auf Interaktionsmetriken wie TBT oder INP. Es ist daher wichtig, ihn so klein wie möglich zu halten.

Datenvolumen der Schriftarten#

Entwicklung des Datenvolumens der Schriftarten für einzelne Seiten im Laufe der Zeit. Schriftarten sind in der Regel eine Ressource, die zum Rendering des Inhalts benötigt wird und somit die Metrik LCP beeinflusst.

Wir empfehlen, ihr Datenvolumen unter 50 kB zu halten.

Datenvolumen der Bilder#

Entwicklung des Datenvolumens der Bilder für einzelne Seiten im Laufe der Zeit. Bilder sind oft eine Ressource, die zum Rendering des Inhalts benötigt wird und somit die Metrik LCP beeinflussen kann.

Wir empfehlen, ihr Datenvolumen für jede Seite unter 100 kB zu halten.

Gesamtes Datenvolumen#

Entwicklung des Datenvolumens aller heruntergeladenen Dateien für einzelne Seiten im Laufe der Zeit. Das gesamte Datenvolumen muss nicht unbedingt Einfluss auf die Metriken und die Benutzererfahrung haben, dennoch empfehlen wir, es für jede Seite unter 0,5 MB zu halten.

Die Überwachung technischer Indikatoren kann sehr hilfreich sein, wenn Sie sich entscheiden, sich auf eine der oben genannten Metriken und eine der spezifischen typischen Seiten zu konzentrieren.

Was tun, wenn Sie eine Verschlechterung eines technischen Indikators feststellen?#

Zunächst einmal sei gesagt, dass es nicht immer ein größeres Problem darstellen muss. Stellen Sie also sicher, dass Sie im gleichen Zeitraum Auswirkungen auf die Benutzer-Metriken sehen (siehe Berichte Wächter, Seiten oder Domains).

Manchmal haben Sie keine Möglichkeit, die Verschlechterung zu beeinflussen, z.B. bei Komponenten von Drittanbietern. Dennoch lohnt es sich, den Drittanbietern Aufmerksamkeit zu schenken.

Verbesserungen bei den technischen Indikatoren sind immer eine gute Nachricht.

Im Detail des Testruns Lighthouse können Sie dann einen noch breiteren Kontext sehen.

Sehen Sie dennoch im Bericht „Technische“ ein Problem auf Ihrer Seite und gleichzeitig eine Verschlechterung, die die Core Web Vitals betrifft, also z.B. eine Verschlechterung in den Berichten Wächter oder Domains?

1. Finden Sie die konkrete Änderung in den Diagrammen. Welche typischen Seiten betrifft sie? Ist sie sowohl für Mobilgeräte als auch für Desktops gleich?
2. Durch Klicken auf einen bestimmten Wert im Diagramm gelangen Sie zum Lighthouse-Test, der Ihnen die spezifische Messung des Wertes mit weiterem Kontext zeigt.
3. Fragen Sie Entwickler, Marketer und andere Teammitglieder, was sich im spezifischen Zeitraum geändert hat.

Eine vollständige Anleitung bietet unser Artikel Wie wir testen und Detail des Testruns mit dem Monitoring von PageSpeed.ONE.