So Viel Umsatz Kostet Dich Ladezeit Tatsächlich

So viel Umsatz kostet deine Ladezeit tatsächlich
9. Mai 2023

Wie die Geschwindigkeit deiner Webseite deinen Umsatz beeinflusst

Hast du dir schon mal Gedanken darum gemacht, ob und wie die Performance deiner Webseite dein alltägliches Geschäft beeinflusst?


Wenn deine Webseite zu langsam lädt, Bilder versetzt angezeigt werden und die Klick-Aktionen in der Ausführung zu lange brauchen, wirkt sich das auf die Benutzerfreundlichkeit aus. Im schlimmsten Fall bedeutet das, dass die Besucher deine Webseite verlassen oder ihren Kauf in deinem Shop abbrechen.


Dein Business kann also von einer schnellen Ladezeit deiner Webseiten-Ladezeit enorm profitieren. Anhand von 7 Case Studies veranschaulichen wir dir, wie Unternehmen wie Vodafone oder Tui ihren Umsatz mit einer einer richtig guten Performance noch stärker ausbauen konnten.

1. Warum solltest du die Geschwindigkeit deiner Webseite verbessern?

Im Kern gibt es vier fantastische Gründe, das Erlebnis für den Besucher einer Website so schnell wie möglich zu gestalten.


  1. Webseitenleistung spielt eine entscheidende Rolle für den Gesamterfolg eines Onlineunternehmens.
  2. Schnellere Seiten führen zu zufriedeneren Besuchern (BBC verliert 10 % Besucher je eine Sekunde Ladezeitverzögerung).
  3. Geschwindigkeit weckt Vertrauen in das Unternehmen.
  4. Schnellere Ladeprozesse führen in fast allen Fällen zu mehr Konversionen (Furniture Village reduziert Ladezeiten um 20 % und erhöht dadurch Konversionsrate um 10 %.).
  5. Höhere Geschwindigkeit korreliert direkt mit besseren Rankings bei Google. Speedwerte sind offizielle – von Google bestätigte – Rankingfaktoren (Pinterest reduziert Ladezeit um 40 % gewinnt 15 % mehr Suchmaschinentraffic).
  6. Langsame Ladezeiten führen laut Studien bei Besuchern zu mehr Stress und den gleichen Gefühlen wie beim Schauen eines Horrorfilms oder beim Lösen eines Matheproblems. Letzteres dürfte für viele schlimmer sein. 🙂
  7. Größere Webressourcen führen nicht nur zu langsameren Ladezeiten, sondern auch zu mehr Mobilkosten. Diese sind noch nicht überall so gut reguliert wie in der EU.
  8. Von unterwegs schnell noch etwas kaufen, ist heutzutage sehr gefragt. Die Mobilfunkabdeckung lässt jedoch immer noch viel zu Wüschen übrig. Schnelle Seiten haben hier einen großen Vorteil. Werte von unter 2,5 Sekunden sind schnell. Über die gesamte Webseite gesehen, sollten gute Werte bei mindestens 75 % aller Seiten erreicht werden.

Das Kundenerlebnis entscheidet darüber, ob ein Besucher etwas in den Warenkorb legt, den nächsten Kauf tätigt oder einfach nur schnell genug eine Anzeige zu sehen bekommt. Ladezeiten und die Geschwindigkeit bei der Anzeige und Bedienung einer Webseite haben einen entscheidenden Einfluss. Sicher sind das Layout, die Preisgestaltung und kulante Rückgabebedingungen wichtig. Allerdings können diese Faktoren ihre positive Wirkung weniger entfalten, sollte sich die Bedienung einer Seite anfühlen, wie ein Lauf durch den Sumpf in zu kurzen Gummistiefeln. Zu viel „Reibung“ lädt Besucher zum Absprung ein.


Wie wichtig ist PageSpeed wirklich?


Amazon hat schon 2006 festgestellt, dass jede 100 Millisekunden an Ladeverzögerung 1 % des Umsatzes kostet. Zur gleichen Zeit hat auch Google schon vermeldet, dass 0,5 Sekunden Verzögerung bei der Anzeige der Suchergebnisse, Traffic und Umsatz um 20 % einbrechen lasse.


Der Zusammenhang zwischen Traffic- und Umsatzeinbruch ist demnach nicht wirklich neu. Die damaligen Tests bezogen sich aber vor allem auf die Geschwindigkeit bei der Auslieferung von Inhalten. Verzögert wurde oft die TTFB (time to first byte). Obwohl die meisten Hoster mittlerweile akzeptable Auslieferungszeiten haben, gibt es dennoch Mitbewerber, die sich bei den günstigen Hostingtarifen 0,5 bis 1,0 Sekunden zusätzliche Verzögerungen leisten. Einen eigenen Performance-Test durchzuführen, kann sich lohnen.

Im Jahr 2021 hat Google unter dem Namen „Core Web Vitals“ (CWV) neue auf Performance basierende Rankingfaktoren eingeführt. Googles Argument dafür: Die Ladegeschwindigkeit einer Seite ist entscheidend für ein gutes Benutzererlebnis. Seiten mit positivem Benutzererlebnis erhalten bessere Rankings.

💡TIPP


Wer sich mit den technischen Details der Core Web Vitals noch nicht so gut auskennt, empfehlen wir den technischen Teil einmal gründlich durchzulesen, weil die Aussagen, Findings und Learnings in den Case-Studies dann deutlich besser zu verstehen sind.


2. Die 7 besten Case Studies für Webseiten Geschwindigkeit

Think with Google – Bouncerate verdoppelt sich bei Ladezeiten über 6 Sekunden

Case Studies über Google und Ladezeiten Verbesserung
Google ermittelte schon im Februar 2017, dass sich die Absprungrate mit Zunahme der Ladezeit rapide verschlechtert. Nach drei Sekunden ist bereits ein Drittel der Besucher weg. Danach werden die Zahlen drastisch schlechter. Erhoben wurden diese Werte bei 11 Mio. Landingpages von Mobilwerbeanzeigen in über 213 Ländern.


Interessant ist auch: steigt die Anzahl von zu ladenden Elementen (Text, Titel, Bilder) von 400 auf 6.000 fällt die „Konversionsrate“ (die Abschlussquote für das Ziel einer Webseite) um 95 %. Getestete Seiten waren aus den Branchen: Finanzen, Reise, Auto, Retail, Technologien.

II. Vodafone – 8 % mehr Sales nach Optimierung des LCPs um 31 %

Vodafone fand in Kollaboration mit Google heraus, dass eine Verbesserung der Ladezeit des „Largest Contentful Paints“ einer Landingpage zu 8 % mehr Sales führte. Stolze 11 % mehr Besucher besuchten den Warenkorb. Dabei verbesserte sich der Wert von 8,3 auf 5,7 Sekunden (-31 %).


Die Optimierungen im Detail:


  • Auslagerung von Renderlogik vom Client auf den Server / Kritisches HTML bereits Server-seitig bereitgestellt
  • Bilder verkleinert, insbesondere das Herobild und PNGs
  • Verwendung von SVG-Dateien
  • Lazy Loading von Bildern, die erst später geladen werden müssen
Vodafone steigert seine Ladezeiten um 8%

III. eBay – Jede 100 Millisekunden weniger Ladezeit steigern „Zum Warenkorb hinzufügen“ um 0,5 % (2019)

Als Unternehmen war eBay fest davon überzeugt, dass Performance der Schlüssel zu einer guten Customer-Experience ist. Alle durchgeführten Maßnahmen führten zu einer beachtlichen Verbesserung im zweistelligen Prozentbereich bei den beiden wichtigsten Seiten, der Homepage und der Suchseite.
Ebay steigert mit der Ladezeit der Webseite ein Einkäufe
Nur ein geringer Prozentsatz der Seiten hatten nach den Optimierungsarbeiten einen langsamen FCP. Rot und Orange sollten so niedrig wie möglich sein.


Maßnahmen im Detail


  •  Minifikation von CSS, JavaScript, HTML und JSON-Antworten.
  • Native Apps für iPhone und Android aktualisieren ihren Screen basierend auf Anfragen, die mit großen JSON-Objekten bedient werden. Die großen Objekte wurden in mehrere kleinere Objekte „zerlegt“. So kann die Client-App erst die wichtigen Daten auslesen und diese direkt anzeigen, bevor die restlichen Daten verarbeitet werden.
  • Auch die Backend-Services wurden so neu ausgerichtet, dass sie zuerst die Daten generieren, die „above the fold“ gebraucht werden. Daten für „später“ werden direkt danach parallel eingeholt.
  • eBay ist auf WebP als Bildformat umgestiegen, um die Ladezeiten bei Bildern zu reduzieren. Vormals war es für bestimmte Bilder auf der Startseite verschiedenen Parteien erlaubt, Bilder selbst hochzuladen. Das hat sich nicht verändert, jedoch erzwingt die Eingabemaske jetzt, dass diese Parteien maximale Komprimierung anwenden.
  • eBay-Session sind nicht nur vereinzelte Seitenaufrufe, sondern komplette „Flows“ (Homepage • Suche • Gegenstand). Predictive Prefetch hilft dabei, JS- und CSS-Dateien für den Erstbesucher in den Cache zu laden. So kann die Homepage bereits das CSS und JS der Suche im Cache speichern. Sobald der Besucher auf die Suche klickt, lädt die (beim ersten Besuch) schneller.
  • Prefetching geschieht auch für die einzelnen Gegenstände der Suche. Angenommen, es gibt zehn Gegenstände in einem Suchergebnis, so wird der Cache mit den Inhalten dieser Ergebnisse gefüllt. Sobald der Besucher beispielsweise auf Gegenstand 3 klickt, können die Daten dazu direkt angezeigt werden. Prefetching passiert dabei sowohl auf der Serverseite als auch im Browsercache.
  • Bei einer Suche werden die ersten zehn Bilder in einem Chunk direkt im Browsercache abgelegt.
  • Autosuggest bei der Eingabe von Suchbegriffen sind sehr Ressourcen-intensiv bei der Beschaffung. Daher werden die einzelnen Ergebnisse für 24 Stunden zwischengespeichert.
Ebay shopping for Speed

„Speed has now become a foundational element in our product release cycle, following the footsteps of security, availability, and accessibility“. – Senthil Padmanabhan eBay engineer

IV. Yelp – steigert Konversionen um 15 %

Yelp (die amerikanische Version der Gelben Seiten in den USA) optimiert den First Contentful Paint und die Time to Interactive und erreicht eine Verbesserung von 15 Prozentpunkten bei der Konversionsrate.


Bei der Analyse der Ladevorgänge waren die Chrome DevTools von besonderer Hilfe. Im Performance-Tab war ersichtlich, welche Tasks den Hauptthread beim Laden blockierten und wie viel Zeit der Browser damit verbrachte, jede einzelne Ressource zu laden.


Weitere Performance-Verbesserungen:


  • JS-Dateien von 576 KB auf 312 KB (fast 50 % Reduktion).
  • Codesplitting über 7 ladbare Seiten. Jede Seite bekommt nur so viel Code, wie sie benötigt. Es wird nicht der gesamte Code auf der ersten Seite geladen.
  • Nachladen von Komponenten über window.requestIdleCallback(), um UX-Verzögerungen beim Nachladen zu vermeiden.
  • Eliminieren von ungebrauchtem Code aus der Codebasis. Oft werden umfangreiche Bibliotheken geladen, von denen nur wenige Prozent gebraucht werden. Hier lässt sich oft unnötiger Code ausmisten.
  • Ersetzen von größeren Codebibliotheken mit kleineren: Beispiel moment.js mit date-fns ersetzt.
  • Unnötiges re-rendering verhindern. Manchmal werden Komponenten wie die Navigation auf der Seite gerendert, dann geändert, dann neu gerendert.
  • Parallelisierung von Netzwerk-Aufrufen. Falls externe Daten oder Funktionen innerhalb des Ladevorgangs aufgerufen werden, sollte sichergestellt sein, dass diese sich nicht gegenseitig blocken.
  • Redirects eliminieren.
  • HTML Server-seitig rendern. Gerade Mobilgeräte mit schwächeren CPUs können den Rendervorgang unnötig verzögern.
  • Cache aufwärmen: Sicherstellen, dass das Caching richtig funktioniert. Ansonsten den Cachingprozess optimieren.
  • Schnellere Serverhardware hat noch einmal bis zu 20 % mehr Performance geliefert!
Yelp Verbesserung der Rendering Time
Das finale Ergebnis

• Reduktion der P75* FCPs von 3,25 auf 1,80 Sekunden (-45 %)

• Reduktion der P75* YPCs von 4,31 auf 3,21 Sekunden (-25 %)

• 15 % Steigerung der Konversionsrate

*75 % der Pageviews

V. SportsShoes.com – 34 - 41 % mehr Konversionen ...

… wenn Ladezeiten schneller als der Durchschnitt sind. Propellernet ist Anbieter des RUM-Tools Blackbird. RUM steht für real user monitoring. Blackbird zeichnet bis die Millisekunde genau alle Metriken einer Landingpage auf. Beim Monitoring der Konversionsrate für SportsShoes.com ermittelte das Team etwas Erstaunliches.


Bei überdurchschnittlich schnellen Desktop-Besuchern (faster then average visits) wurde eine um 19 % höhere Konversionsrate gemessen. Im Gegensatz dazu liegt die Erhöhung der Konversionsrate bei überdurchschnittlich schnellen Mobil-Besuchern bei 41 %.

Es lohnt sich demnach sehr, den Fokus auf die Optimierung der Mobilnutzer zu richten.


Vodafone fand in Kollaboration mit Google heraus, dass eine Verbesserung der Ladezeit des „Largest Contentful Paints“ einer Landingpage zu 8 % mehr Sales führte. Stolze 11 % mehr Besucher besuchten den Warenkorb. Dabei verbesserte sich der Wert von 8,3 auf 5,7 Sekunden (-31 %).


Die Optimierungen im Detail:

Sport Shoes verbessert Konversionen
  • Auslagerung von Renderlogik vom Client auf den Server / Kritisches HTML bereits Server-seitig bereitgestellt
  • Bilder verkleinert, insbesondere das Herobild und PNGs
  • Verwendung von SVG-Dateien
  • Lazy Loading von Bildern, die erst später geladen werden müssen

VI. NETZWELT – steigert Werbeanzeigenumsatz um 18 % mit Core Web Vitals

Der deutsche Publisher NETZWELT konzentrierte sich bei einem Relaunch des Portals auf die Optimierung für die Core Web Vitals. Dieser führte zu einer Steigerung der Pageviews um 27 %, 18 % mehr Einnahmen durch Werbeanzeigen und 75 % höherer Ad viewability. Diese Case-Study macht deutlich, womit viele Publisher heute kämpfen:


  • Unterschiedliche Anzeigen führen zu unerwünschtem Cumulative Layout Shift (CLS).
  • Der Largest Contentful Paint (LCP) ist verspätet, weil die Anzeigen selbst oft nicht optimiert genug sind bzw. in Bandbreitenkonkurrenz zum Beispiel mit dem Hero-Elemente auf der Seite stehen.
  • Das JavaScript von Drittanbietern führt zu einem hohen First Input Delay (FID).
  • Das allseits geliebte Cookie-Consent-Popup kann zusätzlich zu CLS führen oder den LCP verfälschen, wenn es als solcher erkannt wird.
Die Pagespeed von Netzwelt
NETZWELT konnte für all diese Probleme Lösungen finden. Nicht immer beheben diese 100 % das Problem, oft aber führen sie zu drastischen Verbesserungen. Da die Dimensionen und die Dateigrößen von Anzeigen vor der Auslieferung nicht bekannt sind, kann es prinzipbedingt keine perfekten Lösungen geben.


  • Anzeigen above the fold verursachen oft große Sprünge beim Aufbau des Layouts. NETZWELT hat die Top-Aneige einfach in ein Sticky-Element gepackt, was den CLS verhindert.
  • Um den FID zu optimieren, wurden alle JS-Skripte mit defer oder async geladen, geladene JS-Bibliotheken mittels treeshaking und unbundling erleichtert, CSS-Struktur mit BEM-Regeln vereinfacht, lange Tasks mit dem idel-until-urgentPattern optimiert, bei visuellen Updates stets RequestAnimationFrame verwenden.
  • Große Anzeigen können den LCP negativ beeinflussen. Um das zu vermeiden, hat NETZWELT bei der Ladereihenfolge stets dem Content Vorrang gegenüber den Anzeigen gegeben, kritisches HTML und CSS zuerst geladen bzw. kritisches CSS separiert und im HTML geladen, die wichtigsten Fonts, Skripte und Bilder vorgeladen, kein lazy loading für Bilder above the fold und font-display: swap verwendet.

Besonders interessant ist die Einbindung des Cookie-Consents. Schließlich müssen Besucher in der Regel erst den Cookies zustimmen, bevor diese angezeigt werden können. Da dies zu CLS führen kann, berücksichtigt Netzwelt Leerraum für die Werbeplätze schon vor der Einwilligung, um Shifting zu vermeiden. Aus dem gleichen Grund verwendet die Consentbox außerdem position: fixed. Die Skripte werden mit async geladen, um Blocking zu vermeiden.


Aus dieser Case-Study sollten wirklich alle Webseiten-Betreiber etwas für die Performance-Optimierung lernen können. Nicht nur die, die ihren Umsatz hauptsächlich über Werbeanzeigen generieren.


Vollständige Informationen auf web.dev: How committing to Core Web Vitals increased Netzwelt‘s advertising revenues by 18 %.

VII. TUI – reduziert Ladezeiten um 78 %, steigert Bouncerates um 31 % und mobile Konversionsrate um 11 %.

Besonders interessant an der TUI-Case-Study sind weniger Zahlen, sondern die Soft Learnings. Das TUI-Team hat sich intern stark für das Speedprojekt gemacht und konnte das gesamte Unternehmen dafür gewinnen, am Optimierungsprozess mitzuwirken. Angefangen mit dem CEO Alex Huber über das Finanzteam bis hin zum UX-Team.


Das Dev-Team hat cross-functional teams etabliert, deren Aufgabe es war, die jeweiligen Abteilungen zu integrieren und das Vorhaben der Speedoptimierung abteilungsgerecht aufzubereiten

Tui Case Study PageSpeed
Noch nicht genug gelesen?


Alle Informationen rund um die Case Studies und die Web Vitals kannst du dir jetzt auch als Datei herunterladen. Du musst keine deiner Daten angeben – einfach klicken, runterladen und in Ruhe nachlesen. ☺️

3. Ein Überblick über die Web Vitals

Die Web Vitals sind eine Sammlung spezieller Faktoren, bei denen es weniger um die rohe Ladegeschwindigkeit, den Durchsatz des Servers oder die Geschwindigkeit der Verbindung geht. Es kommt bei den Vitals eher auf die „wahrgenommene“ Anzeigegeschwindigkeit einer Seite an.


Vereinfacht gesagt: Wie schnell baut sich der erste Teil der Seite auf und wie lange dauert es, bis der Rest geladen ist? Kann der Nutzer direkt mit der Seite interagieren, ohne dass sie „wild rumzuckt“ bzw. die Elemente sich noch aufbauen? Es geht also mehr um ein Gefühl. Fühlt sich Site schnell an?


Dazu gibt es sechs messbare Geschwindigkeits-Faktoren.

Die Core Web Vitals – wichtig für die User-Experience und die Google Rankings

Zu unterscheiden sind die sogenannten Core Web Vitals von den restlichen Web Vitals.
Die Core Web Vitals Metriken
Die drei Core Web Vitals verwendet Google in der Rankingberechnung. Sie spielen dabei eine wichtige Rolle und sind nicht nur ein Nebenfaktor:


„Core Web Vitals Ranking Factor is More than a Tie Breaker“.


Es ist allerdings nicht auszuschließen, dass in Zukunft andere Faktoren hinzukommen oder sich die Gewichtung bei der Rankingbewertung im Laufe der Zeit verschiebt.


Eine schnelle Seite verbessert drei wichtige Aspekte der User-Experience: das Ladeverhalten, die Interaktivität und die visuelle Stabilität. Diese Faktoren sind neben den Inhalten wichtig für die allgemeine Qualität einer Seite. Tendenziell werden sie in Zukunft für die Rankinggewichtung eher an Bedeutung hinzugewinnen.

Largest Contentful Paint (LCP)

Der LCP identifiziert den Zeitpunkt, zu dem der Hauptinhalt einer Seite für den Besucher vollständig geladen ist. Darunter fallen Bilder, Videos (hier nur die Videoposter) und Texte. Streng genommen handelt es sich nur um das größte Element auf der Seite, allerdings ist das in der Praxis meist der Hauptinhalt einer Seite. Im Gegensatz führt ein Ladebalken oder Splashscreen zwar zu einem schnelleren First Contentful Paint, solche Elemente haben jedoch kaum einen Nutzen für den Besucher.
core Web Vitas – LCP
Werte von unter 2,5 Sekunden sind schnell. Über die gesamte Website gesehen, sollten gute Werte bei mindestens 75 % aller Seiten erreicht werden.

First Input Delay (FID)

Der FID ist vereinfacht gesagt die Zeitspanne zwischen dem ersten Seitenaufruf und dem Zeitpunkt, zu dem der Besucher mit der Seite interagieren kann. Darunter fallen Aktionen, wie Cursor in einer Suchbox platzieren, Text markieren, einen Link oder Button klicken. Es geht hauptsächlich darum, Interaktivelemente nicht zu blockieren, während andere Funktionen und Inhalte nachgeladen werden. Beispielsweise kann der Ladevorgang der Seite insgesamt fünf Sekunden dauern, der Besucher versucht vielleicht schon nach einer Sekunde auf einen Button zu klicken.
Core Web Vitals - FID
Gute Werte liegen unterhalb der 100-Millisekunden-Grenze.


Um den FID zu optimieren, sollten für die direkte Ausführung nicht kritische Elemente und JavaScript-Code aufgeteilt werden.


Beispiel: Die Seite lädt insgesamt drei Buttons, zehn Bilder und viel JavaScript-Code für die Galeriefunktionen, aber darüber hinaus auch Trackingcode und Code zur Anzeige von Werbeinhalten. Der Trackingcode und die Werbefunktionen sollten erst geladen werden, wenn die Galeriefunktionen sichergestellt sind. So kann ein Besucher sofort auf ein Bild klicken, dass sich dann im Galeriemodus öffnet, inkl. Buttons für „nächstes“ und „vorheriges“ Bild.

Cumulative Layout Shift (CLS)

Wenn sich Elemente beim Ladevorgang bewegen, also ihre Position verändern, dann fällt dies unter den Begriff CLS. Dieses „Shiften“ oder „Herumspringen“ kann zu Fehleingaben führen, sodass sich der Besucher „verklickt“. Es versteht sich von selbst, dass dies unter allen Umständen zu vermeiden ist. Außerdem ist es sehr nervig. Das Phänomen ist oft aus Seiten zu beobachten, die beim Scrollen Werbeanzeigen nachladen.
Core Web Vitals – CLS
Idealerweise ist der CLS auf 0 oder wenigstens unter 0.1. Dies ist in den meisten Fällen leicht zu erreichen, solange bei der Ausrichtung von Elementen (Bilder, Videos, Text etc.) Positions- und Dimensionsangaben (Breite/Höhe) gemacht werden.


So viel zu den Core Web Vitals. Die folgenden Web Vitals sind nicht minderwichtig. Zwar sind sie aktuell nicht Bestandteil des Google-RankingAlgorithmus. Was nicht ist, kann aber noch werden. Sie spielen jedenfalls eine wichtige Rolle für die Ermittlung der Performance-Kennzahlen.

First Contentful Paint (FCP)

Der FCP misst die Ladezeit der allerersten Inhalte – das erste Stück DOM-Content. Darunter fallen Bilder, (nicht-weiße) canvas-Elemente sowie SVG-Dateien.
Web Vitals – FCP
Im Mittel liegen die FCP-Ladezeiten beim HTTP Archive Projekt ungefähr 2 Sekunden (blaue Linie) für die Desktop-Variante. Die Mobilversion benötigt rund 5 Sekunden, was deutlich langsamer ist. Der HTTP Archive crawlt übrigens seit Mitte 2018 regelmäßig über 5 Mio. URLs.
Web Vitals – FCP2

Speed Index (SI)

Der SI misst, wie schnell sich die Inhaltsblöcke einer Seite beim Ladevorgang zusammensetzen. Bei der Messung wird ein Video des Ladevorgangs erstellt und gemessen, wie viel sich zwischen den einzelnen Frames des Videoclips verändert. Stockt der Ladevorgang beispielsweise, weil im Hintergrund Ladeprozesse das Voranschreiten verhindern, dann leidet der Speed Index darunter.
Web Vitals – Speed Index
Der durchschnittliche Speed Index im HTTP Archive liegt bei knapp unter vier Sekunden für Desktop und neun Sekunden bei Mobile. Darunter zu bleiben, ist bei den meisten Seiten ein realistisches Ziel. Unter drei Sekunden ist ideal. Natürlich geht das nicht immer, denn in vielen Fällen wollen Besucher auch länger auf größere Bilder, Videos etc. warten.

Time to Interactive (TTI)

Der TTI ist der Zeitpunkt, an dem die gesamte Seite voll interaktiv wird. Dazu sind drei Kriterien zu erfüllen.


  1. Nützliche Inhalte anzeigen, wie durch den FCP gemessen.
  2. Event-Handler für alle sichtbaren Elemente sind registriert.
  3. Die Seite reagiert innerhalb von 50 Millisekunden auf Nutzerinteraktion.

Den stärksten Effekt für die Verbesserung der TTI-Metrik hat das Entfernen oder Ausgliedern von JavaScript-Funktionalität.


TTI-Metrik (in Sekunden)    Bewertung


0 – 3,8                                     Schnell


3,9 – 7,3                                   Moderat


Über 7,3                                   Langsam

Total Blocking Time (TBT)

Die TBT ist die Menge an Zeit, die zwischen dem First Contentful Paint (FCP) und der Time to Interactive (TTI) vergeht. Dies ist die Zeit, in der der Main-Thread des Browsers einen Userinput blockiert. Sollte eine Verzögerung länger als 50 Millisekunden dauern, dann fühlt sich die Seite für den Besucher träge an.
Web Vitals – Total Blocking-Time
Nur Tasks, die länger als 50 Millisekunden dauern, werden als Blocking wahrgenommen. Daher werden nur die dunklen Bereiche aus der Grafik zusammengerechnet. Jetzt wird es ein wenig tricky.


Der TTI ist erreicht, sobald die TBT 5 Sekunden vorüber ist. Erst dann ist eine Seite „zuverlässig interaktiv“. Das heißt aber auch, dass drei Tasks, die 51 Millisekunden dauern und über 10 Sekunden verteilt sind, eine TBT von 9.950 Millisekunden haben. Drei Tasks mit 51 Millisekunden direkt hintereinander ausgeführt hätten aber nur eine TBT von 3 Millisekunden. Letzteres ist auf jeden Fall besser.

WebVitals – Total-Blocking-Time

Gewichtung der Core Web Vitals

Die Gewichtung der einzelnen Faktoren in einen Wert zwischen 1 und 100 macht jede Testsuite (GT metrix, Google Pagespeed Insights, Lighthouse u.a.) etwas anders. Interessant ist jedoch die Gewichtung in Lighthouse 8, dem Messtool von Google, das direkt in Chrome eingebunden ist. Hier lässt sich gut erkennen, worauf es bei den eigenen Messungen wirklich ankommt.

Lighthouse 8 Gewichtung der Core Web Vitals

Web Vitals – Lighthouse 8

4. Tooltips

Tooltip: Zipkin


Zipkin hilft bei der Aufzeichnung von komplexen Timingdaten für größere Webanwendungen.

tooltip-zipkin
Tooltip: Splunk (kostenpflichtig)


Splunk liest u. a. Performance-Daten aus der Datenbank und visualisiert diese live.

Der Core Web Vitals Optimizer ist Open Source und hilft bei der Aufzeichnung der Performance-Werte.


Instant Vitals besteht aus zwei Komponenten. Der Client sammelt Performance-Werte und schickt sie an den Server, der sie aufbereitet und sie Google BigQuery speichert. Von da lassen sich die Daten individualisiert abfragen. Der Vorteil von Instant Vitals besteht darin, dass es HTML-Elemente als XPath-Abfragen speichert. So lässt sich nachher genau ermitteln, genau welche Stelle im HTML-Dokument Verzögerungen ausgelöst hat.

5. Fazit


TIPP 💡


Wenn du noch mehr über das Thema Speedoptimierung lernen möchtest, empfehlen wir dir, dich über diese Links einzulesen:




Picture of Johanna
Johanna
Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert