« Zum Blog

Shopware Ladezeiten Challenge Teil II - Analyse der Webseite

Der eigentlich erste Teil der Shopware Ladezeiten Challenge

Die Shopware Ladezeiten Challenge ist mein Projekt für das Jahr 2017. Das Ziel ist es die Ladezeit meiner Shopware Installation auf 2 Sekunden in 3G Netzwerken zu drücken. Das Nebenziel ist es einen Google PageSpeed Wert von 90 für Mobil und Desktop zu erreichen. Testen werde ich das Ergebnis in den Chrome Developer Tools, da man dort die Internetverbindung drosseln und 3G somit simulieren kann.

Hier geht es zu den anderen Blogposts der Shopware Ladezeiten Challenge:

Letzte Woche habe ich hier zum ersten Mal über meine Shopware Ladezeiten Challenge für 2017 gesprieben. Heute möchte ich die anfängliche Analyse nachholen, die ich letzte Woche ausgelassen habe. Dabei widme ich mich diesen Themen:

Die Performance Messung in den Firefox/Chrome Developer Tools

Mein erste Frage ist: Wie schnell ist meine Seite aktuell? Um dies herauszufinden, kann ich mit jedem gängigen Browser eine Messung der Ladezeiten durchführen. Ich nutze dazu immer Firefox und Chrome. Dazu muss man in den Entwicklertools den Tab Netzwerk öffnen. (Falls Du nicht weißt, wie Du die Entwicklertools öffnest, findest Du eine Anleitung in meinem vorherigen Blogpost bei dem Expires Header.)

Ich werde hier immer die Chrome Screenshots zeigen. Die Schritte sind im Firefox aber dieselben. Kommen wir zu einer kurzen Einführung in die Entwicklertools.

Nach dem erneuten Laden der Seite kann ich nun alle Anfragen an den Server sehen. Da Webseiten in verschiedene Elemente unterteilt sind, muss ein Browser jedes einzelne Element laden. Für die einzelnen Elemente gibt es daher eine Anfrage an den Server, um die Daten herunterzuladen.

Geht wir nun auf die einzelnen Elemente ein. Das Wichtigste steht hier in der untersten Zeile.

Die Aussage ist, dass meine Webseite nach 1,22 Sekunden geladen ist. Alle Anfragen wurden also vom Server innerhalb von 1,22 Sekunden beantwortet und auch heruntergeladen. Das ist ein Ergebnis der richtigen Konfiguration, die ich schon vorgenommen habe. (Wie Du Deine Installation korrekt konfigurierst, kann Du hier nachschauen). Ohne die Konfiguration und aufgewärmten Cache würde das Ergebnis so aussehen:

Zudem ist hier noch nicht der gesamte Inhalt geladen. Darauf gehe ich später ein. Die eigentliche Ladezeit liegt hier bei ca. 16 Sekunden.

Als nächstes möchte ich auf das Wasserfall-Diagramm eingehen.

Chrome zeigt hier, wie die Webseite geladen wird. Um den Umfang dieses Posts nicht zu sprengen werde ich mich hier auf wenige Punkte konzentrieren. Der erste Punkt ist, dass die Elemente nicht unbedingt in der Reihenfolge geladen werden, in der sie im HTML auftauchen.

Der weiße, durchsichtige Balken zeigt an, wie lange Chrome von dem Element wusste, bevor das Element angefragt wurde. Die JavaScript Datei in der erste Zeile wurde sofort vom Server angefragt und heruntergeladen. Das Bild allerdings wurde nicht direkt heruntergeladen.

Dieser Umstand ist der Art und Weise wie Browser arbeiten geschuldet. Um die ersten Elemente der Webseite anzuzeigen, benötigt der Browser folgende Elemente: Das HTML (der Inhalt), alle CSS-Dateien im Head (das Design), alle JavaScript Dateien im Head (die “aktiven Elemente”) und alle Schriftarten. Daher werden Bilder nicht sofort geladen, sondern der Browser lädt erst diese Elemente, damit er schnellst möglich die ersten Elemente anzeigen kann. Der wichtige Punkt ist, dass so lange diese Elemente nicht geladen sind, der Bildschirm weiß bleibt. Für mich bedeutet das, dass ich diese Resourcen also so klein wie möglich lassen möchte, damit die Webseite schnell angezeigt wird.

Das Gute an dieser Ansicht ist, dass man hier schnell die Anfragen ausmachen kann, die die längsten Antwortzeiten haben. Damit kann man sich auf die Anfragen konzentrieren, bei denen eine Beschleunigung den größten Effekt hat. Hier in diesem Beispiel ist es dieser Request mit knapp 500 Milisekunden an Länge.

Diese Anfrage werde ich allerdings vernachlässigen. Shopware lädt die HTML Seite aus dem Cache. Diese Anfrage soll lediglich prüfen, ob es wirklich noch keine neuere Version der Seite gibt. Damit läuft sie im Hintergrund ab und hat keine Auswirkung auf die Ladezeit der Seite.

Die Analyse von Webpage Test

Das zweite Tool zum Messen der Performance ist der Webpage Test (http://www.webpagetest.org/). Dieses Tool lädt die Webseite in einen Browser und stellt später alle ablaufenden Prozesse dar. Damit ermöglicht es Webentwicklern eine detaillierte Analyse der Webseite als die Entwicklertools der Browser. Ein interessantes Features ist zum Beispiel der Film Strip, der den Prozess des Ladens zeigt.

Heute möchte ich zwei Dinge hervorheben. Zuerst wieder das Wasserfall-Diagramm.

Zusätzlich zu den Informationen aus dem Browser zeigt es uns die CPU Auslastung, die Netzwerk Auslastung und was der Main Thread des Browsers gerade macht. Zudem bietet das Diagramm eine bessere Übersicht, da alle Anfragen auf einer Seite angezeigt werden.

In dem Bild ist eine einzelne Anfrage rot umrandet. Nachdem diese Anfrage beantwortet wurde, fängt der Browser wieder an Bilder herunterzuladen. Dies ist ein Hinweis, dass hier weiteres HTML herunter geladen und in die Seite eingefügt wird.

In Shopware gibt es die Einkaufswelten und diese produzieren genau solche Anfragen. Dabei wird erst das Grundgerüst der Seite geladen. Das sieht in der mobilen Ansicht so aus:

Das HTML der Einkaufswelt wird in einer anderen Anfrage geladen, in die Seite gespeist und löst dann das Laden der Bilder aus. Das ist auch der Grund, weshalb die 7 Sekunden Load in meiner nicht optimierten Seite nicht stimmen. Chrome ist leider nicht in der Lage zu erkennen, dass diese Anfragen zum Laden der Seite gehören und lässt sie damit aus. Der Webpage Test hingegen gibt an, wann die Webseite visuell vollständig (Visually Complete) ist, um solche Anfragen zu berücksichtigen.

Die zweite Eigenschaft, die ich hervorheben möchte ist die Connection View. Diese zeigt wie viele Verbindungen der Browser zu der Webseite aufbaut und wie diese ausgelastet sind. Ein Browser stellt immer nur eine begrenzte Anzahl an Verbindungen zu einer Domain her. Beim IE (im Screenshot zu sehen) sind es 6 Verbindungen.

In dem Bild wird klar, dass die Schriftarten (rot) das Laden der HTML Anfragen (hellblau) blockieren. Da der Browser die Schriftarten zum ersten Rendern der Seite benötigt, macht das auch Sinn. In diesen HTML Anfragen liegt leider unsere Einkaufswelt. Hier gibt es durchaus Optimierungspotenziale. Das ist aber der Stoff für einen anderen Blogpost.

Der Google PageSpeed Wert

Zu guter Letzt möchte ich mich meinem letzten Tool widmen: dem Google PageSpeed Wert.

Die wichtigen Vorschläge für meine Seite sind die Above the Fold Optimierung und die Optimierung der Bilder. Worum es bei der Above the Fold Optimierung geht, kannst in meinen Tipps erfahren. Dazu gibt es nicht viel zu sagen, die muss ich machen. Auch das ist wieder ein Thema für einen weiteren Blogpost. Genauso müssen die Bilder optimiert werden. (Das ist übrigens sehr ärgerlich für mich, da ich ein Plugin dafür gekauft habe.)

Kommen wir nun zu den letzten beiden Vorschlägen. Sichtbare Inhalte priorisieren spielt wieder in die Einkaufsweltproblematik. Was Google mir mit diesem Punkt sagen möchte ist, dass in der ersten HTML Anfrage nur wenig Inhalt ist. Logisch, die erste Anfrage sendet nur das Grundgerüst, der Inhalt wird nachgeladen.

Dieser Punkt nervt mich zugegebener Maßen sehr. Das Problem ist nicht unbedingt der Google PageSpeed Wert, sondern die generelle Problematik. Die Webseite ist langsamer, weil der Inhalt nachgeladen werden muss. Dabei wird nicht nur die Zeit verlängert in der mein Nutzer keinen Inhalt sieht, sondern auch das Laden der Bilder für den Inhalt blockiert (Der Browser weiß ja noch nicht welche Bilder er herunterladen soll, wie soll er da die Anfragen stellen.) Übertroffen wird dies aber nur durch den Fakt, dass der Browser deswegen die Bilder in dem Footer zuerst abarbeitet, da er sie zuerst im HTML gefunden hat. Dabei sieht der Nutzer den Footer noch nicht einmal. Dieses Problem zu beheben, bedeutet allerdings einen tiefen Eingriff in Shopware. Ich bin mir zugegebener Maßen noch nicht sicher, wie ich das Problem löse.

Browser-Caching nutzen bezieht sich nur auf das Google Analytics Script. Das habe ich nicht in der Hand und kann es daher auch nicht optimieren.

Zu guter Letzt noch eine Anmerkung: Früher wurde mir noch HTML reduzieren als Vorschlag angezeigt. Das habe aber mit meinem WOTipps HTML reduzieren und komprimieren Plugin gelöst.

Zusammenfassung

In diesem Ausschnitt meiner Analyse habe ich die folgenden 4 Punkte zur Optimierung gefunden:

Ich glaube, dass ich damit schon auf einem sehr guten Weg bin, um meine Ziele zu erreichen.

Wenn Dir dieser Beitrag gefallen hat, komm doch nächste Woche für den Nächsten vorbei.

 

« Zum Blog