Google’s mod_pagespeed Praxis-Test
Copyright © Shutterstock / Billion Photos
Inhaltsverzeichnis
Was ist Google’s mod_pagespeed Praxis-Test?
Die Ladegeschwindigkeit einer Seite liegt Google ja bekanntlich sehr am Herzen. Die Google-Gründer wollen das Internet laut eigenen Angaben so schnell machen wie das Umblättern in einer herkömmlichen Zeitung.
Nicht umsonst sind bisher etliche Grundlagenartikel sowie ein Analyse-Tool für den Firefox unter der Regie von Google erschienen. In Chrome ist sogar ein sehr nützliches Werkzeug zum Messen der Ladegeschwindigkeit der Komponenten einer Website schon fest eingebaut. Ein Zeichen, wie ernst es ihnen ist.
Und auch wenn immer noch spekuliert wird, ob die Ladegeschwindigkeit nun schon einen Einfluss auf das Ranking hat oder nicht – empirische Analysen haben gezeigt, dass besonders bei großen Websites eine Verringerung der Ladezeit tatsächlich die Indexierungstiefe erhöht, weshalb die Ladegeschwindigkeit nicht mehr länger nur eine Sache der Usability und performance-liebenden Enthusiasten ist. Es ist ein tatsächlicher Faktor im SEO, den man nicht länger ignorieren sollte.
2010 hat nun Google noch eins draufgesetzt und für den Apache Webserver ein Modul namens mod_pagespeed veröffentlicht, das mehr oder weniger “out of the box” für bis zu 50% schnellere Ladezeiten sorgen soll. In manchen Fällen sogar noch mehr. Ein leeres Versprechen – oder ist da tatsächlich etwas dran? Wir haben natürlich gleich mal die Probe aufs Exempel gemacht…
Die Testsituation
Verwendet wurde ein Root-Server bei Strato. Dort werden drei Websites mit unterschiedlichen Domains von einer zentralen Apache-Instanz beschickt. Eine der Websites ist ein ziemlich modifizierter OsCommerce MS2, die anderen beiden sind WordPress-Installationen in jeweils aktueller Version, mit sehr unterschiedlichen Templates und unterschiedlichen Plugins.
Der Aufbau der Seiten war wie folgt (alle Zahlen in kB):
| Website | Documents | Stylesheets | Images | Scripts | Total |
| OsCommerce | 44,23 | 2,64 | 133 | 17,93 | 198,07 |
| WordPress 1 | 31,60 | 22,50 | 211,60 | 167,10 | 432,89 |
| WordPress 2 | 42,88 | 69,37 | 41,51 | 242,50 | 396,25 |
Das mod_pagespeed-Plugin wurde in der 32bit-Version für Ubuntu als Package heruntergeladen, installiert, mit den Grundeinstellungen konfiguriert und der Apache anschließend neu gestartet. Ein phpinfo() zeigte auch, dass das Modul geladen war und das Caching-Verzeichnis des Plugins wurde im Laufe der Tests erfolgreich mit Dateien gefüllt, d.h. die Funktion war gegeben.
Die Testdurchführung
Vor jedem Request wurde der Browser-Cache gelöscht, um lokale Caching-Effekte zu eliminieren. Zudem wurden 5 Requests gemacht und daraus der Mittelwert gebildet, um mögliche, vorübergehende Lastspitzen des Servers zu eliminieren. Extreme Abweichler vom Mittelwert wurden gelöscht und der Request wiederholt, da die Maschine nicht die performanteste ist und zufälligerweise stattfindende, massiv parallel Zugriffe durchaus deutlich spürbar sind.
Das Ergebnis
Das Ergebnis war überraschend (alle Zahlenangaben in ms):
| OsCommerce | Latenz | Documents | Stylesheets | Images | Scripts | Total |
| Vorher | 728 | 931 | 998 | 7.272 | 3.832 | 8.176 |
| Nachher | 789,00 | 1020,00 | 1045,00 | 1976,00 | 2.172 | 4.380 |
| Differenz | -61 | -89 | -47 | 5296,00 | 1.660 | 3.638 |
| Veränderung | -8% | -10% | -5% | 73% | 43% | 44% |
| WordPress 1 | Latenz | Documents | Stylesheets | Images | Scripts | Total |
| Vorher | 728 | 1.342 | 395 | 2.302 | 2.564 | 6.072 |
| Nachher | 1.222 | 1.222 | 379 | 3.024 | 3.004 | 6.036 |
| Differenz | -494 | 120 | 16 | -722 | -440 | 36 |
| Veränderung | -68% | 9% | 4% | -31% | -17% | 1% |
| WordPress 2 | Latenz | Documents | Stylesheets | Images | Scripts | Total |
| Vorher | 1.832 | 1.832 | 2.134 | 2.736 | Apr 44 | 6.886 |
| Nachher | 1.914 | 1.912 | 2.100 | 2.920 | Apr 14 | 7.126 |
| Differenz | -82 | -80 | 34 | -184 | -60 | -240 |
| Veränderung | -4% | -4% | 2% | -7% | -1% | -3% |
Das Ergebnis ist also durchwachsen.
Die Website mit OsCommerce erlebte gerade im Bereich der Bilder einen deutlich spürbaren Performance-Zuwachs, wohingegen die WordPress-Websites nahezu unverändert blieben.
Die Interpretation
Auch wenn für eine Website mit einfachen Mitteln (Installation und Konfiguration alles in allem rund 10 Minuten) ein überwältigender Effekt erzielt werden konnte, darf das wohl nicht verallgemeinert werden. Gerade im Bereich der Latenzen ist sogar durchweg eine längere Ladezeit zu sehen und diese wird nur durch mögliche Einsparungen bei den einzelnen Komponenten der Website wettgemacht.
Ob dies am Anteil der einzelnen Komponenten, am Aufbau der WordPress-Websites, an einer eventuell noch nicht optimalen Konfiguration oder eventuell sogar an einem noch nicht ganz ausgereiften Plugin liegt – diese Frage können nur weitere Tests und eine bessere Dokumentation des Plugins zutage fördern.
Zudem kann sicher die Testsituation noch weiter optimiert werden, indem ein dedizierter Testserver verwendet wird, der keine andere Aufgabe hat, als die Testabrufe zu bedienen, um so auch die letzten Effekte multipler Zugriffe zu eliminieren. Allerdings waren die Test-Websites wenig frequentiert, sodass das Ergebnis als hinreichend genau und vor allem tatsächlich praxisbezogen angesehen werden dürfte.
Fazit
Als Fazit kann man jedenfalls sagen, dass es nach momentanem Wissensstand durchaus einen Versuch wert ist. Wenn wie im Falle der OsCommerce-Website mit nur 15 Minuten Arbeit satte 44% Ladezeit eingespart werden können, ist das beeindruckend. Und wenn hingegen wie im Fall der beiden WordPress-Websites zumindest keine deutlich spürbare Verschlechterung eintritt, kann man es immerhin als kleine praktische Übung sehen und das Plugin sehr einfach wieder deaktivieren und deinstallieren.
Sie haben noch Fragen?
