Magento 2-Geschwindigkeitsoptimierung: Untersuchungen beweisen, dass die Standardfunktionalität ausreicht

Einführung

Laut Statista soll die Zahl der Handynutzer weltweit im Jahr 2019 die Fünf-Milliarden-Grenze überschreiten. Dabei legt Google größten Wert auf die Ladegeschwindigkeit von Websites auf Mobilgeräten. Dieser Parameter beeinflusst zweifellos das Ranking der Suchergebnisse. Darüber hinaus erhöht die schnelle Ladezeit der Website die Conversion, da die Websites den Verlust stationärer Benutzer vermeiden können.

Im ersten Teil dieses Artikels werden wir versuchen herauszufinden und zu zeigen, ob es möglich ist, die Ladezeit der Magento 2-Seite mit Standardmitteln zu beschleunigen oder nicht, und vor allem zu definieren, wie effektiv diese Mittel sind.

Im zweiten Teil geben wir einen Einblick in die Wirksamkeit von Lösungen und Ansätzen von Drittanbietern.

Testumgebung

Alle Messungen werden in Chrome Audit mit der Einschränkung „For mobile device with simulation Fast 3G“ durchgeführt:

Im Review kommt Magento 2.3.1 ungefaltet im Docker-Container zum Einsatz. Dadurch können wir Ressourcen isolieren.

Wir werden die Leistung im Produktionsmodus mit dem vollständig aktivierten integrierten Cache messen.

Die Tests werden auf drei Site-Seiten durchgeführt: Haupt-, Produkt- und Kategorieseiten. Für jede dieser Seiten führen wir drei Audit-Prüfungen durch. Es wird ein durchschnittliches Testergebnis ausgewählt.

Da wir keine Lasttests durchführen werden – während die Seitenladezeit auf der Clientseite in einem Browser hauptsächlich in diesem Artikel behandelt wird – werden MySQL- und PHP-Versionen nicht angegeben. Nicht das absolute Ergebnis, sondern der Leistungsunterschied zwischen verschiedenen Konfigurationen wird für uns von Interesse sein.

Wie ist es möglich, die Seitenladezeit mit Standard-Magento- und Servermitteln zu beschleunigen?

Dies kann vor allem dadurch erreicht werden, dass entweder die Größe der gesendeten Daten oder die Anzahl der Anfragen reduziert wird. Lesen Sie weiter für detailliertere Einblicke.

Kapitel 1. Magento-Setup und Serverkonfiguration

Gzip

Wie aus der folgenden Tabelle ersichtlich ist, ist die erste und wichtigste Sache – Sie haben Recht, es hat keine Relevanz für die Magento-Einrichtung – die Komprimierung auf dem Server zu aktivieren. Das Datenvolumen ist der entscheidende Faktor für die Ladegeschwindigkeit in langsamen Mobilfunknetzen. Bei aktivierter Komprimierung wird eine Website viel schneller dargestellt . Der unvermeidliche Nachteil ist eine Erhöhung des Parameters First CPU Idle als Ergebnis des serverseitigen Entpackens.

Ohne Gzip:

Mit aktiviertem Gzip:

Minimieren Sie Js und CSS

Was ist, wenn wir versuchen, die Größe der übertragenen Daten noch weiter zu reduzieren? Lassen Sie uns zunächst Minify Js und Minify CSS aktivieren. Dann machen Sie einen Vergleich.

Alle optimierungsbezogenen Konfigurationen finden Sie unter Stores -> Configuration -> Developer:

Die Registerkarte ist ausschließlich im Entwicklermodus verfügbar. Stellen Sie im Produktionsmodus sicher, dass Sie zuerst in den Entwicklermodus wechseln, indem Sie den folgenden Befehl verwenden:

 > bin/magento deploy:mode:set developer

Dann können Sie den Entwicklerbereich sehen, die erforderlichen Konfigurationsänderungen vornehmen, den Cache löschen und wieder in den Produktionsmodus wechseln:

 > bin/magento deploy:mode:set production

Daraufhin findet die Bereitstellung statischer Inhalte statt.

Das Suffix min wird js/css-Dateien hinzugefügt:

Das Datenvolumen hat sich tatsächlich verringert! Für die Homepage wurde 1 Mb statt 1,3 Mb übertragen.

Wenn Sie denken, dass dies unsere Parameter um ein Drittel verbessert hat, liegen Sie falsch. Die Situation hat sich verbessert, aber nicht wesentlich.

Wir haben es immer wieder laufen lassen, aber die Ergebnisse waren stabil, dh trotz gewisser Verbesserungen standen sie in keinem Verhältnis zum Rückgang der übertragenen Datenmenge.

Zusammenführen von Js und Zusammenführen von CSS

Nun wäre es logisch anzunehmen, dass weitere Verbesserungen eher mit dem Rückgang der Anzahl der Anfragen als mit dem Datenvolumen zusammenhängen müssen.

Probieren wir es aus und aktivieren Merge Js- und Merge CSS-Konfigurationen.

Beachten Sie, dass Magento selbst diese Funktion als veraltet bezeichnet:

„Wir raten davon ab, veraltete Einstellungen wie das Zusammenführen von JS- und CSS-Dateien zu verwenden, da sie nur für synchron geladenes JS im HEAD-Abschnitt der Seite entwickelt wurden. Die Verwendung dieser Technik kann dazu führen, dass die Bündelung und die requireJS-Logik nicht korrekt funktionieren.'

Lassen Sie es uns dennoch versuchen:

Die Veränderungen in der Anzahl der Anfragen sind nicht beeindruckend, oder?

Obwohl Parameter wie „First Contentful Paint“ und „First Meaningful Paint“ verbessert wurden, gibt es sicherlich Raum für Verbesserungen.

JS-Paket

Lassen Sie uns die JS-Bundle-Technologie ausprobieren, bei der js-Dateien basierend auf einer festen Größe gebündelt werden. Dadurch können wir die Anzahl der Anfragen verwalten, während ein Gesamtdatenvolumen unverändert bleibt.

Die Ergebnisse sind überwältigend. Die Sache ist, dass der eingebaute Magento-Mechanismus js-Bundles für alle Seiten sammelt, dh praktisch alle js werden auf jeder Seite gesammelt. Dies wird zu einem starken Anstieg des Seitenvolumens führen.

Ja, Sie können bestimmte js-Dateien von Bundles ausschließen (einige davon sind standardmäßig ausgeschlossen). Sie müssen dies jedoch nicht für eine bestimmte Seite tun.

Magento empfiehlt auch nicht, Bundle JS im Produktionsmodus zu aktivieren. Scheint, als wäre es eine zweite Option, die verfügbar ist, aber sachlich – nicht wirklich.

Erweitertes JS-Bundle

Magento erkennt Schwierigkeiten mit Bundles JS an, bietet aber an, diese nicht selbst anzugehen. In der offiziellen Anleitung finden Sie ein Beispiel dafür, wie es möglich ist, nur die erforderlichen js-Dateien auf einer aktuellen Seite zu bündeln. Ja, das ist etwas schwieriger, als einen Parameter in der Config zu ändern. Für Advanced Bundle müssen Sie Nodejs, Require JS, Phantom JS verwenden. Das ist natürlich keine fertige Lösung. Aber nachdem wir den angebotenen Mechanismus getestet haben, werden wir eine Vorstellung davon haben, wie Advanced Bundle die Seitenladezeit aus theoretischer Sicht beschleunigen kann.

Der vorgeschlagene Mechanismus arbeitet im manuellen Modus und nicht innerhalb , sondern außerhalb des Frameworks. Die speziellen Tools analysieren js-Dateien, die auf Seiten geladen werden, und sammeln sie in einem Bundle, entweder einem allgemeinen oder einem spezifischen für den PageTYPE-Bundle.

Letztendlich werden die gesammelten Bundles in require js geschrieben und von diesem auf eine Seite geladen:

Auf jedem Seitentyp (natürlich für den ein Bündel gesammelt wurde) wird ein bestimmtes Bündel geladen. Dies wäre ein Beispiel für eine Startseite:

Es scheint, dass, nachdem wir die Anzahl der Anfragen reduziert haben, keine zusätzlichen Daten geladen werden und die Leistung deutlich steigen muss… Aber auch die für SEO kritische Zeit für First Contentful Paint und First Meaningful Paint hat sich dramatisch erhöht. Das macht Sinn. Bis die Bundle-Datei geladen ist, findet kein Tracking statt.

________________

Scheint, als hätten wir unser Bestes versucht, oder nicht? Ich denke, es ist höchste Zeit, weiterzumachen und aktuelle Technologien auszuprobieren.

HTTP/2

Lassen Sie uns Bundle JS in Magento deaktivieren und HTTP/2 auf dem Server aktivieren.
In unserem Fall ist es nur nginx. Wir haben ein paar Zeilen geändert – http2-Unterstützung für Port 443 hinzugefügt.

 listen 80; listen 443 ssl http2; server_name md201.local; ssl_certificate /etc/nginx/ssl-certificates/md201.local/localhost.crt; ssl_certificate_key /etc/nginx/ssl-certificates/md201.local/localhost.key;

Zum Testen in Chrome müssen wir das selbstsignierte Zertifikat zur Trusted Root Authority (in unserem Fall MacOS) hinzufügen.

So sieht die HTTP/2-Verbindung aus:

Dadurch haben sich ausnahmslos alle Parameter verbessert! Das liegt an den Features der HTTP/2-Technologie.

Verringerung der Zugriffsverzögerungen zur Beschleunigung der Seitenladezeit, insbesondere durch:

• Datenkomprimierung in HTTP-Headern,
• Einsatz von Puch-Technologien auf der Serverseite,
• fordert Beförderung an,
• Auflösung der Head-of-Line-HTTP 1.0/1.1-Protokollblockierung,
• Multiplexen zahlreicher Anfragen in einer TCP-Verbindung.

Mit HTTP/2 ist eine große Anzahl von Anfragen kein Problem, da keine TCP-Verbindung für jede Anfrage geöffnet wird.

HTTP/2 wird von aktuellen Versionen von nginx und Apache in den meisten aktuellen Browsern unterstützt: https://caniuse.com/#search=http2

In diesem Zusammenhang haben Sie vielleicht die folgende Frage: Was wäre, wenn wir Advanced JS Bundle und HTTP/2 kombinieren?

Theoretisch wird die Ladezeit der Seite nicht beschleunigt, da HTTP/2 keine wesentlichen Vorteile beim Laden großer Bundle-js-Dateien bietet. Aber um es sicher zu wissen, lassen Sie es uns überprüfen.

Wie wir sehen, verbessert die Verwendung von Advanced Bundle JS innerhalb einer HTTP/2-Verbindung die Geschwindigkeit nicht.

Ein Versuch, die Bündel fein abzustimmen, ist ein zeitraubender Prozess. Es erfordert, dass Bundles nach jedem Update von Magento oder einer Erweiterung eines Drittanbieters (die JS zum Frontend hinzufügt) neu generiert werden, sowie nach dem Hinzufügen neuer Produkttypen, die ihre spezifischen js verbinden oder die js anderer Produkte nicht verwenden Typen. Grundsätzlich gibt es noch mehr Nuancen zu beachten. Meiner Meinung nach wird die Umstellung auf Bundle JS keine signifikanten Ergebnisse bringen, wenn Sie die Möglichkeit haben, HTTP/2 zu verwenden.

Welche anderen Mittel zur Geschwindigkeitsoptimierung gibt es? Ist es möglich, die Seitenladezeit noch schneller zu machen?

_______________

Verschieben Sie den JS-Code an das Ende der Seite

Ehrlich gesagt hatten wir vor, diese Optimierungsmittel von Drittanbietern zu überprüfen, aber während dieser Artikel erstellt wurde, wurde Magento 2.3.2 veröffentlicht. Diese Funktion wurde der neuen Version hinzugefügt (und standardmäßig deaktiviert).

Wenn aktiviert, werden einige js-Dateien vom <head>-Abschnitt an das Ende von </body> übertragen, was theoretisch den Beginn der Website-Visualisierung beschleunigen sollte.

Das hatten wir am Anfang:

Hier ist, was wir haben, nachdem wir es aktiviert haben:

Um solche Tests durchzuführen, mussten wir unsere Magento-Version auf 2.3 aktualisieren. Die Menge und Größe der verbundenen Dateien wurden geändert. Daher können die Testergebnisse grob sein. Um zu verstehen, wie die Magento-Version selbst die Ergebnisse beeinflusst hat, haben wir zuerst die Versionen M2.3.1 und M2.3.2 mit der Kombination HTTP/2 + Minify JS/CSS verglichen – und die erhaltenen Ergebnisse waren praktisch gleich, was die Messunsicherheit nicht übersteigt.  

Wie wir sehen können, wurden First Contentful Paint und First Meaningful Paint in allen Fällen um 10–15 % verbessert.

Bei allen hier vorgestellten Möglichkeiten der Magento-Geschwindigkeitsoptimierung scheinen folgende Varianten die Nase vorn zu haben:

Gzip + JS/CSS minimieren + HTTP/2 + JS-Code an das Ende der Seite verschieben

Betrachten wir es als Ausgangspunkt und gehen weiter. Zuvor haben wir mit Konfigurationen herumgespielt, die ausschließlich JS/CSS berühren. Daher gibt es bestimmte Aspekte, die verbessert werden können.

HTML minimieren

Die Einrichtung ist hier zu finden:

HTML-Teil der Homepage ― 89 Kb vor und 88,7 nach HTML Minify / mit Komprimierung auf dem Server ― 12,2 gegenüber 12,1 Kb.

HTML-Teil der Kategorieseite ― 155 Kb vor und 100 nach HTML Minify / mit Komprimierung auf dem Server ― 16,8 gegenüber 15,2 Kb.

HTML-Teil der Produktseite ― 80 Kb vor und 67 nach HTML Minify / mit Komprimierung auf dem Server ― 15 gegenüber 14,1 Kb.

Da die Komprimierung auf der Serverseite verwendet wird, ist ein Unterschied von 1-2 Kb nicht kritisch und liegt innerhalb der Prüfungsnachteile.

Kapitel 2. Zusätzliche Werkzeuge

Erweiterungen von Drittanbietern: Minify/Merge JS/CSS/HTML | JS bündeln

In der Zwischenzeit macht es nicht viel Sinn, sich für JS/CSS/HTML-Lösungen von Drittanbietern zu entscheiden und JS zu bündeln. Selbst wenn Sie zusätzliche Komprimierungsergebnisse erzielen, werden diese im Frontend auf einen Anteil von einem Prozent begrenzt. Im Gegenzug erhalten Sie eine oder mehrere weitere Magento-Extensions im System. Die Tatsache ihres Vorhandenseins und des Betriebs ihrer Algorithmen erfordert zusätzliche Ressourcen und erhöht das Risiko eines Systemausfalls im Allgemeinen. Wenn Sie sich nicht sicher sind, ob der potenzielle Nutzen die damit verbundenen Risiken überwiegt, wird empfohlen, die Verwendung einzustellen .

Wenn Sie eine Lösung von Drittanbietern kennen, die die Ladegeschwindigkeit durch Komprimierung und Bündelung drastisch verbessert, empfehlen wir Ihnen, sie in den Kommentaren zu teilen oder uns direkt unter [email protected] zu informieren. Wir werden dem gerne nachgehen  

Versuchen wir nun, Verbesserungen mit Mitteln vorzunehmen, die in Magento standardmäßig nicht verfügbar sind.

Bildgröße verkleinern

Die Verwendung von Bildern im Web ist immer ein Kompromiss zwischen Qualität und Bilddateigröße.

Unser Hauptanliegen ist die Reduzierung der Bildgröße ohne Qualitätsverlust. Nun, mit der standardmäßigen Magento-Funktionalität ist es tatsächlich möglich, die Bildgröße zu verringern. Aber die Qualität der Bilder wird erheblich leiden.

Lassen Sie uns die Größe von Standardbildern verringern, die Magento basierend auf den Konfigurationen konvertiert und in der Größe geändert hat, dh wir interessieren uns hauptsächlich für Bilder, die sich in magento_root_directory/pub/media/catalog/product/cache befinden.

Magento-Konfigurationen finden Sie hier:

Versuchen wir zunächst, dies manuell zu tun und das Dienstprogramm jpegoptim zu verwenden. Mehrere Module, die darauf abzielen, Magento zu beschleunigen (einschließlich der kostenpflichtigen), werden von diesem Dienstprogramm unterstützt.

Keine Ergebnisse für Bilder aus dem Cache, es sei denn, wir verringern die Bildqualität:

Daran scheint etwas nicht zu stimmen. Zu Testzwecken haben wir es auf das Originalbild angewendet, das tatsächlich nicht auf der Seite angezeigt wird. Wir haben es geschafft, bestimmte Ergebnisse zu erzielen, wenn auch unbedeutende:

Wie wäre es mit automatisierten Lösungen?

Lassen Sie uns den folgenden kostenlosen Bildoptimierer ausprobieren: https://github.com/justbetter/magento2-image-optimizer.

Wir haben alle angebotenen Dienstprogramme installiert, die von der Erweiterung verwendet werden:

• JPEGOptim
• Option
• Pngquant 2
• SVGO
• Gifsicle

Die Bildkomprimierungseinstellungen wurden für JPEG auf 80 eingestellt. Dies entspricht den Standardeinstellungen von Magento. Dann haben wir die Optimierung für alle Medienverzeichnisse durchgeführt.

Die vollständige Größe des Medienverzeichnisses vor der Komprimierung beträgt 353 MB, nach ― 340,1 MB

Die Größe des Verzeichnisses media/catalog/product/cache beträgt 194,7 MB und hat sich nach der Komprimierung nicht geändert.

Wir haben festgestellt, dass die Lösungen bequem und nützlich sind, insbesondere wenn Sie die Bilder nicht fertig machen, bevor Sie sie auf Ihre Website hochladen.

Wenn es jedoch darum geht, die Gesamtbildgröße auf Produkt- und Kategorieseiten zu verringern, wurden keine signifikanten Verbesserungen erzielt.

Wahrscheinlich werden in Ihrem Fall hauptsächlich andere Bildformate verwendet. Daher könnten die Ergebnisse sogar noch aussagekräftiger sein.

Wir geben hier absichtlich keinen Überblick über das Webp-Bildformat, da Apple-Browser dieses Format nicht unterstützen: https://caniuse.com/#feat=webp.

____________________

In Ordnung, wenn wir die Bilddateigröße nicht wesentlich verringern können, versuchen wir, sie nur für den sichtbaren Bereich hochzuladen.

Lazy Loading-Bild

Lassen Sie uns die erste KOSTENLOSE Lösung von Drittanbietern ausprobieren, auf die wir stoßen – Magento 2 Lazy Loading.

Wie zuvor haben wir eine Prüfung der Produkt-, Kategorie- und Homepages durchgeführt.

Es wurden keine wesentlichen Änderungen erzielt. Die Schwankungen liegen innerhalb der Messunsicherheit.

Dies liegt wahrscheinlich daran, dass die Beispieldatenseiten recht dünn sind und sich alle Primärbilder direkt im sichtbaren Bereich befinden.

Produktbeschreibung enthält keine Bilder. Die Kategorie hat überhaupt keine Beschreibung.
Machen wir es am einfachsten und erhöhen einfach die Anzahl der Produkte (inklusive der Anzahl der Ladebilder) auf der Kategorieseite im Pager ― zuerst von 9 auf 30, dann bis auf 48 und listen die Ergebnisse auf.

Die Ergebnisse sind offensichtlich. Je größer (in Menge und Größe) Ihre Bilder im beim ersten Laden nicht sichtbaren Website-Bereich sind, desto größer sind die Vorteile. Das Feature ist vom Optimierungsstandpunkt sicherlich ein nützliches Feature, obwohl es gewisse Usability-Nachteile hat.

_________________

Anstelle von Schlussworten

Wir haben sowohl die Standardfunktionen von Magento als auch einige Lösungen von Drittanbietern, die eine Optimierung der Seitenladeleistung ermöglichen, im Überblick.

Trotz der Recherche fällt es uns schwer, eindeutige Schlussfolgerungen zu ziehen, da alle Websites einzigartig sind und ihre eigenen einzigartigen Besonderheiten haben. Daher besteht immer eine gewisse Wahrscheinlichkeit, dass Lösungen, die für eine Website funktionieren, keine Auswirkungen auf andere haben.

Die nützlichsten Funktionen, die einen sinnvollen Effekt haben, sind jedoch das standardmäßige Gzip von Magento + Minify JS/CSS + HTTP/2 + Image Lazy Loading

Über Bundle JS

Fortgeschrittene Versionen dieses Pakets von Erweiterungsentwicklern von Drittanbietern ermöglichen daher kaum eine signifikante Erhöhung der Ladegeschwindigkeit ohne zusätzliche personalisierte Site-Feinabstimmung.

Es gibt sicherlich noch mehr Mittel, die Sie ausprobieren können, um die Ladezeit zu verlängern. Viele von ihnen sind jedoch keine One-Size-Fits-All-Lösungen. Zum Beispiel spielt auch die Korrelation von Website-Besuchern aus verschiedenen Ländern auf der ganzen Welt und dem physischen Server/Server-Standort eine Rolle. Es ist sinnvoll, die Site auf einen Server zu übertragen, von dem aus die Datenübertragung für die Mehrheit der Site-Benutzer schneller ist / verwenden Sie CDN für statische Dateien. Wenn Website-Besucher hauptsächlich aus einer Region stammen, können Sie versuchen, statische Dateien mit Varnish zwischenzuspeichern: https://devdocs.magento.com/guides/v2.3/config-guide/varnish/config-varnish-magento.html# cache-statische-dateien.

Letztendlich ist die Verwendung der AMP-Technologie ein Mittel, das die Situation grundlegend ändert und Ihre Website auf mobilen Geräten maximal schnell macht.

PS-AMP

(https://amp.dev/about/websites)

Bei Handheld-Geräten gelangt ein Benutzer von Google SERP nicht zu Ihrer Website, sondern zu ihrer zwischengespeicherten Version, die auf Google-Servern gespeichert ist. Der anfängliche Ladevorgang wird blitzschnell sein. Solche Websites werden in den SERPs natürlich mit einem Blitz gekennzeichnet.

Diese Technologie ist nicht einfach und setzt voraus, dass nur eigene Amp-JS-Bibliotheken verwendet werden. Außerdem haben Sie die Möglichkeit, eine separate Seitenversion zu haben, die in keiner Weise mit Ihrem aktuellen Thema verbunden ist.

Dies kann eine schwierige Entscheidung sein. Einerseits geht es um verbesserte Ladegeschwindigkeit und Conversions. Andererseits gibt es Einschränkungen, die die AMP-Technologie mit sich bringt, dh Sie können js und HTML nur aus AMP-Bibliotheken verwenden. Dadurch wird die Funktionalität eingeschränkt.