Pagespeed Header

Der definitive Pagespeed-Guide: 10 Fakten in 5 Minuten

Die Wichtigkeit von Pagespeed für den unternehmerischen Erfolg von Onlinehändlern wird in „mobile-first”-Zeiten immer deutlicher. Der Online Marketing Fokus nimmt verstärkt die Optimierung der Conversion Rate ins Visier, welche eng mit der Seitengeschwindigkeit in Verbindung steht. Welche Faktoren sind aber tatsächlich relevant? Wir haben die wichtigsten Pagespeed Fakten gesammelt und räumen mit den größten Mythen auf.

Fakt 1

Pagespeed und Conversion Rate: Zeit ist Geld

Eine Sekunde langsamer entspricht einem Conversion Rate Rückgang von 7%

Laut einer Studie von Akuma erwarten 83% der Besucher, dass eine Webseite in unter 3 Sekunden lädt, pro Sekunde Ladezeit nimmt die Conversion Rate um bis zu 7% ab (Section.io). Jede gewonnene Sekunde Ladezeit bedeutet damit höheren Umsatz.

Fakt 2

Pagespeed und SEO Ranking: Server Response Time im Fokus

Top 3 Seiten in Google Organisch haben häufig eine Server Response Time unter 300 ms

Google hat bereits 2010 offiziell bestätigt, dass das SEO-Ranking vom Pagespeed direkt beeinflusst wird – zumindest für Desktop. Dieser Effekt scheint besonders bei Top-Rankings erkennbar: nach einer Korrelationsstudie von Zedwoo und SEM Deutschland ist eine geringere Serverantwortzeit, auch Time-to-First-Byte oder TTFB genannt, signifikant mit höheren Rankings korreliert. Auf den ersten Plätzen macht sich dieser Effekt besonders stark bemerkbar. Hier können für kompetitive Suchen nur Seiten mithalten, welche eine Desktop Server Response Time von 300ms nicht überschreiten.

Zum mobilen Pagespeed-Effekt auf SEO gab Google Ende 2016 Entwarnung: Pagespeed wird laut John Müller für den geplanten Mobile-first Index noch nicht herangezogen. Die Effekte des Accelerated Mobile Pages Markups sind abzuwarten.

Fakt 3

Unterschiedlich stark: Server Response, Content Loaded und Page Load Time

Server Response Time ist die wichtigste Metrik, gefolgt von Content Loaded Time, die Gesamtladezeit ist die unwichtigste

Das Gesamtkonzept Pagespeed setzt sich aus drei Teilmetriken zusammen:

  1. SRTServer Response Time: Die SRT beschreibt die Zeit zwischen Browser Request und Antwort des Servers, d. h.: Browser sendet Anfrage – Server bereitet Antwort vor – Browser erhält erstes Byte (entspricht TTFB)
  2. CLTContent Loaded Time: Die (DOM) Content Loaded Time setzt sich fort mit dem ersten Byte vom Server und endet, wenn HTML, CSS, Bilder und synchrones JavaScript geladen sind.
  3. PLTPage Load Time: Die PLT oder Seiten-Ladezeit setzt sich fort mit abgeschlossenem Seitenaufbau , wenn die Seite “DOM-Ready” ist. In dieser letzten Phase werden vorrangig Bilder und asynchrones JavaScript nachgeladen. Dies sind Marketingskripte wie Webanalyse und Retargeting, welche oft weitere Ressourcen nachladen. Daher ist die letzte Metrik deutlich nachrangiger, da der User diese Prozesse nicht wahrnimmt.

Abb.1: Typischer Seitenladeprozess in Google Chrome – unterteilt in SRT, CLT und PLT

Fakt 4

Vergleichbarkeit zählt: „Die Seite braucht 10 Sek! Wie kann das sein!?"

Für Sekundenvergleiche: Halten Sie Verbindungsfaktoren mittels gleicher Toolsettings konstant und definieren Sie einen Teststandard

Einige Tools wie Webpagetest.org, Pingdom und GT Metrix, geben absolute Sekundenmessungen von Seitenladeprozessen an. Eine Vergleichbarkeit ist jedoch nur unter Kontrolle und Festlegung der folgenden Umgebungsfaktoren möglich, für ein Einzelmessungs-Reporting sollte Einigkeit bzgl. der untenstehenden Faktoren bestehen:

Netzwerkverbindung: Downloadraten variieren nach Gerät zwischen 56 kBit/sek bis über 100 Mbit, im DE-Durchschnitt liegen sie bei 13,7 Mbit für Desktop und 6,1 Mbit Mobil. Für Stichproben ist ein Wert um 3 Mbit empfehlenswert.

Standort: Es sollte mind. das Land spezifiziert sen, um unnötige Netzwerkknoten zu vermeiden, bevorzugt eine Stadt oder Rechenzentrum wie Frankfurt.

UserAgent: Jeder Browser nutzt andere Einstellungen.

Caching: Browserseitiges Caching von statischen Dateien kann die Content Loaded Time senken, während serverseitiges Caching von dynamischen und statischen Teilen die Server Response Time verringern kann. Dies kann Unterschiede über 100 % ausmachen.

Uhrzeit: Je nach situativer Nutzerlast, Speicherauslastung der App-Server und Befüllung der Caching-Server kann die Geschwindigkeit nach Tageszeit und Wochentag stark variieren.

Fakt 5

Reporting Strategie: Regelmäßig, pro Seitentyp und mit großer Stichprobe

Messen Sie Pagespeed regelmäßig, seitentypbasiert und mit ausreichender Stichprobe

Neben der Kontrolle von Umgebungsfakoren für Einzelmessungen sollte man für ein aussagekräftiges Bild  die verschiedenen Teilmetriken (SRT, CLT und PLT) regelmäßig mit größerer Stichprobe sammeln. Mit dieser Methode erhält man ein reales Bild vom Verhalten der Website in Lastzeiten sowie der einzelnen Seitentypen, da die Enduserzeiten gemessen werden. Dies ist ebenfalls das Vorgehen der Pagespeedmessung bei Webanalysetools wie Google Analytics. Größere Stichprobenmengen sind für Änderungen und Relaunches gut verwertbar, da auch die strikte Kontrolle der Umgebungsfaktoren weniger ins Gewicht fällt.

Aus Shop-Sicht ist es zielführend, die Einzelmessung nach Seitentyp  zu gruppieren, da die zugrundeliegenden Aufrufketten sich teils stark unterscheiden. Daher ist ein Reporting nach Seitentyp die wichtigste Auswertungsdimension. Für regelmäßige Messungen eignen sich die Pagespeedmetriken der Webanalysetools gut, da die Daten über Dimensionen aggregierbar sind. Einziger Vorbehalt: Die genaue Messmethodik inkl. Einschränkungen, wie Sampling, sollte allen bei Reportingstart bekannt sein.

Fakt 6

Pagespeed-Tools: Einzeldiagnose ist nicht Reporting

Ideales Toolset: 1. Einzelmessungen mit Faktorenkontrolle und 2. Dauermessungen pro Seitentyp über Webanalyse

Nach Aussagen zu Einzel- und Reihenmessungen stellt sich die Frage, welches Tool für den jeweiligen Zweck am besten geeignet ist. Es gibt eine Reihe von Pagespeedtools mit verschiedenen Stärken und Schwächen, grundlegend empfiehlt sich eine Differenzierung zwischen diagnostischer und Reportingzielsetzung:

  • Einzeldiagnose: Hier stehen genaue Ressourcenabfrage-Sequenzen im Vordergrund, um Ursachen zu identifizieren. Eine gemessene Sekundenzahl wird erst belastbar, wenn Umgebungsfaktoren konstant gehalten werden, analog einer Ruhepulsmessung.
  • Regelmäßiges Reporting: Hier steht die tägliche, detaillierte Sammlung von Pagespeeddaten im Vordergrund, ohne differenzierte Diagnostik und Ursachenprüfung.

In dieser Zweiteilung der Zielsetzung ergibt sich folgende Gegenüberstellung der gängigen Pagespeed-Tools:

Tool

Vorteile

Nachteile

GT Metrix
(Google PageSpeed + YSlow)
  • Detaillierte Diagnose mit angefragten Ressourcen und Wasserfalldiagramm
  • Ergebnisse von Google’s Pagespeed und Yahoos YSlow
  • Keine Free-Version
  • Für Geo-Auswahl ist Paid-Version notwendig
Webpagetest.org
Pingdom
  • Detaillierte Diagnose
  • Kontrolle der Faktoren in Free-Version: Ort, Browser, Verbindung Anzahl von Tests, Repeat View etc.
  • Test in Free-Version
  • Kein regelmäßiger Test
Webpagetest.org
(Google Analytics, Econda etc.)
  • Häufige Messung durch Stichprobe aus Sitzungen
  • Viele Dimensionen wie Gerät verfügbar, sowie eigene wie Seitentyp möglich
  • Historischer Verlauf
  • Keine Kontrolle der Umgebungsfaktoren
  • Sampling der Messungen auf 1%

Fakt 7

Interpretation der Indexwerte „Nur 59 aus 100 Punkten!?”

Indices sind als schnelle Orientierung zu sehen, nicht als detaillierte Differentialdiagnose

Das meistgenutzte Pagespeedtool – selbstverständlich von Google, unter testmysite.google.com verfügbar – verzichtet wegen oben genannter Faktoren auf absolute Sekundenmessungen und setzt im Kern auf drei Indexwerte bis 100 Punkte. Es werden zusätzlich konkrete Optimierungsempfehlungen zu geladenen Dateien gegeben.

Neben dem oben genannten Vorbehalt der Einmalmessungen und Zweifeln an der generellen Toollegitimation ist bei Indizes zu beachten, dass sie bewusst Komplexität und Vielfalt vereinfachen. Pauschale Empfehlungen sind dabei wie Indices: Einfach und grundlegend richtig, jedoch für bestimmte Shopsysteme oft nicht einfach realisierbar und ggf. ohne echten Mehrwert hinsichtlich der Teilmetriken. Beispiel: Eine Abschaltung von Retargeting-Tags kann zu einer Indexscore-Erhöhung wegen einer geringeren Pageload-Time führen, obwohl für den Nutzer kein Unterschied spürbar ist.

Fakt 8

Benchmarking is key: Sinnvolle Referenzen definieren

Ein sinnvoller Benchmark nimmt auf Branche, Kundengröße und ggf. auch auf ein vergleichbares Shopsystem Rücksicht

Nach Festlegung der Messmethodik liegt der Wunsch nach einem Vergleich mit Wettbewerbern nahe, um zu sehen, wie diese im Bereich Pagespeed stehen. In Abwesenheit von Webanalysedaten oder Dauermessungen der Konkurrenten muss hier mit Einmalmessungen oder Indices Vorlieb genommen werden, was als grobe Orientierung jedoch ausreichend ist. Folgende Faktoren sollten für den Auswahl eines sinnvollen Benchmarks beachtet werden:

  • Branche. Der Benchmark sollte in der gleichen Branche liegen. Hochauflösende Bilder im High-Fashion sind nicht mit Online-Apotheken zu vergleichen.
  • Kundengröße. Ein realistischer Vergleich zielt auf einen Konkurrenten, welcher branchengleich im Umsatz etwa 20-100% größer ist. Ein Vergleich mit den Branchenriesen ist auf technischer Basis unrealistisch und nicht ressourceneffizient.
  • Shopsystem.  Auch wenn es Gegner der shopsystem-fixierten Denkweise gibt, schreibt dieses einen gewissen Rahmen vor. Es ist damit eher ein kontextuelles als ein hartes Kriterium, doch bewegen sich alle Mittelständler in einem endlichen Budgetrahmen. Ein Vergleich mit anderen Shops und Shopsystemen ist daher nicht ausgeschlossen, doch sollten Abweichungen immer im Rahmen der Systeme und Budgets gesehen werden.

Fakt 9

HTTPS und HTTP/2 ist der neue Standard - Sind Sie bereit?

Investieren Sie in HTTP/2 und HTTPS-by-Default. Nutzen Sie Domain-Sharding mittels CDNs, falls aufgrund hoher internationaler Zugriffe sinnvoll

Bereits 10% der Top-Million Seiten nach BuiltWith nutzen mittlerweile HTTPS-by-default, die verschlüsselte Client-Server-Verbindung wird damit zum Web-Standard. Trotz eines leichten Zeitverlustes durch zusätzlichen Austausch von Informationen – auch SSL oder TLS-Handshake genannt – setzt sich HTTPS aufgrund günstigerer Zertifikate, fertiger Serverpackages und höherem Uservertrauen durch.

Der HTTP/1.1 Standard stammt aus dem Jahr 1997 und lässt, neben anderen Nachteilen, nur 5 parallele Ressourcenaufrufe des gleichen Hosts – Subdomain und Rootdomain – in einer TCP-Connection zu. Besonders im mobilen Kontext sollte berücksichtigt werden, dass nicht allein die Dateigröße, sondern ebenfalls der Anstieg der Requestanzahl verlangsamend sind. Dies hat verstärkt zu Praktiken der Ressourcenoptimierung geführt, welche in HTTP/2 zukünftig obsolet werden:

  • Domain-Sharding. Nutzung eines CDNs, um z.B. alle statischen Inhalte von einer separaten Subdomain zu hosten
  • Image spriting. Nutzung von CSS, um viele Bilder in einer Datei zu konsolidieren.
  • Konkatenierung von CSS/ JS. Konsolidierung vieler in jeweils eine CSS/JS  Datei.

HTTP/2 verbreitet sich rasant

Der neue Standard HTTP/2 umgeht die obige Einschränkung durch sog. “Multiplexing”, welches mehrfache HTTP Requests und Responses über die gleiche TCP-Connection zulässt.  Im Dezember 2016 unterstützten bereits 11% aller Webseiten und 78% aller Browser HTTP/2. Ein zwingende Voraussetzung für HTTP/2 ist die HTTPS-by-default Fähigkeit eines Webservers, daher verstärken sich beide Trends gegenseitig. Google treibt die Entwicklung ebenfalls maßgeblich voran: Seit Ende 2015 steht das Gerücht im Raum, dass in Zukunft Chrome nur HTTP/2 unterstützen könnte.

Fakt 10

Pagespeed-Tools sind unterschiedlich: Einzeldiagnose ist nicht Reporting

Nicht immer sorgt mehr Hardware für eine linear bessere Performance. Individuelle Lösungen für individuelle Probleme sollten das Ziel sein. Verschiedene Teilmetriken erfordern einen individuellen Fokus

Metrik

Ursachen & Maßnahmenfokus

Server Response Time Application Stack: Loadbalancer, Serveranzahl und Leistung (App-Server & Web-Server und Datenbank), Programmiersprache, Caching-Server, Datenbank-Queries, Pre-Rendering & weitere Faktoren
Ende: HTML Datei wird serviert, Erstes Byte geladen
Content Loaded Time Asset Komprimierung: Können Bilder, css und JavaScript pro Seitentyp komprimiert werden?

Asset Reduktion: Können Bilder über CSS Sprites oder CSS/JS in weniger Dateien konsolidiert werden?
Ende: Seite ist “DOM-Ready” und bereit zur Interaktion

Page Load Time Marketingscripte oder asynchrones JavaScript, wie Trackingtools , Tag Manager & Retargeting, werden nachgeladen, diese rufen wiederum weitere aus. Sind alle wirklich notwendig? Wie sind die Server-timeouts?
Ende: Alle Dateien nachgeladen

How-To

Projektumsetzung mit starken Partnern

Die Diagnose und Maßnahmenkonzeption zur Pagespeed-Optimierung sollte von einem Expertenteam aus Shopentwicklern und Hostingverantwortlichen vorgenommen werden. Als OXID-Agentur pflegen wir eine enge Partnerschaft mit unserem Hostingpartner SysEleven, einem der führenden Shophoster in Deutschland. Die auf Geschwindigkeit spezialisierte Unternehmensabkopplung ScaleCommerce – Thomas Lohner und Joscha Krug als Geschäftsführer – agiert als Sparringpartner in unseren Pagespeed-Projekten, um eine externe diagnostische Meinung einzuholen. Diese unabhängige Einschätzung durch Experten ist bei größeren Optimierungsprojekten sehr zu empfehlen, um einen ganzheitlichen Ansatz von Architektur- bis Codereview-Ebene zu erarbeiten.

FAZIT: Die Wahrheit ist vielschichtig – Setzen Sie auf Experten!

Pagespeed-Beratung hinsichtlich Konzeption, Umsetzung und Monitoring sollte in den Händen von Experten liegen. Dies umfasst das Shopsystem, den Application Stack, und alle eingesetzten Komponenten. Als Shopagentur sind wir als Enterprise-Partner auf das  OXID-Framework spezialisiert,  unser Performance Marketing Team unterstützt bei der Projektbegleitung durch gezieltes Reporting.

Falls Sie die Geschwindigkeit Ihres OXID-Shops nachhaltig verbessern möchten oder Sie konzeptionelle Projektunterstützung benötigen – Kontaktieren Sie uns!

Christopher Gutknecht ist Head of Online Marketing bei norisk. Sowohl auf Bergen und Kletterwänden als auch in den Suchergebnissen will er stets ganz nach oben.

Pagespeed ist genau Dein Thema? Dein Herz schlägt für zielführendes Onlinemarketing? Dann melde Dich bei uns – wir sind immer auf der Suche nach Experten!