tl;dr: Seite laden: 16s -> 4.5s , TTFB: 4.5s -> 2.5s, Datenmenge: 1.1MB -> 0.59MB, PageSpeed: 75% -> 93%
Einer unserer Kunden kam mit dem Wunsch auf uns zu, seinen Magentoshop zu beschleunigen. Es ist ein relativ neuer Shop, der noch am Anfang seiner Entwicklung steht. Das Hosting übernimmt ein vServer, für den der Kunde auch root-Zugang hat. Unsere ersten Schritte bestanden in einer Ist-Analyse gefolgt von einer Soll-Definition. Der Kunde wählte dafür eine für Ihn repräsentative Seite aus.
Für die Untersuchung der Seite boten sich die Webseiten GTmetrix und WebPagetest an. GTmetrix fasst die Ergebnisse von YSlow und Google PageSpeed zusammen und als Bonus speichert es alte Messungen zum Vergleich der verschiedenen Optimierungen. Die Seite WebPagetest überzeugt mit aussagekräftigen Wasserfall und Verbindungsdiagrammen.
Bei der Analyse zeigte sich, dass das Rendern der Seite mehr als 15 Sekunden benötigt und diese Seite mehr als 1.1 MB an initialen Daten benötigt. Als Ziel setzte der Kunde 6 Sekunden zum Rendern der Seite. Das sahen wir auch als realistisch an.
Beispiel eines Verbindungsdiagramms
Im Wasserfalldiagramm stellt sich die TTFB (Time To First Byte) als größter Posten dar und dort begannen wir auch mit unserer Arbeit. Nach eingehender Analyse der momentanen Systems zeigte sich auf PHP-Seite, dass der APC Bytecode Cache mit 12MB zu klein dimensioniert war und PHP per FCGI eingebunden ist.
Der kleine Cache sorgte für eine schnelle Verdrängung von Cacheeinträgen. Dies führt zu einer Hit / Miss Rate von 20 / 80. Da jeder FCGI Prozess seinen eigenen Bytecode Cache benötigt, wird bei der Nutzung von APC für den Magento Cache zusätzlicher Platz benötigt. Wir splitteten den Mangento Cache und Bytecode Cache in zwei verschiedene Systeme. Der APC-Cache ist mit 128MB bemessen und sorgt für das Cachen des Bytecodes. Der Magento Cache wird jetzt durch einen Memcached-Server mit 256MB übernommen. Durch diese Maßnahme kann der Kunde später durch neue Server horizontal skalieren und hat einen gemeinsamen Cache für alle Instanzen. Die TTFB war damit bei einem Drittel der ursprünglichen Zeit und die Hit- / Missrate für den APC- und Bytecode-Cache bei 99/1.
Die Begutachtung des Seiten-HTML-Codes förderte zu Tage, das Boxen mit aktuellen Angebote per iframe eingebunden wurden. Dies sorgte beim Laden der Seite für ein ständiges Neurendern und verzögerte den subjektiven Seitenaufbau. Die diversen iframes konsolidierten wir zu einem einzigen, der bereits von Magento an der richten Stelle im Template eingebunden wird.
Die Verbindungsanalyse von GTmetrix zeigte, das viele Bilder/CSS/JS Dateien sequenziell geladen werden müssen und nur eine begrenzte Anzahl von Verbindungen zum Server aufgebaut werden. Dies lösten wir durch Aktivieren von HTTP-Pipelining im Apacheserver und Aufteilung der js, media und skin Verzeichnisse auf verschiedene vHosts.
Beispiel eines Wasserfalldiagramms
Als letztes widmeten wir uns dem Thema Trafficreduzierung. Dazu ließen wir Magento alle CSS- und JS-Dateien jeweils in eine Datei zusammenfassen und diese mit einem CSS- und JS-Minifier weiter komprimieren, die Produktbilder von Magento auf die korrekte Größe skalieren.
Weiterhin verkleinerten wir die Bilder ohne Qualitätseinbußen durch das Tool in Googles Pagespeed. Die GZip-Kompression aller textuellen Ressourcen und das Setzen eines Expires-Headers durch den Apache Server brachte noch einmal einen deutliche Geschwindigkeitssteigerung und Trafficreduzierung bei weiteren Zugriffen auf die Seite.
Desweiteren setzten wir alle einfach zu erreichenden Vorschläge von YSlow und Googles Pagerank um.
Das Ergebnis der Mühe ist ein Shop, der in 4.5 Sekunden lädt. Der benötigte Traffic für die Seite sank dabei von 1.1MB auf 590KB. Das YSlow-Ranking wuchs von 67% auf 80% und das PageSpeed-Ranking von 75% auf 93%.
Wir legten dem Kunden dar, dass er die Ladezeit von 4.5s weiter reduzieren könnte, da dort 2.5s als TTFB enthalten sind. Dies könnte er durch geschicktes Caching mittels eines Reverse Proxy wie beispielsweise Varnish erreichen. Das Laden des statischen Contents könnte weiterhin auch durch einen leichtgewichtigeren Webserver wie lighttpd oder nginx noch beschleunigt werden. Der Kunde ist mit dem erreichten Zustand sehr zufrieden und priorisiert momentanen andere Projekte höher.
Falls auch Sie Hilfe bei der Beschleunigung ihres eCommerce Portals benötigen, stehen wir Ihnen gerne mit Rat und Tat zur Seite. Fordern Sie uns ! Wir lieben Herausforderungen. Nehmen Sie einfach über das Kontaktformular mit uns Kontakt auf und wir melden uns bei Ihnen.