Content ist ‚king‘ – aber er glänzt nur dann, wenn er schnell ausgeliefert wird. Nutzer wenden sich schnell von langsamen Seiten ab – was Suchmaschinen wie Google verleitet, langsame Seiten weiter unten in die Liste zu packen. Nutzer bekommen, was sie wollen – nur bleibt auch guter Content wirkungslos, wenn in Sachen Geschwindigkeit nicht gearbeitet wird. Magento (speziell in Version 1) hat Nachhol-Bedarf in Sachen Geschwindigkeit. Magento 1 ist nach wie vor relevant – deshalb stellt dieser Artikel einen Ansatz vor, mit dem sich die mit PageSpeed gemessene (und wahrgenommene) Geschwindigkeit von Magento 1 Shops substanziell verbessern lässt.

Entscheidende Kennzahlen

Um die Geschwindigkeit des Seiten-Aufbaus objektiv zu bewerten bieten sich (vor allem) drei Kennzahlen an:

  • Time to First Byte (TTFB): Wie lange braucht der Server, um überhaupt zu antworten. Hier lässt sich mit Optimierungen im Backend sowie mit Caches (z.B. Varnish) arbeiten. Allerdings ist das nicht der Fokus des Artikels.
  • Time to first render: Wann ist das erste Mal Inhalt sichtbar.
  • Time to interactive: Es stehen alle Funktionen im Shop bereit, es kann z.B. auf „bestellen“ geklickt werden.

Entscheidend für die wahrgenommene User Experience (UX) (und für den PageSpeed von Google) ist die Time to first render, also wann der Inhalt das erste Mal sichtbar ist. Dem gegenüber ist die Time to interactive nachgelagert (so lange es im Rahmen bleibt). Die Überlegung hierzu ist: Jeder Nutzer braucht ohnehin ein bis zwei Sekunden, um sich zu orientieren. In der Zeit gibt es keine Scrolls und auch keine Klicks – Interaktivität ist also ohnehin nicht verlangt. Anders herum werden Seiten als schlecht wahrgenommen, die sehr lange nur weiß sind, auch wenn ihre Time to interactive im Vergleich sogar besser ist.

Die folgenden drei Abbildungen verdeutlichen das Prinzip:

bad - blank page

 

 

 

Eine Seite, auf der man nichts sieht ist verstörend,…

 

 

 

better - Sanduhr

 

 

 

 nur eine Sanduhr ist immerhin ein Lebenszeichen, aber nicht toll.

 

 

 

getting there - Bild und Sanduhr

 

 

 

Etwas zu sehen (und mit lesen anfangen können) ist das worauf es hinzuarbeiten gilt –

sowohl für Nutzer wie auch für Suchmaschinen.

 

 

Problem bei Magento 1

Leider macht Magento 1 genau das Gegenteil: Die Seite wird erst angezeigt, wenn ein Großteil der Scripts fertig ist – so lange sieht man… nichts. Es besteht also keine gute UX und kein guter PageSpeed Score. Das Verhalten lässt sich per se so auch nicht einfach umkonfigurieren oder anderweitig „schnell“ lösen: Viele Module binden eigene Scripts synchron ein oder rendern Inline-Scripts (die immer synchron sind). Oft bauen die Scripts aufeinander auf – so dass die Wahl bleibt, entweder sehr viele Module umzubauen (keine echte Option, der erste Wurf ist viel Aufwand, die Stabilisierung noch schlimmer) – oder auf die Optimierung zu verzichten.
Oder… einen anderen Ansatz zu verwenden.

Unser Ansatz: Umfassendes PostProcessing

Lemundo hat ein Magento1-Modul entwickelt, das sich als Post-Prozessor nach dem Rendering von Blöcken sowie Layouts und vor die Auslieferung des Moduls hängt: Dabei werden alle Script-Tags umgeschrieben (egal ob per se synchron oder nicht). Hier das Prinzip:

Aus

<script src=“script.js“></script>

wird
<span data-xscript data-src=“script.js“></span>
und aus
<script>/* some JS */</script>
wird
<span data-xscript=“<encoded script>“></span>

Vor </body>  wird (ohne Umschreiben) ein Script gehangen, dass

  • alle <span data-xscript in Reihenfolge der DOM durchgeht.
  • Script Tags erstellt und an die gleiche Stelle im DOM einhängt.
  • auf Fertigstellung des Scripts wartet, bevor das nächste angefasst wird (für nicht-async).
  • document.write-Ausgaben an die richtige Stelle packt.
  • DOM Lifecycle events (z.B. onload) abermals feuert.

Aus Sicht der Scripts hat sich nichts geändert: Sie werden in der richtigen Reihenfolge ausgeführt (finden auch alle Vorgänger-Scripts sauber vor). Allerdings ist die Ausführung komplett asyncron. Bisweilen wird defer statt async vorgeschlagen – was auf das gleiche hinausläuft: Bestehende Module müssen durch post-processing angepasst werden.

Für den Nutzer ändert sich Gewaltiges: Die Seite rendert erheblich früher, die UX wird substanziell verbessert und der (sonst gleiche) Shop fühlt sich angenehmer an. Auch PageSpeed honoriert die Verbesserung. Ein Umschreiben von Dutzenden oder mehr Modulen entfällt.

Erfahrungswerte soweit

Die Einführung unseres AsyncJS Moduls verbessert den PageSpeed Score signifikant – vor allem den (für das Ranking bei den meisten Seiten mittlerweile entscheidenden) mobilen Score – Stichwort Mobile First Index. Eine gute PageSpeed-Bewertung ist mit Magento 1 also sehr wohl möglich. Eine Verbesserung um 30 und mehr Punkte konnten wir bisher realisieren.

Allerdings hängt der konkrete Erfolg vom Shop ab: Es gibt auch Situationen mit weniger Verbesserung – oder das Potenzial für noch mehr.

Probieren Sie‘s aus

Sprechen Sie uns an, um AsyncJS in Ihren Shop zu integrieren und neue Chancen durch bessere UX und besseres Ranking zu realisieren. Als Agentur hatten wir die Chance, den Ansatz in Shops zu stabilisieren und haben bisher sehr gute Erfahrungen gemacht.

VN:F [1.9.17_1161]
Bewertung
Bewertung: 5.0/5 (1 Bewertung abgegeben)
Magento Commerce PageSpeed-Optimierung, 5.0 von 5 basierend auf 1 Bewertung(en)