E-Commerce: Die Wahrnehmung der Website-Geschwindigkeit macht den Unterschied

Wir alle wissen, dass die Website-Geschwindigkeit einen großen Unterschied für die Konversionsrate und Klebrigkeit einer E-Commerce-Website machen kann.

In einer Fallstudie von SOASTA wurde behauptet, dass die Verbesserung der Ladegeschwindigkeit mobiler Seiten die Konversionsrate um über 25 % erhöht hat. In seinem ständigen Bestreben, den Benutzer an die erste Stelle zu setzen, ist Jeff Bezos, Gründer und CEO von Amazon, bekanntermaßen besessen von der Seitenladegeschwindigkeit und treibt seine Mitarbeiter ständig dazu an, die Seitengeschwindigkeit der Amazon-Website zu reduzieren.

Die zunehmende mobile Dominanz hat den Bedarf an schnelleren Seitenladegeschwindigkeiten verstärkt, da Benutzer Websites häufig mit langsameren Verbindungen durchsuchen.

Es gibt viele Tools, mit denen Sie die Geschwindigkeit von Webseiten wie Yslow oder Google Pagespeed Insights verbessern können, und es gibt verschiedene Best Practices wie CSS- und JS-Minimierung und -Zusammenführung, Verwendung von CSS-Sprites und Minimierung von Netzwerkanforderungen Ein Front-End-Entwickler sollte folgen, um sicherzustellen, dass die Seitengeschwindigkeit maximiert wird.

Das Problem, das wir haben, ist, dass Sie, sobald Sie die standardmäßigen Best Practices befolgt und die großen Gewinne realisiert haben, bald feststellen werden, dass sich die Bemühungen zur Verbesserung der allgemeinen Seitengeschwindigkeit verringern.

Sie können viel Zeit damit verbringen, immer kleinere inkrementelle Verbesserungen vorzunehmen, und dies wird ein kostspieliger und zeitaufwändiger Prozess sein. Frontend-Entwickler mit den notwendigen Fähigkeiten und Erfahrungen, um auf diesem Niveau zu arbeiten, sind überraschend rar und teuer.

Es gibt einige Dinge, die Sie nicht kontrollieren können, wie z. B. die Netzwerklatenz oder die Geschwindigkeit der mobilen Verbindung, und daher gibt es eine Grenze für das, was mit der Rohseitengeschwindigkeit erreicht werden kann. Bei einer 3G-Verbindung werden irgendwo zwischen 600 ms und 1 s durch obligatorische Netzwerk-Overheads verbraucht, gegen die Sie nichts unternehmen können. Ausgehend von einer gewünschten Seitenladezeit von 2s haben wir nur 1s zum Spielen. Das ist nicht sehr viel.

Es lässt sich nicht leugnen, dass die Seitengeschwindigkeit sehr wichtig ist, und alle Entwickler sollten mindestens die standardmäßigen Best Practices befolgen.

In diesem Artikel wird jedoch nicht erläutert, wie Sie das Laden Ihrer Seite beschleunigen können. Es gibt viele Artikel darüber und es ist alles ein bisschen techie.

Dieser Artikel konzentriert sich auf die Wahrnehmung der Seitengeschwindigkeit.
Was ist wichtiger: Wie schnell lädt die Seite oder wie schnell lädt der Nutzer?

Sicherlich ist die Wahrnehmung das Wichtigste für den Benutzer.

Website-Geschwindigkeit: Erste Eindrücke

Konzentrieren wir uns auf die Startseite Ihrer Website. Es enthält wahrscheinlich eine Top-Navigation, eine Suchleiste, ein Hero-Banner, vielleicht Links zu Schlüsselkategorien, ein Karussell und einige Inhalte. Homepages sind in der Regel ziemlich inhaltslastig und das schnelle Laden all dieser Inhalte auf einer mobilen Verbindung wird eine große Herausforderung sein.

Der Schlüssel hier ist, das Laden kritischer Inhalte zuerst und vor anderen Inhalten zu priorisieren – geben Sie dem Benutzer so schnell wie möglich etwas Wichtiges zu sehen.

Während diese kritischen Informationen verarbeitet werden, können Sie mit dem Laden der nächsten Inhaltsebene beginnen.

Auf einem mobilen Gerät beginnt ein Großteil des Inhalts unterhalb der Falte und sollte daher nach den Inhalten oberhalb der Falte geladen werden. Es ist gängige Praxis, JavaScript zusammenzuführen und zu minimieren. Dies wird normalerweise als bewährte Methode angesehen, kann Sie jedoch daran hindern, dem Laden von kritischem JavaScript Vorrang vor weniger kritischem Code einzuräumen. Stattdessen könnten Sie erwägen, Ihr minimiertes und zusammengeführtes JavaScript aufzuteilen und es nach Bedarf nach und nach zu laden. Es ist nicht erforderlich, das für die Suche erforderliche JavaScript zu laden, bevor Sie überhaupt das Suchfeld laden. Benutzer werden mindestens ein paar Sekunden nach dem Laden einer Seite keine Zeichen in das Suchfeld eingeben.

Schauen wir uns eine Seite an, die das sehr gut macht. Amazon hat die Lieferung von Assets und Inhalten aufgeteilt, um sicherzustellen, dass der Benutzer so schnell wie möglich mit kritischen Inhalten versorgt wird, und lädt Assets dann nach und nach in der Reihenfolge ihrer Priorität.

Dieser Test wurde auf einem iPhone 6-Simulator mit einer guten 3G-Verbindung und deaktiviertem Caching durchgeführt. Nachdem die Seite ursprünglich geladen wurde, habe ich eine harte Aktualisierung initiiert.

In etwas mehr als 600 ms beginne ich etwas mit meinem Namen im Header zu laden. Sie werden auch feststellen, dass nur 6 Netzwerkaufrufe getätigt und 5 Assets geladen wurden (3 CSS-Dateien und 2 Bilder).

Nur 50 ms später sehe ich jetzt Schlüsselkomponenten des Headers sowie das Lead-Helden-Banner. Ich habe bereits die Wahrnehmung von Geschwindigkeit, da mir wichtige Inhalte sehr schnell geliefert werden und meine Augen und mein Gehirn etwas zu verarbeiten haben, während zusätzliche Inhalte geladen werden.

Nach nur 1 Sekunde ist die Hauptnavigation geladen. Sie werden feststellen, dass zu diesem Zeitpunkt keine Bildlaufleiste sichtbar ist. Das bedeutet, dass derzeit kein Inhalt unterhalb der Falte vorhanden ist. Es wurde keine kostbare Zeit verschwendet, um diesen Inhalt zu laden, den der Benutzer nicht sehen kann. Sie werden auch feststellen, dass bisher nur 13 Anfragen gestellt wurden.

In knapp 2 Sekunden habe ich jetzt einen neuen Abschnitt mit wichtigen Inhalten.

Ich nehme jetzt an, dass die Seite in weniger als 3 Sekunden vollständig geladen wurde, während die Seite tatsächlich knapp 5 Sekunden brauchte, um vollständig geladen zu werden. Dies deutet darauf hin, dass ich die Seite als vollständig geladen wahrnehme, obwohl sie tatsächlich nur zu 60% geladen ist.

Der tatsächliche Zeitpunkt der Bereitstellung von Inhalten variiert von Person zu Person, aber dies zeigt sehr deutlich, wie Amazon das Laden mobiler Inhalte priorisiert, um sicherzustellen, dass kritische Inhalte so schnell wie möglich geladen werden und dass die Benutzer die Website so wahrnehmen, als würde sie sehr schnell laden.

Schauen wir uns nun eine Website an, die dies nicht so gut macht. Dieser Test wurde mit genau den gleichen Tools und der gleichen Netzwerkgeschwindigkeit wie der vorherige Amazon-Test durchgeführt. Während die Website von Charles Tyrwhitt einige Inhalte priorisiert, gibt es noch viel mehr, was getan werden könnte, um der Optimierung von Amazon nahe zu kommen.

Ich sehe fast 7,5 Sekunden lang keinen Inhalt. Ich habe sofort den Eindruck, dass diese Seite auf meinem Mobilgerät langsam ist. Obwohl die Website sowohl den Header-Inhalt als auch ein Hero-Banner priorisiert, können Sie sehen, dass bis zu diesem Zeitpunkt über 90 Anfragen gestellt wurden, und wie ich die Bildlaufleiste sehen kann, ist klar, dass der Inhalt unter der Falte geladen worden sein muss.

Nach 8,5 Sekunden sehe ich, dass ein Karussell zu laden beginnt. Die Anzahl der Anfragen hat sich nicht verändert, was darauf hindeutet, dass der Großteil der inhaltsbezogenen Anfragen gleich zu Beginn beim Laden der Seite gestellt wird.

Erst nach fast 22 Sekunden merke ich, dass die Seite nun vollständig geladen ist. Das vollständige Laden der Seite dauerte tatsächlich insgesamt 28,4 Sekunden. Dies deutet darauf hin, dass ich wahrnehme, dass die Seite vollständig geladen wurde, obwohl sie tatsächlich zu 77 % geladen war.

Es ist leicht, den deutlichen Unterschied zwischen den beiden Erfahrungen zu erkennen. Während die mobile Amazon-Homepage erheblich schneller geladen wird als die Charles Tyrwhitt-Homepage, wurden Anstrengungen unternommen, um sicherzustellen, dass die Benutzer wahrnehmen, dass sie noch schneller ist. Der Benutzer beginnt innerhalb von 12,5 % der gesamten Seitenladezeit zu sehen, dass etwas geladen wird, während Benutzer der Charles Tyrwhitt-Website nur innerhalb von 26 % der gesamten Seitenladezeit sehen, dass etwas passiert. Die Amazon-Homepage hat 6 Netzwerkanfragen gestellt, bevor der Benutzer den Fortschritt sieht, während die Charles Tyrwhitt-Homepage 90 Anfragen gestellt hat.

Dies soll Charles Tyrwhitt nicht übermäßig kritisch gegenüberstehen, da sie in der Art und Weise, wie sie ihre Website aufgebaut haben, keineswegs einzigartig sind. Die anerkannte bewährte Praxis wurde in einer Reihe von Bereichen befolgt, aber es scheint, dass noch viel mehr getan werden könnte, um die Wahrnehmung von Geschwindigkeit sowie die tatsächliche Geschwindigkeit zu verbessern.

Verbessern Sie die Website-Geschwindigkeit, indem Sie CSS priorisieren

Es ist ziemlich üblich, dass Front-End-Entwickler den Großteil des CSS einer Website in einer Handvoll Dateien ablegen und immer externes statt Inline-CSS verwenden. Das dadurch verursachte Problem besteht darin, dass eine große CSS-Datei geladen werden muss, bevor einem Benutzer Inhalte angezeigt werden können.

Eine Lösung hierfür besteht darin, Ihre CSS-Dateien aufzuteilen und sie nacheinander mit den kritischen Inhalten zu laden. Wenn wir uns das Beispiel von Amazon ansehen, laden sie eine CSS-Datei, die nur 6,5 KB groß ist, als eine ihrer ersten 6 Anfragen. Diese Datei enthält das CSS, das zum Gestalten der kritischen Inhalte auf ihrer Homepage erforderlich ist. Tatsächlich liegt die Gesamtgröße aller CSS-Dateien, die angefordert werden, bevor der Benutzer Inhalte auf der mobilen Amazon-Homepage sieht, unter 40.000, während sie auf der Charles Tyrwhitt-Homepage über 500.000 beträgt.

Diese Vorgehensweise ermöglicht es Ihnen, dem Benutzer wichtige Inhalte sehr schnell bereitzustellen, und trägt dazu bei, die Wahrnehmung von Geschwindigkeit zu verstärken.

Machen Sie dasselbe mit JavaScript

Neben der Priorisierung von CSS sollten Sie überlegen, wie Sie dies auch mit JavaScript tun. Fast alle E-Commerce-Websites sind stark auf JavaScript angewiesen, um zu funktionieren. Dies ist in Ordnung, solange JavaScript das Laden kritischer Inhalte nicht blockiert. Wenn ich das Beispiel der Website von Charles Tyrwhitt noch einmal nehme und JavaScript in meinem Browser deaktiviere, sehe ich jetzt, dass Inhalte innerhalb von 4,5 Sekunden geladen werden. Dies ist eine massive Veränderung in meiner Wahrnehmung der Geschwindigkeit dieser Website, und das JavaScript, das vor dem kritischen Inhalt geladen wurde, hatte keinen Einfluss auf diesen Inhalt, und daher gibt es keinen Grund, warum das JavaScript nach diesem Inhalt nicht geladen werden konnte.

Es gibt viel, was Webentwickler von der Art und Weise lernen können, wie sich Websites wie Amazon auf die Wahrnehmung der Geschwindigkeit ihrer Website sowie auf die tatsächliche Geschwindigkeit konzentrieren. Obwohl ihre Website eindeutig sehr schnell ist, nehmen die Benutzer sie als noch schneller wahr, da sie der Anzeige von benutzerkritischen Inhalten Vorrang vor allem anderen einräumen.

Es wurde viel über die Auswirkungen gesprochen, die Geschwindigkeit auf Ihre Konversionsrate haben kann, und Einzelhändler sollten erwägen, in die Optimierung ihrer wahrgenommenen Website-Leistung zusammen mit der tatsächlichen Website-Geschwindigkeit zu investieren.