In „mobile-first”-Zeiten sind geringe Ladezeiten maßgebend für den Erfolg von Onlineshops. Jeder Online Marketer hat die Erhöhung der Conversion Rate im Visier, welche eng mit der Seitengeschwindigkeit in Verbindung steht. Welche Faktoren sind für schnelle Shops 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%!
- 100ms Beschleunigung bringen 1% mehr Umsatz!
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 dabei um 7% ab.
Amazon spricht von +1% Umsatz pro 100ms Beschleunigung. Kurzum: Jede gewonnene Sekunde Ladezeit bedeutet höheren Umsatz.
Diese Verhältsmäßigkeit verstärkt sich im mobilen Bereich mit zunehmendem Trafficanteil, wenn Shopseiten über schwache 3G (~ 750 KB/Sek down) geladen werden. Ernüchternd, aber wahr: Die durschnittliche Ladezeit eines Shops steigt also nur durch mehr mobile Zugriffe. Onlinehändler müssen daher zielgerichtet entgegenwirken.
Beispielrechnung: -100ms = +1% Umsatz
Pagespeed & Conversion Rate: Umsatzsteigerung
Nimmt man die obige Amazon-Verhältnismäßigkeit als Grundlage für eine Umsatzssimulation mit stufenweise schnellerer Server Response Time (SRT), ergeben sich folgende Werte für eine mittlere monatliche Umsatzgröße: Sitzungen und Warenkorb werden konstant gehalten, daher ist die Conversion-Rate Steigerung (CR) linear zur Umsatzsteigerung.
Abbildungen oben: Umsatzsimulation bei Senkung der Server Response Time
Das Ergebnis: -0,5 Sek (-33%) Pagespeed können +5% Mehrumsatz pro Monat bedeuten!
Um den absoluten Hebel zu verdeutlichen: Eine Beschleunigung in der Server Response Time von 1,5 auf 1,0 Sek (-33%) hat das Potential einer direkten 5%igen Umsatzsteigerung. In absoluten Zahlen: bei 300k€ Basisumsatz sind das 15.000€ pro Monat oder 180.000€ im Jahr! Es lohnt sich also aus, auch bei Monatsumsätzen unter 500k in Pagespeed zu investieren. Bei größeren Umsätzen ist der absolute Hebel umso größer.
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“
Abbildung: Zusammenhang von Downloadrate und Anzahl gecrawlter Seiten in der Google Search Console
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 Studie von Zedwoo 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 bemerkbar: hier können für kompetitive Suchen oft nur Seiten mithalten, die eine Desktop Server Response Time von 300ms erreichen – Google’s Empfehlung liegt sogar bei 200ms.
Google gab Ende 2016 zum mobilen Pagespeedeffekt Entwarnung, es werde laut John Müller in dem für 2018 geplanten Mobile-first Index noch nicht herangezogen – ABER: es zeichnet sich ein stärkerer Einfluss von Ladezeiten auf SEO Rankings ab, wie Searchengineland im „Periodic Table of SEO“ unterstreicht.
Für die praktische SEO-Arbeit ist die Download Rate (von Ressourcen) in der Google Search Console von Relevanz: Eine schnellere Downloadzeit ist meist mit einer höheren Anzahl an gecrawlten Seiten korreliert. Googlebot crawlt schnelle Shops demnach tiefer und gründlicher als langsame – besonders bei Relaunches mit URL-Neuindexierungen relevant.
Der Effekt des Accelerated Mobile Pages (AMP) Markups bleibt abzuwarten. Dieser seit Ende 2016 stabile Standard soll Ladezeiten um 50%reduzieren können. Der Vorbehalt: AMP spielt vor allem bei einfachen, statischen Contentseiten seine Stärken aus – je mehr dynamische Inhalte, desto schwieriger ist die Umsetzung in einem Responsive Theme.
Fakt 3
Unterschiedlich wichtig: Server Response-, Content Loaded- und Page Load-Time
„Server Response Time ist die wichtigste Metrik, gefolgt von Content Loaded Time, die Gesamtladezeit ist für den User nachrangig.„
Das Gesamtkonzept Pagespeed-Messung kann in mehrere Teile strukturiert werden. Im Folgenden wird eine vereinfachte Dreiteilung, angelehnt an Google, verwendet. Weitere Metriken wie StartRender oder FirstPaint werden von Tools wie Webpagetest genutzt. Hier wird Ladezeit in drei Teilmetriken differenziert:
1. SRT – Server 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. CLT – Content 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. Hier lässt sich noch zwischen Content Interactive und Loaded unterscheiden.
3. PLT – Page Load Time: Die PLT oder (gesamte) Seitenladezeit setzt sich fort mit abgeschlossenem Seitenaufbau, wenn die Seite “DOM-Ready” ist. In dieser letzten Phase werden Dateien asynchron nachgeladen. Dies sind vorrangig JavaScript-Dateien für Webanalyse und Retargeting, welche meist weitere Ressourcen nachladen. Daher ist diese Metrik eher nachrangig, der User nimmt die Prozesse nur durch verzögertes Laden des Browsertabicons – oder Favicon – wahr.
Wesentlich bei einer Betrachtung der Seitenladezeit ist also, die Gesamtzeit in Teilmetriken herunterzubrechen. Die vorderen Abschnitte sind dabei höher zu gewichten, die späteren aber nicht zu missachten: Falls durch Retargetingtags mit 150 Requests im Huckepack die Zeit nach Content Loaded mehr als 5s beträgt, sollten alle Tags genauer evaluiert werden. Hier hilft die Browserextension Ghostery seit Version 7 mit dem Schneckenicon für langsame Tags.
Abbildung: 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!?"
„Halten Sie Verbindungsfaktoren mittels gleicher Toolsettings für Sekundenvergleiche konstant und definieren Sie einen Teststandard“
Einige Tools wie Webpagetest, Pingdom und GT Metrix geben absolute Messungen von Seitenladeprozessen an. Eine Vergleichbarkeit ist jedoch nur unter Kontrolle und Festlegung der folgenden Umgebungsfaktoren möglich, für eine Einzelmessung sollte Einigkeit bezüglich der untenstehenden Faktoren herrschen:
- Netzwerkverbindung: Downloadraten variieren nach Gerät zwischen 56 kB/s 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 5 Mbit empfehlenswert, um einen typischen Split der Zugriffe pro Gerät abzubilden.
- Standort: Es sollte mindestens das Land spezifiziert sen, um unnötige Netzwerkknoten zu vermeiden, bevorzugt eine Stadt oder Rechenzentrum wie Frankfurt. Geo-Unterschiede können in über 100% Differenz resultieren, v.a. ohne Content Delivery Network (CDN).
- 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 Prozent erzeugen.
- Uhrzeit: Je nach situativer Nutzerlast, Speicherauslastung der App-Server und Befüllung der Caching-Server kann die Geschwindigkeit nach Tageszeit und Wochentag stark variieren.
Unterm Strich sind Einmalmessungen auch bei Kontrolle der obigen Faktoren keine zuverlässigen Aussagen zur Ladezeit von Shops, da es zu viele moderiende Variablen gibt – statistisch gesehen: valide, aber nicht reliabel. Für absolute Sekundenwerte sind regelmäßige Messungen zu bevorzugen.
Fakt 5
Reportingstrategie: Regelmäßig, pro Seitentyp und mit großer Stichprobe
„Pagespeed Performance nach Seitentyp ist wichtigste Reportingdimension für Shops – große und regelmäßige Stichproben sind zu bevorzugen“
Abbildung: Beispielhaftes Pagespeed-Reporting pro Seitentyp für Detailseite, Start- und Kategorieübersichtsseite
Neben der Kontrolle von Umgebungsfakoren für Einzelmessungen sollte man für ein aussagekräftiges Bild die verschiedenen Pagespeedmetriken (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 von den einzelnen Seitentypen, da die Enduserzeiten gemessen werden. Dies ist das Vorgehen der Pagespeedmessung bei Webanalysetools wie Google Analytics. Größere Stichprobenmengen sind für Änderungen und Relaunches gut verwertbar, da die strikte Kontrolle der Umgebungsfaktoren durch echte Nutzerdaten ersetzt wird.
Wichtig: Webanalysetools wie Google Analytics zeigen die realen Ladezeiten der User, zusammengesetzt nach Gerät, Verbindung, Standort etc. Es ist also keine Kontrolle notwendig, weil die Daten den tatsächlichen Zugriffen entsprechen. Daher ist die Populationsmessung einer Einzelstrichprobe immer vorzuziehen, wenn absolute Sekundenwerte interpretiert werden.
Aus Shopsicht ist es zielführend, die Messung nach Seitentyp zu gruppieren, da die zugrundeliegenden Aufrufketten sich teils stark unterscheiden. Daher ist ein Reporting nach Seitentyp neben derjenigen nach Gerät die wichtigste Auswertungsdimension. Für regelmäßige Messungen eignen sich die Pagespeedmetriken der Webanalysetools gut, da Seitentypwerte über Dimensionen auf Pageviewebene aggregierbar sind.
Fakt 6
Pagespeed-Tools: Einzeldiagnose ist nicht Reporting
Das ideale 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 Sequenzen von Ressourcenabfragen im Vordergrund, um Ursachen zu identifizieren. Eine gemessene Sekundenzahl wird erst valide, wenn Umgebungsfaktoren konstant gehalten werden, selbst dann ist kein Zuverlässigkeit gegeben: Meist sind Messstreuungen +/- 50% vom Durchschnitt der Regelmessung erkennbar, aufgrund der Faktoren in 4.
- Regelmäßiges Reporting: Hier steht die tägliche, detaillierte Sammlung von Ladezeiten im Vordergrund, ohne differenzierte Diagnostik und Ursachenprüfung. Es werden die realen Nutzerzeiten in der jeweiligen Gewichtung erfasst, was für absolute Messungen zu bevorzugen ist.
In dieser Zweiteilung der Zielsetzung ergibt sich folgende Gegenüberstellung der gängigen Pagespeed-Tools:
Tool | Vor (+) und Nachteile (-) |
| GT Metrix | + Detaillierte Diagnose mit Wasserfalldiagramm |
Webpagetest
| + Detaillierte Diagnose |
| Google Analytics | + Häufige Messung durch Stichprobe aus Tracking |
Fakt 7
Pagespeedindizes: "Nur 58 aus 100?!" Google's Tool misst keinen Pagespeed, sondern Best Practices
„Indizes sind als schnelle Orientierung oder Benchmark zu sehen, nicht als detaillierte Differentialdiagnose.“
Abbildung oben: Beispielergebnis aus Pagespeed Insights
Das bekannte Tool Google Pagespeed Insights verzichtet wegen oben genannter Faktoren auf absolute Sekundenmessungen und setzt im Kern auf drei Indexwerte bis zu 100 Punkten. Es werden auch konkrete Empfehlungen zur Optimierung der geladenen Dateien gegeben.
Neben oben genanntem Vorbehalt bezüglich Einmalmessungen und Zweifeln an der Toollegitimation ist bei Indizes zu beachten, dass sie bewusst Komplexität und Vielfalt vereinfachen. Es sind pauschale Empfehlungen – grundlegend richtig, aber vereinfacht und mit Vorsicht zu genießen. Manche Maßnahmen sind für bestimmte Shopsysteme oft nicht einfach realisierbar und ggf. ohne echten Mehrwert hinsichtlich der Teilmetriken.
Wichtig: Das Google Pagespeedtool misst Ladezeiten nur sehr rudimentär (oder gar nicht), wie auch Onpage.org konstatiert. Es quantifiziert strukturelle Abweichungen von einem (Google) Standard. Je mehr Abweichungen, desto geringer der Score. Score ist also nicht gleich Zeit. Das neuere Google-Tool TestMySite mit Sekundenmessungen wird in 9. diskutiert.
Fakt 8
Interpretation der Toolvorschläge: Listen sind einfach, Aufwand/Nutzen-Einschätzungen nicht
„Die Aufbereitung von Toolvorschlägen in Reports zeigt noch keine Expertise – erst die Evaluation und Priorisierung schafft eine Planungsgrundlage.“
Ob Webpagetest.org oder Google’s Pagespeedtool, die meisten Tools geben eine Liste von grob priorisierten Maßnahmen aus. Die Aufbereitung von Toolexports in Präsentationen unterstreicht noch keine Expertise im Bereich Pagespeed, da jede gut gemeinte Maßnahme auf Basis zweier Faktoren evaluiert werden muss:
1. Technische Sinnhaftigkeit einer Maßnahme ohne Nebeneffekte und Konflikte mit Architekturprinzipien des Frameworks, z.B. Inline vs. External CSS
2. Verhältnis Aufwand und Nutzen: d.h. Umsetzungsaufwand zu echter, absoluter Beschleunigung im Rahmen des verwendeten Frameworks. Hierfür sind einige diskussionswürdige Beispiele zu nennen, welche in solchen Tools immer angeführt werden:
- Renderblocking Dateien. jQuery, css-Dateien und Sonderschriften können auf der eigenen Domain gehostet werden, sind aber für den Seitenaufbau oft zwingend notwendig. Meist werden diese in 30 – 50ms geladen, sind also unkritisch.
- Kompression von 3rd-Party-Tags. Eine gzip-Kompression eines Criteo-Tags ist zwar sinnvoll, aber nicht vom Händler beeinflussbar.
- Ablaufdaten von 3rd-Party-Tags. Die Festlegung eines Ablaufdatums wird im HTTP Header angegeben und kann nur für selbst gehostete Dateien erfolgen, nicht für fremde Skripte wie Google Analytics.
Unterm Strich müssen Vorschläge von Systemarchitekten und Shopentwicklern mit Kenntnis der kompletten Anwendung evaluiert werden. Aus Erfahrung von norisk bringen nicht alle Maßnahmen eine erkennbare absolute Beschleunigung. Notwendig ist daher die erfahrungsbedingte, vorherige Priorisierung der Maßnahmen, um Entwicklingsressourcen effizient einzusetzen.
Fakt 9
Richtiges Benchmarking: 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 Indizes Vorlieb genommen werden, was als grobe Orientierung ausreichend ist. Folgende Faktoren sollten für die 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 daher nicht ressourceneffizient.
- Shopsystem. Bei Einsatz eines Frameworks schreibt dieses einen gewissen Rahmen vor. Ein Vergleich mit anderen Shops und Shopsystemen ist nicht ausgeschlossen, doch sollten Abweichungen immer im Rahmen der Systeme und Budgets gesehen werden.
norisk Benchmark - Server Response Time
Wie schnell ist wirklich schnell? Eigene Ladezeiten richtig einschätzen
Die Frage nach der Einschätzbarkeit eigener Werte wird in jedem Projekt gestellt. Google’s TestMySite Tool gibt als Best Practice für die Branche „Shopping“ (Online Shops) folgende Richtwerte an:
- 4,5 s Ladezeit
- 200 ms Server Response Time
Die Tests laufen standardisiert über ein Moto 4G Gerät, mit einem Chrome-Browser über eine durchschnittliche 3G-Verbindung, d.h. ~2Mbps down.
Testvorgehen
Für 10 Shops wurde je eine URL für jeden der fünf Seitentypen ausgewählt:Start – Kategorie – Marke – Suche – Details
Alle URLs wurden mit folgenden webpagetest-Parametern getestet:
- UserAgent. Amazon EC2 Instanz über Chrome.
- Verbindung. Kabel mit 5Mbps down.
- Standort. Deutschland.
- Anzahl. 3 Tests mit First view only, um Browsercaching zu vermeiden.
Ergebnisse
In der Tabelle unten sieht man die Übersicht der Serveresponsezeiten sowie die Durchschnittswerte pro Shop und pro Seitentyp. Diese können als realistische Best Practice-Werte für eigene Projekte dienen.
Typische Ursachen für die erkennbaren Unterschiede pro Seitentyp
- Startseite. Meist vollständig cachebar, hier ist ein Wert um 400 ms anzuvisieren.
- Kategorie und Marken. Diese erfordern komplexere Aufrufketten mit großen Artikelmengen, ein guter Best Practice liegt zwischen 500 – 700 ms.
- Details. Da sehr gut cachebar und wichtig für Google Shopping, ist unter 500ms ein realistischer Best-Case-Zielwert.
- Suche. Nicht immer im Cachingscope. Die Ladezeit ist stark abhängig davon, ob die Artikelinhalte über externe API generiert werden. Aus SEO-Sicht sind diese Seiten von geringerer Relevanz, weil meist von der Indexierung ausgeschlossen. Unter 1 Sekunde Ladezeit sollte für wichtige Suchen erreicht werden.
Der Google Richtwert von 200ms wird daher von vielen größeren Shops nicht erreicht. „myth busted“ sozusagen. Die vollständigen Testwerte stehen in diesem Google-Sheet zum Nachlesen bereit.
Fakt 13
HTTPS und HTTP/2 als neue Standards: Was bedeutet das konkret?
„Investieren Sie in HTTP/2 und HTTPS-by-Default. Nutzen Sie CDNs, falls dies aufgrund hoher internationaler Zugriffe sinnvoll ist.“
Bereits 28% der Top-Million Seiten nutzen mittlerweile HTTPS-by-default (Stand Ende Juni 2017), die verschlüsselte Client-Server-Verbindung wird damit zum 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 Bevorzugung durch Google durch.
Der HTTP/1.1 Standard stammt aus dem Jahr 1997 und lässt, neben anderen Nachteilen, nur 6 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 wirkt.
Diese TCP-Restriktion von HTTP/1.1 hat verstärkt zu Praktiken der Ressourcenoptimierung geführt, welche in HTTP/2 zukünftig obsolet werden:
- Domain-Sharding. Nutzung einer Subdomain, um alle statischen Inhalte von dort zu hosten, optional in Kombination mit einem CDN
- Image spriting. Nutzung von CSS, um viele Bilder in einer Datei zu konsolidieren.
- Konkatenierung von CSS/ JS. Konsolidierung vieler in eine CSS/JS Datei.
HTTP/2 verbreitet sich schnell
Der neue Standard HTTP/2 umgeht die obige Einschränkung durch sog. “Multiplexing”, welches vielfache HTTP Requests und Responses über die gleiche TCP-Connection zulässt. Im Juni 2017 unterstützten 15% aller Webseiten und 83% 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 maßgeblich voran: Neben dem eigenen Netzwerkprotokoll ALPN steht seit Ende 2015 das Gerücht im Raum, dass Chrome in Zukunft nur HTTP/2 unterstützen könnte.
Fakt 11
Metriken und Ursachen: Welche Maßnahme bringt welchen Effekt?
Mehr Hardware sorgt meist nicht für eine linear bessere Performance. Teilmetriken ermöglichen einen spezifischen Maßnahmenfokus.
Metrik | Ursachen & Maßnahmen |
Server | Application Stack: Loadbalancer, Serveranzahl und Leistung (App-Server & Web-Server und Datenbank), Programmiersprache, Caching-Server, Datenbankqueries, PreRendering & weitere Ende: HTML Datei wird serviert, Erstes Byte geladen |
Content | Asset Komprimierung: Können Bilder, CSS und JavaScript pro Seitentyp Asset Reduktion: Können Bilder über CSS Sprites oder CSS/JS in weniger Dateien konsolidiert werden? Browser-Caching: Sind alle eigenen Dateien mit sinnvollen Ablaufdaten versehen? Deferred Loading: Können Bilder über onload oder onscroll nachgeladen werden, um den initialen Pageload zu reduzieren? Ende: Seite ist “DOM-Ready” und bereit zur Interaktion |
Page | Marketingscripte oder asynchrones JavaScript, wie Trackingtools & Retargeting werden nachgeladen, diese führen weitere aus. Sind alle notwendig? Wie sind die Server-timeouts? Ende: Alle Dateien nachgeladen |
Merkregel für die Konzeption: Jedes Feature kostet!
Ein neues Feature, so gut gemeint und wunderschön es sein mag, kann schnell – und v.a. ungewollt – hart erkämpfte Ladezeitverbesserungen zunichte machen. Daher ist es elementar wichtig, bei allen Beteiligten ein Pagespeed-Bewusstsein in der Featurekonzeption zu erzeugen.
Einige praktische Beispiele, die kritisch für die Performance sein könnten, wenn alle Funktionalitäten direkt zum initialen Pageload bereit stehen müssen:
- AddToCart-Button auf Übersichtsseiten
- Anzeige von Filialverfügbarkeiten (> 5) auf Detailseiten.
Wenn die notwendigen Abfragen asynchron gestaltet werden können, z.B. erst onclick, sind die Pagespeed-Auswirkungen sehr viel geringer. Zielführend sind daher folgende Fragen vor der Umsetzung größerer Features:
- Wie komplex ist die Abfragelogik? Sind die Abfragen cachebar?
- Muss die Funktion direkt beim intialen Pageload bereitstehen?
- Wurde das Feature A/B getestet? Wie ist der erwartete CR-Uplift?
- Wie ist der CR-Uplift im Verhältnis zur möglichen Verlangsamung der Seiten?
Fakt 13
Fakt 13
„Gute Cachingmechanismen auf Serverseite können die Ladezeiten von Übersichts- und Artikelseiten halbieren.“
Clientseitiges Caching umfasst die Speicherung (vorrangig statischer) Dateien, z.B. Bilder mit festgelegtem Ablaufdatum auf Browserseite.
Das Caching auf Serverseite regelt den schnellen Aufruf von Seitenteilen, Komponenten wie Datenbankabfragen, Objekten oder kompletten Seiten wie Artikeldetails. Die nachfolgende Tabelle zeigt alternative Caching-Vorgehensweisen mit ihren Vor- und Nachteilen.
Im OXID-Kontext hat sich AppServer-Caching bewährt, da es Schnelligkeit und Flexibilität zugleich erlaubt. Mittels eigener „Cache-warming“ Technologie ist es norisk möglich, alle Seiten (Home, Kategorien, Marken und Details) proaktiv im Cache zu halten – was Ladezeiten um bis zu 50% senkt!
Proaktives Caching war der größte singuläre Hebel in unseren bisherigen Projekten, daher haben wir uns einer Variation HipHop-Klassiker’s „Cash rules everything…“ bedient. Ergänzend ist Server Side Rendering möglich – dieser Ansatz ist jedoch stärker bei statischen Seiten, React.js-basierten Anwendungen oder Eigenentwicklungen, wie Globetrotter, zu finden.
| Caching in | Vor- (+) und Nachteile (-) |
| Webserver | + Schnellere Auslieferung |
| Application Server | + Cacheeinträge direkt im Server, keine Netzwerklatenz |
| Eigener Caching-Server | + Schnellerer Setup durch Standards |
Fakt 13
Das Projektteam: Interdisziplinär - Shopagentur, Hoster & Webanalysten
„Um nachhaltig schneller zu werden, müssen Know-How und Prozesse aus Hosting, Shoptechnologie, SEO und Webanalyse gut verzahnt werden.“
Ein Projekt zur Ladezeitoptimierung für Shops sollte von einem interdisziplinären Team aus Shopentwicklern, Hostingverantwortlichen und Datenanalysten vorgenommen werden. Onlinemarketing Experten liefern aus dem Bereich Onpage SEO konkrete Maßnahmen aus Toolsicht, überprüfen den Ist-Zustand nach Auslieferung und stellen Pagespeedreports in Form von Dashboards und Alerts bereit.
Ergänzend kann ein auf Pagespeed spezialisierter Dienstleister wirken, welcher als Sparringspartner eine unabhängige Einschätzung bei größeren Optimierungsprojekten liefert. Diese Perspektive ist wertvoll, um einen ganzheitlichen Ansatz von Architektur- bis Codereview-Ebene zu erarbeiten.
Fazit
Pagespeed muss Teil der E-Commerce-DNA werden
Pagespeedoptimierung erfordert ein Team mit Knowhow aus den Bereichen Full-Stack-Technologie, Datenanalyse und Projektmanagement. Eingespielte Prozesse und fertige Komponenten sind von enormem Vorteil, um effizient zur ersten messbaren Beschleunigung zu gelangen.
Pagespeedmaßnahmen sollten v.a. eines NICHT sein: abgeschlossen. Es sollte ein dauerhafter Prozess mit Verantwortlichen etabliert werden. Ähnlich einer datengetriebenen eCommerce-Philosophie sollte die Frage nach Performance jede Shopentscheidung durchdringen und kein Nachgedanke sein.
Passende Module können den Fortschritt zur optimalen Performance unterstützen. digitaldrang bietet für OXID Shops zwei passgenaue Lösungen zur Optimierung von Bildern und Cache an.