WebP

Ein weiterer Vorteil zur Verbesserung der Ladezeit kann zukünftig mit der Unterstützung des Bildformates WebP durch die Browserhersteller erzielt werden. WebP wird derzeit von Google entwickelt und gilt als Nachfolgeformat für GIF, PNG und JPEG, welches durch ein verbessertes Kompressionsverfahren eine Reduzierung des Dateivolumens von Bildern und Grafiken ermöglicht [Skv14]. Aktuell wird das Format von den Browsern Android, Chrome und Opera unterstützt[1].

<picture>
  <source srcset=“small.webp“ type=“image/webp“) />
  <source srcset=“small.jpg“) />
  <img src=“small.jpg“ />
</picture>

Laut Scott Jehl besteht mit der oben angeführten Auszeichnung von Bildern schon heute die Möglichkeit, das WebP-Dateiformat in Kombination mit dem <picture>-Element, unter der Angabe von type=“image/webp“ und einer entsprechenden Rückfalllösung, einzusetzen, um das Datenvolumen bei der Übertragung zu verringern [Jeh14b].

[1] http://caniuse.com/#search=webp (abgerufen am 28.11.2015)

Accelerated Mobile Pages (AMP)

Im Oktober 2015 hat Google das Accelerated Mobile Pages (AMP) Projekt vorgestellt, mit dem die Performance zur Auslieferung von Informationen für mobile Endgeräte verbessert werden soll [Bes15]. Dabei handelt es sich um ein HTML-Framework, das auf bestehende Webtechnologien zurückgreift und für die Auslieferung an mobile Endgeräte ausschließlich die Verwendung vordefinierter Elemente gestattet, um Auswirkungen auf die Performance, beispielsweise durch den Einsatz externer Bibliotheken, zu vermeiden. Diese Art der Reglementierung wird von dem Performance-Experten Tim Kadlec kritisch betrachtet, da durch die Einschränkungen des Frameworks die Flexibilität verloren geht [Kad15]. Die Veröffentlichung von AMP ist für das Jahr 2016 geplant.

WebAssembly

Die Browserhersteller Apple, Google, Microsoft und Mozilla haben gemeinsam mit der Entwicklung des Webstandards WebAssembly begonnen. Mit diesem soll der Quellcode als Bytecode ausgeführt werden, um langfristig JavaScript zu ersetzen. WebAssembly ist ein binäres Format für Websites und gibt Entwicklern die Möglichkeit, performancekritischen Code und Programmiersprachen, wie C/C++, für die Webplattform zu kompilieren [Lee15]. Es kann mit WebAssembly eine Verbesserung der Ausführungszeit von bis zu 20 Prozent gegenüber der Verwendung von JavaScript erzielt werden, bei einer gleichzeitigen Verringerung der Dateigröße um 20 bis 30 Prozent [Kha15]. Der Webstandard befindet sich noch am Anfang der Entwicklung. Es ist daher noch nicht absehbar, wann dieser produktiv bei der Erstellung von Websites eingesetzt werden kann.

PHP Version 7

Seit der Veröffentlichung des HTTP/2 Protokolls im Mai 2015 und der in Kapitel 3.1 vorgestellten PHP-Version 7 im Dezember 2015, arbeiten die Webhosting-Anbieter an der Implementierung dieser Standards zur Verbesserung der Performance von Websites. Während PHP in der Version 7 eine Optimierung der Ausführungszeit durch die Zend Engine erreicht, setzt das HTTP/2 Protokoll auf eine Reduzierung der HTTP-Anfragen durch die Nutzung direkter Verbindungen in Form von Datenstreams.

HTTP/2 Protokoll

Seit der Veröffentlichung des HTTP/2 Protokolls im Mai 2015 und der in Kapitel 3.1 vorgestellten PHP-Version 7 im Dezember 2015, arbeiten die Webhosting-Anbieter an der Implementierung dieser Standards zur Verbesserung der Performance von Websites. Während PHP in der Version 7 eine Optimierung der Ausführungszeit durch die Zend Engine erreicht, setzt das HTTP/2 Protokoll auf eine Reduzierung der HTTP-Anfragen durch die Nutzung direkter Verbindungen in Form von Datenstreams. Mit diesen Datenstreams wird eine Verbesserung des Ablaufs beim Laden zugehöriger Ressourcen eines HTML-Dokumentes zwischen den Browsern und dem Webserver angestrebt, um Ressourcen ohne vorherige Anfrage des Browsers senden zu können [Hog15]. Die kritische Komponente bei der Nutzung des HTTP/2 Protokolls ist derzeit die Infrastruktur. Sowohl die Clients als auch die Webserver müssen dieses Protokoll unterstützen. Daniel Stenberg, ein Mitarbeiter des Browser-Herstellers Mozilla, gibt an, dass Ende 2015 die Mehrheit der Browser das HTTP/2 Protokoll unterstützen wird und es von den Hosting-Anbietern abhängt, diesen Standard zu etablieren [Ste15c].

Bewertung der praktischen Anwendung

Im Rahmen der praktischen Versuche dieser Arbeit wurden die Ansatzpunkte und Maßnahmen zur Verbesserung der Ladezeit von Webseiten aus Kapitel 3 angewendet. Dazu erfolgte eine Überarbeitung und Optimierung statischer Templates, die anschließend in die Content-Management-Systeme Contao, TYPO3 und WordPress integriert wurden. Dadurch konnte gewährleistet werden, dass die Vergleiche der Systeme stets unter den gleichen Grundvoraussetzungen erfolgten. Im weiteren Verlauf der Umsetzung wurden Lösungsansätze zur Performanceoptimierung für jedes CMS evaluiert. Darüber hinaus erfolgte die Betrachtung der Auswirkungen verschiedener Webserverumgebungen auf die Verarbeitungs- und Ladezeiten bei der Auslieferung der Websites.

Es zeigte sich in den Versuchen, dass die Verwendung eines Shared-Webhostings die Gesamtperformance der Content-Management-Systeme, durch eine Verlängerung der Verarbeitungszeit, negativ beeinträchtigte und aus Sicht der Performanceoptimierung nicht genutzt werden sollte. Das Nginx-Webhosting lieferte die beste Performance der Webserverumgebungen, während das SSD-Webhosting zwischen 0,1 bis 0,2 Sekunden länger zur Verarbeitung und Auslieferung der Webseiten benötigte. Die vorgegebenen Zielwerte des Performance Budgets konnten mit beiden Webserverumgebungen für die drei Content-Management-Systeme erreicht werden.

In der praktischen Umsetzung bestätigte sich die Aussage von Steve Souders, dass die Frontend-Templates das meiste Potential zur Optimierung der Ladezeit bieten [Sou07]. Die bisherigen Versuche erfolgten, zur Gewährleistung der Vergleichbarkeit, mit dem zu Beginn dieses Kapitels optimierten Template. Für ein abschließendes Fazit wurde ein Vergleich der Ursprungsversion des Template, welches WordPress als CMS nutzt, mit der optimierten Version der WordPress-Installation vorgenommen. Aus den Ergebnis-sen in Tabelle 4.28 geht hervor, dass die Gesamtladezeit bei dem Abruf der Startseite über einen Desktop-Rechner mit einem kabelgebundenen Datennetz um 70 Prozent reduziert wurde. Die HTTP-Anfragen konnten von 32 auf 14 und das Datenvolumen um 69 Prozent, von 921 Kilobyte auf 283 Kilobyte, verringert werden.

Tabelle 4.28: Startseite ausgeliefert durch WordPress beim Abruf über einen Desktop-Rechner

Metrik Ursprungsversion Optimiert Verbesserung
Visually Complete 2,1 Sekunden 1,2 Sekunden 0,9 Sekunden 43 %
SpeedIndex 1708 692 1016 59 %
Document Complete 3,3 Sekunden 1,0 Sekunden 2,3 Sekunden 70 %
Time to First Byte 0,7 Sekunden 0,3 Sekunden 0,4 Sekunden 57 %
Anfragen 32 14 18 56 %
Datenvolumen 921 KB 283 KB 638 KB 69 %
Pagespeed Insights (Mobil / Desktop) 56 / 71 100 / 93 44 / 22 79 % / 31 %
YSLOW (Punkte / Note) 70 / D 94 / A 24 34 %
Pingdom 74 99 25 34 %

Bei dem Responsive Webdesign konnte durch die Auslieferung spezifischer Inhalte für mobile Endgeräte das Datenvolumen um 95 Prozent auf 56 Kilobyte reduziert werden (siehe Tabelle 4.29). Dies war einer der wesentlichen Faktoren zur Verbesserung der wahrgenommenen Ladezeit von 4,5 Sekunden auf 1,5 Sekunden in Abbildung 4.12.

Tabelle 4.29: Startseite ausgeliefert durch WordPress beim Abruf über ein 3G-Datennetz

Metrik Ursprungsversion Optimiert Verbesserung
Visually Complete 13,3 Sekunden 1,6 Sekunden 11,7 Sekunden 88 %
SpeedIndex 4390 1310 3080 70 %
Document Complete 11,4 Sekunden 2,6 Sekunden 8,8 Sekunden 77 %
Time to First Byte 1,3 1,1 0,2 15 %
Anfragen 45 6 39 87 %
Datenvolumen 1033 KB 56 KB 977 KB 95 %
Abbildung 4.12: Wahrgenommene Ladezeit des WordPress-Templates nach der Optimierung

Die Ursprungsversion des Template erfordert bei dem Abruf über ein mobiles Endgerät 13 weitere HTTP-Anfragen und die Übertragung eines zusätzlichen Datenvolumens von 112 Kilobyte, gegenüber dem Abruf durch einen Desktop-Rechner. Die Ergebnisse in den Tabellen 4.28 sowie 4.29 zeigen die Potentiale bei der Verwendung von Responsive Webdesign als ganzheitliche Lösung zur Optimierung der Darstellung und Auslieferung von Websites an mobile Endgeräte, unter der Berücksichtigung deren Limitierungen.

Bereits in der Planungsphase eines Webdesigns sollten die Auswirkungen von Design-entscheidungen auf die Ladezeiten einer Website, mit Hilfe von Performance Budgets, beachtet werden. Der Aufwand für eine nachträgliche Überarbeitung, beispielsweise durch den Wechsel des Ansatzes von einer Graceful Degradation hin zu Mobile First, erhöht den Entwicklungsaufwand und die damit verbundenen Kosten. In diesem Beispiel sind für die ausschließliche Überarbeitung des bestehenden, individuellen Templates 45 Arbeitsstunden angefallen.

Vergleich der Webserverumgebungen und Content-Management-Systeme

Nachdem die Content-Management-Systeme Contao, TYPO3 und WordPress in den vorangegangenen Kapiteln optimiert wurden, erfolgt in diesem Kapitel ein Vergleich der Auswirkungen dieser Systeme auf die Ladezeit der Startseite. Gleichzeitig werden anhand einer Gegenüberstellung die Auswirkungen der in dem Kapitel 4.3 vorgestellten Webserverumgebungen im Bezug auf die Performance näher betrachtet.

Die Ladezeiten wurden für diese Versuche mit den Web-Diensten GTmetrix, Pingdom und WebPagetest ermittelt. Bei den Messungen stellte sich heraus, dass die Ergebnisse von GTmetrix und Pingdom deutliche Abweichungen aufwiesen und nicht zuverlässig reproduziert werden konnten. Diese Abweichungen entstanden durch eine Verkürzung der Zeit für den DNS-Lookup ab dem zweiten Abruf einer Domain und entstanden aufgrund der Nutzung von Subdomains für die Installationen der Systeme. WebPagetest hingegen lieferte für den Vergleich konstante und reproduzierbare Messergebnisse.

Tabelle 4.26: Vergleich der Webserverumgebungen und CMS beim Abruf über einen Desktop-Rechner

System – Metrik Timme Hosting Mittwald Strato
Contao – Visually Complete 1,1 Sekunden 1,2 Sekunden 1,4 Sekunden
Contao – SpeedIndex 592 660 957
Contao – Document Complete 1,0 Sekunden 1,2 Sekunden 1,3 Sekunden
Contao – Time to First Byte 0,2 Sekunden 0,3 Sekunden 0,6 Sekunden
TYPO3 – Visually Complete 0,8 Sekunden 1,0 Sekunden 1,1 Sekunden
TYPO3 – SpeedIndex 593 626 820
TYPO3 – Document Complete 0,9 Sekunden 1,0 Sekunden 1,2 Sekunden
TYPO3 – Time to First Byte 0,2 Sekunden 0,2 Sekunden 0,4 Sekunden
WordPress – Visually Complete 1,2 Sekunden 1,3 Sekunden 1,7 Sekunden
WordPress – SpeedIndex 690 790 1191
WordPress – Document Complete 1,0 Sekunden 1,3 Sekunden 1,5 Sekunden
WordPress – Time to First Byte 0,3 Sekunden 0,4 Sekunden 0,8 Sekunden

Die Ergebnisse in Tabelle 4.26 wurden mittels WebPagetest vom Standort Amsterdam über ein kabelgebundenes Datennetz mit einer Round Trip Time von 25 Millisekunden ermittelt. Die Messung der Ergebnisse in Tabelle 4.27 erfolgte ebenfalls vom Standort Amsterdam über ein 3G-Datennetz mit einer Round Trip Time von 300 Millisekunden.

Tabelle 4.27: Vergleich der Webserverumgebungen und CMS beim Abruf über ein 3G-Datennetz

System – Metrik Timme Hosting Mittwald Strato
Contao – Visually Complete 1,6 Sekunden 1,6 Sekunden 2,1 Sekunden
Contao – SpeedIndex 1213 1312 1284
Contao – Document Complete 2,6 Sekunden 2,7 Sekunden 2,9 Sekunden
Contao – Time to First Byte 1,0 Sekunden 1,1 Sekunden 1,3 Sekunden
TYPO3 – Visually Complete 1,8 Sekunden 1,9 Sekunden 2,1 Sekunden
TYPO3 – SpeedIndex 1707 1807 2013
TYPO3 – Document Complete 2,5 Sekunden 2,6 Sekunden 2,8 Sekunden
TYPO3 – Time to First Byte 1,0 Sekunden 1,1 Sekunden 1,3 Sekunden
WordPress – Visually Complete 1,6 Sekunden 1,7 Sekunden 2,0 Sekunden
WordPress – SpeedIndex 1309 1412 1712
WordPress – Document Complete 2,7 Sekunden 2,8 Sekunden 3,2 Sekunden
WordPress – Time to First Byte 1,1 Sekunden 1,3 Sekunden 1,5 Sekunden

Aus den Ergebnissen in den Tabellen 4.26 und 4.27 geht hervor, dass die Webserverumgebung die Ladezeiten von Contao und TYPO3 um bis zu 0,3 Sekunden beeinflusst. Bei der Auslieferung von WordPress durch Strato verlängert sich die wahrgenommene Ladezeit gegenüber Timme Hosting um 0,5 Sekunden. Die Abweichung der Ladezeit zwischen Timme Hosting und Mittwald beträgt 0,1 Sekunden (siehe Abbildung 4.11).

Abbildung 4.11: Auswirkung der Webserver auf die wahrgenommen Ladezeit von WordPress

Das Nginx-Webhosting von Timme Hosting liefert im Vergleich die beste Performance, das SSD-Webhosting von Mittwald benötigte zur Verarbeitung und Auslieferung 0,1 bis 0,2 Sekunden länger. Ein deutlicher Unterschied ist beim Shared-Webhosting von Strato anhand des Speed Index und der Time to First Byte zu erkennen, diese ist bei der Auslieferung doppelt so hoch wie bei Mittwald (siehe Tabelle 4.26). Im Hinblick auf die Performance sollte somit kein kostengünstiges Shared-Webhosting genutzt werden.

Die Gesamtladezeit der drei Content-Management-Systeme liegt dicht zusammen und verhält sich proportional zu der genutzten Webserverumgebung. TYPO3 überzeugt bei dem Abruf über einen Desktop-Rechner mit der geringsten Ladezeit, konnte allerdings bei der Auslieferung über ein mobiles 3G-Datennetz nicht überzeugen (siehe Tabelle 4.27). Contao lieferte die Webseiten über ein 3G-Datennetz mit der niedrigsten Ladezeit aus und positionierte sich bei dem Abruf über einen Desktop-Rechner im Mittelfeld.

Anhand der Ergebnisse dieser Versuche lässt sich festhalten, dass die Wahl des CMS, im Gegensatz zur Wahl der Webserverumgebung, nur einen geringeren Einfluss auf die Verbesserung der Ladezeit einer Website hat. Bei der Wahl eines Content-Management-Systems sollten daher vorwiegend der Einsatzzweck und die erforderlichen Funktionen berücksichtigt werden.

WordPress

WordPress startete im Jahr 2004 als Open Source Blog-System und wird heute vermehrt als CMS eingesetzt [Wikb]. Mit einem Marktanteil von 34,58 Prozent ist WordPress das meist genutzte Content-Management-System in Deutschland [Cms15]. Die Verbreitung des WordPress-Systems führt zu einer umfassenden Unterstützung durch kostenfreie sowie kostenpflichtige Erweiterungen. Diese stellen ergänzende Funktionen bereit, die das System nicht vorgesehen hat, wie beispielsweise ein Kontaktformular. Neben diesen Funktionserweiterungen werden fertig ausgestaltete und programmierte Webdesigns in Form von Themes angeboten, die sich ohne Programmierkenntnisse installieren lassen.

Optimierungen bei der Installation und Konfiguration

Im Rahmen der Performanceoptimierung dieser Arbeit wurde WordPress in der Version 4.3 eingesetzt. Im Gegensatz zu den Systemen Contao und TYPO3 wird bei der Installation von WordPress keine HTACCESS-Datei bereitgestellt. Diese musste per Hand angelegt werden und die entsprechenden Definitionen erfolgten anhand der optimierten HTACCESS-Datei des statischen Template. Die Standardinstallation von WordPress bietet keine weiteren Ansatzpunkte zur Optimierung an.

Abbildung 4.7: Wahrgenommene Ladezeit mit und ohne Definitionen in der HTACCESS-Datei

Die Übernahme der HTACCESS-Datei brachte bei dem Abruf über einen Desktop-Rechner mittels WebPagetest eine Verringerung der wahrgenommenen Ladezeit um 13 Prozent, von 1,5 Sekunden auf 1,3 Sekunden, wie aus der Abbildung 4.7 hervorgeht. Darüber hinaus konnte eine Reduzierung der Ladezeit des Document Complete um 25 Prozent, von 1,6 Sekunden auf 1,2 Sekunden, erreicht werden (siehe Tabelle 4.21).

Tabelle 4.21: Auslieferung der Startseite durch WordPress mit und ohne HTACCESS-Datei

Metrik Normal Optimiert Verbesserung
Visually Complete 1,5 Sekunden 1,3 Sekunden 0,2 Sekunden 13 %
SpeedIndex 1367 1290 77 6 %
Document Complete 1,6 Sekunden 1,2 Sekunden 0,4 Sekunden 25 %
Pagespeed Insights 77 / 89 79 / 93 2 / 4
YSLOW 87 / B 92 / A 5
Pingdom 90 99 9

Die Bewertungen anhand der regelbasierten Kriterienkataloge von PageSpeed Insights, YSLOW und Pingdom verbesserten sich moderat. Für weitere Optimierungen der Ladezeiten ist die Integration von Erweiterungen zur Ergänzung der Funktionen des Systems erforderlich.

Integration von Erweiterungen

WordPress setzt zur Anpassung und Ergänzung der Grundfunktionen des Systems auf die Verwendung von externen Erweiterungen. Diese können über die Administrationsoberfläche des Systems automatisiert installiert und anschließend konfiguriert werden.

Um die Möglichkeiten zur Verbesserung der Verarbeitungszeit durch Caching zu testen, wurden die Auswirkungen der Erweiterungen W3 Total Cache und WP Super Cache in einem Versuch näher betrachtet. WP Super Cache bietet nach der Installation kaum Einstellungsmöglichkeiten, während sich W3 Total Cache umfangreich konfigurieren lässt. In der Konfiguration von W3 Total Cache wurden zu Beginn der Optimierung alle Caches, die Komprimierung der zu generierenden HTML-Dokumente und die Nutzung clientseitiger Browser-Caches aktiviert.

Abbildung 4.8: Auswirkungen der Caching-Erweiterungen für WordPress beim Abruf der Startseite

Aus der Abbildung 4.8 geht hervor, dass beim Abruf der Startseite mit einem Desktop-Rechner durch WebPagetest die Caching-Erweiterung WP Super Cache mehr Zeit zur Auslieferung der Inhalte im sichtbaren Bereich benötigt, als der Abruf ohne Caching.

Abbildung 4.9: Wahrgenommene Ladezeiten durch Caching-Erweiterungen in WordPress

Die Generierung und Auslieferung der HTML-Dokumente profitierte in dem Versuch am meisten von der Erweiterung W3 Total Cache. Diese reduzierte die Gesamtladezeit der Startseite um 0,2 Sekunden und verbesserte auch die wahrgenommene Ladezeit, wie in Abbildung 4.9 dargestellt, um 0,2 Sekunden. Die Bewertungen anhand der regelba-sierten Kriterienkataloge von PageSpeed Insights, YSLOW und Pingdom verbesserten sich nicht durch die Nutzung der Erweiterungen zum internen Caching. Aufgrund dieser Ergebnisse wurde W3 Total Cache zur Verbesserung der Performance von WordPress eingesetzt. Im weiteren Verlauf konnten mit Hilfe der Optionen der Erweiterung zudem die CSS-Definitionen für den kritischen Rendering Pfad integriert werden.

Um Responsive Images mit WordPress nutzen zu können, ist zurzeit die Erweiterung RICG Responsive Images von den Entwicklern von WordPress und der Responsive Images Community Group (RICG) erforderlich. In der WordPress Version 4.4, die im Dezember 2015 erscheint, ist die Einbindung von Responsive Images in den Standard-funktionen des WordPress-Systems vorgesehen [Mcg15]. Nach der Installation erstellt die Erweiterung RICG Responsive Images während des Hochladens von Bildern auto-matisch, anhand zuvor festgelegter Bildgrößen, verschiedene Auflösungen. In den Ein-stellungen der Erweiterungen kann unter dem Menüpunkt Medien die Breite der Bilder angegeben werden. Hier wurden die von dem statischen Template vorgegebenen Auf-lösungen der Bilder mit einer Breite von 720 Pixeln und 990 Pixeln gewählt. Weitere Auflösungen lassen sich in der Konfigurationsdatei functions.php des Themes durch die Angabe von add_image_size definieren [Gre15].

Die Erweiterung EWWW Image Optimizer optimiert die bestehenden Bilder in der Mediathek von WordPress durch eine erneute Komprimierung und die Entfernung von Metadaten. Darüber hinaus werden nach der Installation der Erweiterung alle Bilder beim Hochladen in die Mediathek automatisch optimiert, um Auswirkungen auf die Ladezeit, durch eine fehlerhafte Kompression der Bilder, zu vermeiden.

Zur Steuerung der Auslieferung bestimmter Elemente für mobile Endgeräte, nach dem in Kapitel 3.5.1 vorgestellten Ansatz RESS, erfolgte in WordPress die Installation der Erweiterung Mobble. Diese identifiziert anhand des User Agent das Endgerät und berücksichtigt in den Templates Auszeichnungen mit der Definition is_mobile().

if (is_mobile()) {
  the_post_thumbnail(‚medium’);
} else {
  the_post_thumbnail(‚large’);
}

Folglich wurden für die Auslieferung der Website an mobile Endgeräte die Web Fonts und der Content-Slider auf der Startseite entfernt. Durch diese Maßnahmen konnte das Datenvolumen der Startseite von 297 Kilobyte auf 52 Kilobyte reduziert und die Ladezeit um 2 Sekunden verringert werden (siehe Abbildung 4.10).

Abbildung 4.10: Verbesserung der Ladezeit durch die Reduzierung des Datenvolumens mit Mobble

Bei der Verwendung von Erweiterungen in WordPress-Systemen ist zu beachten, dass sich diese, durch eine Steigerung der Anzahl von Datenbankabfragen, nachteilig auf die Performance der Website auswirken können. Laut Marcus Taylor werden Probleme bei der Ladezeit von WordPress-Installationen vorwiegend durch zu langsame Webserver, eine hohe Anzahl an Erweiterungen oder überladene Templates verursacht [Tay14]. Die Bereinigung der Datenbank sollte daher zur Systempflege von WordPress gehören und kann mit der Erweiterung WP-Optimize in regelmäßigen Intervallen automatisiert vorgenommen werden, um die Performance der Datenbank aufrechtzuerhalten [Tay14].

Bewertung von WordPress

WordPress bietet in der Grundkonfiguration, abgesehen von den Definitionen mittels HTACCESS-Datei, keine weiteren Ansatzpunkte für die Maßnahmen zur Optimierung der Ladezeit. Zur Realisierung weiterer Performanceoptimierungen ist die Installation von Erweiterungen erforderlich. Diese haben den Nachteil, dass eine Abhängigkeit zu Drittanbietern entsteht, die diese Erweiterungen entwickeln und bereitstellen. Die Integration von Erweiterungen erfolgte für das systeminterne Caching, die Einbindung von Responsive Images, zur Optimierung der über WordPress hochgeladenen Bilder und zur Auslieferung spezifischer Elemente sowie Ressourcen für mobile Endgeräte.

Tabelle 4.22: Startseite ausgeliefert durch WordPress beim Abruf über einen Desktop-Rechner

Metrik Normal Optimiert Verbesserung
Visually Complete 1,5 Sekunden 1,3 Sekunden 0,2 Sekunden 13 %
SpeedIndex 666 790 124 19 %
Document Complete 1,4 Sekunden 1,1 Sekunden 0,3 Sekunden 21 %
Pagespeed Insights 77 / 89 100 / 93 23 / 4
YSLOW (Punkte / Note) 86 / B 94 / A 8
Pingdom 90 99 9

Die Optimierungen von WordPress bewirkten eine Reduzierung der Gesamtladezeit, die sich wiederum auf die wahrgenommene Ladezeit auswirkte. Aus den Tabellen 4.22 und 4.23 geht hervor, dass die Ergebnisse der regelbasierten Kriterien verbessert wurden.

Tabelle 4.23: Unterseite ausgeliefert durch WordPress beim Abruf über einen Desktop-Rechner

Metrik Normal Optimiert Verbesserung
Visually Complete 0,8 Sekunden 0,6 Sekunden 0,2 Sekunden 25 %
SpeedIndex 604 493 111 18 %
Document Complete 0,9 Sekunden 0,9 Sekunden
Pagespeed Insights 78 / 90 100 / 93 22 / 3
YSLOW (Punkte / Note) 89 / B 95 / A 6
Pingdom 92 99 7

Wie schon in den Versuchen mit Contao und TYPO3, wirkten sich bei WordPress die Maßnahmen zur Optimierung der Ladezeit insbesondere auf die Auslieferung an mobile Endgeräte aus. Für die Darstellung der Inhalte in dem sichtbaren Bereich eines mobilen Endgerätes konnten Ladezeiten von 1,6 Sekunden für die Startseite und 1,4 Sekunden für eine Unterseite gemessen werden (siehe Tabelle 4.24 und 4.25 auf der folgenden Seite).

Tabelle 4.24: Startseite ausgeliefert durch WordPress beim Abruf über ein 3G-Datennetz

Metrik Normal Optimiert Verbesserung
Visually Complete 3,3 Sekunden 1,6 Sekunden 1,7 Sekunden 52 %
SpeedIndex 2387 1312 1075 45 %
Document Complete 4,7 Sekunden 2,7 Sekunden 2,0 Sekunden 43 %
Anfragen 13 6 7 54 %
Datenvolumen 297 KB 52 KB 245 KB 82 %

Tabelle 4.25: Unterseite ausgeliefert durch WordPress beim Abruf über ein 3G-Datennetz

Metrik Normal Optimiert Verbesserung
Visually Complete 3,3 Sekunden 1,4 Sekunden 1,9 Sekunden 58 %
SpeedIndex 2822 1154 1668 59 %
Document Complete 3,8 Sekunden 3,1 Sekunden 0,7 Sekunden 18 %
Anfragen 11 8 3 27 %
Datenvolumen 230 KB 188 KB 42 KB 18 %

Die Berücksichtigung des kritischen Rendering Pfades, durch die Einbindung von CSS-Definitionen als Inlinestyling, führte auf der Unterseite zu einer Verbesserung der Zeit des Visually Complete von 58 Prozent. Das erzielte Ergebnis ist beachtenswert, da das Datenvolumen der Unterseite durch die Optimierung lediglich um 18 Prozent verringert werden konnte.

TYPO3

Das Enterprise Content-Management-System TYPO3 wurde in dem Jahr 2002 in der finalen Version 3.0 veröffentlicht, bei allen vorherigen Veröffentlichungen handelte es sich um Beta-Versionen [Typ]. Im Rahmen dieser Arbeit wurde die Version 7.4 des TYPO3 CMS eingesetzt. Diese Version lässt sich, gemäß der Roadmap[1], auf die am 10. November 2015 veröffentlichte Version 7.6 von TYPO3 updaten und bietet einen Long-Term-Support für sicherheitsrelevante Updates bis in das Jahr 2018.

Mit der aktuellen Version 7 des TYPO3 CMS wurde der grundlegende Quellcode des Systems überarbeitet und eine Verbesserung der Performance gegenüber den bisherigen Versionen des CMS erzielt [Bri15].

Optimierung der Konfiguration

Nach der Installation des TYPO3 CMS auf dem Webserver erfolgte das Anlegen der Seitenstruktur und die Übernahme der Inhalte. Die einzelnen Templates des Themes wurden mit den Bezeichnern zur Einbindung dynamischer Inhalte versehen und das entsprechende TypoScript für die Funktionalitäten der Website angelegt.

Ein clientseitiges Caching der Inhalte ist bei TYPO3 standardmäßig aktiviert und erfolgt durch eine mitgelieferte HTACCESS-Datei, die bereits viele Optimierungen zur Verbesserung der Ladezeit bei der Auslieferung von Webseiten berücksichtigt. Über die Grundkonfiguration hinausgehende Anpassungen zur Performanceoptimierung stellt das System nicht zur Verfügung.

Um eine Verbesserung des Renderings in den Browsern durch die Berücksichtigung des kritischen Rendering Pfades zu erzielen, wurde der erforderliche CSS-Quellcode, wie in Kapitel 4.2.3 beschrieben, für jedes Template generiert und in den HTML-Dateien der integrierten Templates mittels Inlinestyling hinterlegt. Sofern ein Webseitenlayout von dem Grundaufbau abweicht, ist es in TYPO3 erforderlich, ein separates Template für diese Webseite zu erstellen und das Template mittels TypoScript zu verknüpfen.

Die in Kapitel 3.5.2 vorgestellte Einbindung von Responsive Images ist in TYPO3 seit der Version 6.2 standardmäßig integriert. Die Aktivierung der Funktionalität erfolgt in der Konfiguration des Templates über den Constant Editor. Dort kann unter dem Punkt Rendering-type for responsive image zwischen den Angaben „default“, „img-tag with alternate sources as srcset-attribute“ und „picture-tag with source-child-tags“, zu der Einbindung von Responsive Images, durch das <picture>-Element oder das srcset-Attribut gewählt werden. Im Anschluss müssen die von dem System zu generierenden Auflösungen der Bilder in das TypoScript des Template aufgenommen werden. Der folgende Ausschnitt zeigt die Konfiguration zur Generierung und Auslieferung der Bilder in drei Auflösungen mit einer Breite von 480 Pixeln, 720 Pixeln und 990 Pixeln.

tt_content.image.20.1.sourceCollection {
  small.maxW = 480
  small.srcsetCandidate = 480w
 
  middle.maxW = 720
  middle.srcsetCandidate = 720w
 
  large.maxW = 990
  large.srcsetCandidate = 990w
}

Integration von Erweiterungen

Die Möglichkeit zur Identifikation des User Agent wurde aus der Version 7 des TYPO3 CMS entfernt. Eine Definition der auszuliefernden Inhalte und Ressourcen, wie bei den vorherigen Versionen des CMS, ist nicht möglich. Diese Funktionalität lässt sich mit der Erweiterung Mobile Helper hinzufügen.

Nach der Installation von Mobile Helper, über das Repository von TYPO3, wurden für alle Templates mobile Versionen erstellt. Anschließend erfolgte eine Ergänzung des be-stehenden TypoScript mit dem nachfolgenden Quellcode zur Auslieferung der mobilen Templates bei dem Abruf der Website über mobile Endgeräte.

[userFunc = user_lvmobile_isMobile]
  temp.docHead {
    template.file = fileadmin/templates/main/page-mobile.html
  }
[end]

Zur serverseitigen Optimierung und Reduzierung der generierten HTML-Dokumente wurde die Erweiterung Sourceopt eingesetzt. Diese optimiert und minifiziert den Quellcode vor der Auslieferung an das Endgerät des Nutzers.

Bewertung von TYPO3

Das TYPO3 CMS erforderte in der Grundkonfiguration die Definition zur Generierung der Responsive Images, weitere Anpassungen, wie die Berücksichtigung des kritischen Rendering Pfades, erfolgten bei der Integration des Template. Die Komprimierung der HTML-Dokumente und die Steuerung der Auslieferung von bestimmten Inhalten für mobile Endgeräte erfolgten über die Installation von Erweiterungen externer Anbieter.

Die Optimierungen verbesserten die wahrgenommene Ladezeit bei dem Abruf der Startseite über einen Desktop-Rechner um 27 Prozent, gleichzeitig blieb die Darstellungszeit der Unterseiten unverändert. Durch die automatische Generierung und Einbindung einer CSS-Datei im <head>-Element der HTML-Dokumente konnte keine Verbesserung der Bewertung durch PageSpeed Insights erreicht werden (siehe Tabelle 4.17 und 4.18).

Tabelle 4.17: Startseite ausgeliefert durch TYPO3 beim Abruf über einen Desktop-Rechner

Metrik Normal Optimiert Verbesserung
Visually Complete 1,1 Sekunden 0,8 Sekunden 0,3 Sekunden 27 %
SpeedIndex 657 611 46 7 %
Document Complete 1,0 Sekunden 0,9 Sekunden 0,1 Sekunden 10 %
Pagespeed Insights 79 / 93 79 / 93 – / –
YSLOW 93 / A 93 / A – / –
Pingdom 98 98

Tabelle 4.18: Unterseite ausgeliefert durch TYPO3 beim Abruf über einen Desktop-Rechner

Metrik Normal Optimiert Verbesserung
Visually Complete 0,9 Sekunden 0,9 Sekunden
SpeedIndex 645 629 16 2 %
Document Complete 0,9 Sekunden 0,9 Sekunden
Pagespeed Insights 79 / 93 79 / 93 – / –
YSLOW 94 / A 94 / A – / –
Pingdom 98 98

Noch deutlicher fallen hingegen die Verbesserungen bei einem Abruf der von TYPO3 generierten Webseiten durch mobile Endgeräte aus. Die Ladezeiten konnten durch eine Reduzierung der eingebundenen Ressourcen und des Datenvolumens reduziert werden. Bei dem Abruf der Startseite über ein 3G-Datennetz konnten das Datenvolumen um 80 Prozent und die Ladezeit um 41 Prozent verringert werden (siehe Tabelle 4.19).

Tabelle 4.19: Startseite ausgeliefert durch TYPO3 beim Abruf über ein 3G-Datennetz

Metrik Normal Optimiert Verbesserung
Visually Complete 3,3 Sekunden 1,9 Sekunden 1,4 Sekunden 42 %
SpeedIndex 2298 1807 491 21 %
Document Complete 4,4 Sekunden 2,6 Sekunden 1,8 Sekunden 41 %
Anfragen 14 7 7 50 %
Datenvolumen 270 KB 54 KB 216 KB 80 %

Tabelle 4.20: Unterseite ausgeliefert durch TYPO3 beim Abruf über ein 3G-Datennetz

Metrik Normal Optimiert Verbesserung
Visually Complete 3,2 Sekunden 1,9 Sekunden 1,3 Sekunden 41 %
SpeedIndex 2780 1615 1165 42 %
Document Complete 3,7 Sekunden 3,4 Sekunden 0,3 Sekunden 8 %
Anfragen 12 9 3 25 %
Datenvolumen 211 KB 189 KB 22 KB 10 %

Bei den Unterseiten fällt die Reduzierung des Datenvolumens gemäß der Tabelle 4.20 nicht in gleichem Maße wie zuvor bei der Startseite aus, dennoch verbesserte sich die wahrgenommene Ladezeit um 41 Prozent auf 1,9 Sekunden. Eine Gegenüberstellung mit den Content-Management-Systemen Contao und WordPress erfolgt in Kapitel 4.7.

[1] https://typo3.org/typo3-cms/roadmap/ (abgerufen am 15.11.2015)

>