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.

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.

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.

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).

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.