Test von Googles neuem Apache Modul mod_pagespeed
Google kündigt an, die Welt applaudiert: Das neue Apache-Modul mod_pagespeed soll automatisch Webseiten schneller machen, ohne Aufwand und für jede Seite, eine bis zu 50% schnellere Webseite wird versprochen. Google selbst hat natürlich auch etwas davon: Wenn jede Webseite schneller abrufbar ist, können die Suchmaschinen-Spider schneller und mehr crawlen…
Doch wenn man es selbst ausprobiert sind die Ergebnisse ernüchternd. Ich habe heute Abend das Modul installiert und aktiviert (in unter 3 Minuten), und ein paar Messergebnisse mit Firebug, PageSpeed und YSlow zusammengetragen.
Ergebnis: kein nennenswerter Geschwindigkeitsschub, teilweise sogar langsamer als vorher. Einige haben bei ersten Benchmarks das selbe Ergebnis wie ich erhalten, andere jedoch sprechen von 46% Verbesserung. Es scheint sehr davon abzuhängen wie die Seite aufgebaut ist und ob bereits Maßnahmen zur Verbesserung der Performance getroffen wurden.
Außerdem habe ich auf meiner Seite nach der Aktivierung Probleme mit dem HTML-Validator gefunden die vorher nicht da waren, durch die „Verbesserungen“ habe ich plötzlich ungültigen HTML-Code!
Hat jemand von Euch bereits Tests gemacht, was ist dabei herausgekommen?
==========================
Die Installation unter Ubuntu (32bit) ist denkbar einfach:
wget https://dl-ssl.google.com/dl/linux/direct/mod-pagespeed-beta_current_i386.deb dpkg -i mod-pagespeed-beta_current_i386.deb /etc/init.d/apache2 restart
Danach kann man die Konfiguration anpassen:
vi /etc/apache2/mods-enabled/pagespeed.conf
Meine ersten Ergebnisse:
Browser Cache deaktiviert Ohne Pagespeed: 51 Requests Firebug Netzwerk Tab: 4,64 3,79 3,5 3,8 3,81 PageSpeed 83/100 YSlow 81 Size 154,4KB Standard Konfiguration 50 Requests Firebug Netzwerk Tab: 4,69 5,13 5,91 4,99 6,3 PageSpeed 84/100 YSlow 82 Size 155,1KB Fast alle Filter aktiviert: 50 Requests Firebug Netzwerk Tab: 6,0 5,85 6,47 5,34 5,83 PageSpeed 83/100 YSlow 82 Size 154,9KB =============================================================== Browser Cache aktiviert Ohne Pagespeed: 18 Requests Firebug Netzwerk Tab: 3,2 2,7 2,9 2,8 2,85 PageSpeed 80/100 YSlow 81 Complete Size 59,5KB index size 12,3KB Standard Konfiguration 18 Requests Firebug Netzwerk Tab: 2,8 2,7 3,1 3,0 2,85 PageSpeed 80/100 YSlow 84 Complete Size 61,2KB index size 14,0KB Fast alle Filter aktiviert: 18 Requests Firebug Netzwerk Tab: 3,4 3,6 3,4 3,1 3,7 PageSpeed 80/100 YSlow 84 Complete Size 61KB index size 13,8KB
Huh? Die haben nie gesagt ohne Aufwand. Ganz so einfach kommst du nicht zu schnelleren Seiten.
Auf der Dokumentation der einzelnen Filter findet sich auch immer ein Abschnitt über potentielle Risiken: http://code.google.com/intl/de-DE/speed/page-speed/docs/filters.html
Ohne sorgfältiges Studium der Filter würde ich mod_pagespeed auch nicht einfach so einsetzen.
Ich habe selber noch nicht damit gespielt, aber ich denke ebenfalls, dass halbwegs sorgfältig gemachte Seiten nicht viel von mod_pagespeed profitieren.
Vielleicht bringt es etwas im Zusammenhang mit CMS-Software und ähnlichen. Beispielsweise erzeugt Typo3 mit einigen installierten Plugins unter Umständen nicht mehr so schönen HTML-Code (Inline-CSS, Inline-Javascript…).
christian
5 Nov. 10 at 08:20
Was genau ist denn am Code verändert worden, sodass er nicht mehr valide ist? Wurde etwas eingefügt, was evtl. sogar zu Google „nach Hause“ telefoniert oder was ist da passiert?
Philip
5 Nov. 10 at 10:02
Ein Filter, den ich aktiviert hatte, entfernte alle Anführungszeichen um Attributwerte, das fand der Validator garnicht so toll bei XHTML.
Ein weiterer Filter hat bei Bildern fehlenden „width und height“ Werte hinzugefügt, auch diese ohne Anführungszeichen.
Vielleicht wäre das mit HTML 4 TRANSITIONAL nicht passiert, ich weiß nicht bei welchem Standard er erlaubt ist, die Anführungszeichen unter Umständen wegzulassen.
Die Zeilen Javascript, die Google einfügt, um zu meinem Server zu „telefonieren“ und die Ladezeit zu melden (die eingebaute beacon/statistic Funktion) waren glaube ich fehlerfrei eingebaut.
Hier ein weiterer schöner Test:
http://www.online-solutions-group.de/blog/suchmaschinenoptimierung-seo/googles-mod_pagespeed-erster-praxis-test
Michael Kliewe
5 Nov. 10 at 10:21
Sieht ganz nett aus das Tool. Danke für den Hinweis. Ist das Modul wirklich von google oder wird es nur bei google code gehostet? Konnte die Info das irgendwie nicht finden.
Nils
5 Nov. 10 at 10:40
Ist direkt von Google, siehe Changelog:
http://code.google.com/p/modpagespeed/source/list
Michael Kliewe
5 Nov. 10 at 11:07
@Michael Kliewe: Das Weglassen der Anführungszeichen ist in HTML5 valide.
David Müller
5 Nov. 10 at 11:44
Ich habe das gestern auch einmal ausprobiert.
Das Ergebnis war ähnlich wie bei Dir. Der Blog hat noch länger geladen. Zudem war er auch kurzfristig nicht erreichbar – da kam nur eine weiße Seite zum Vorschein.
Google darf da ordentlich nachbessern.
Dann doch lieber einen ordentlichen Opcache installiert, bringt m. E. nach mehr.
Daniel
5 Nov. 10 at 14:08
Wann und wo hat Google denn gesagt, dass mod_pagespeed mal eben so einfach die Geschwindigkeit steigert?! Ich halte das für eine Fehlinterpretation, die im Einzelfall eben auch dazu führt, dass die Seite langsamer wird.
Google schreibt doch explizit in der Dokumentation: ‚With some experimentation, you can fine-tune the configuration to get the maximum benefit in terms of page performance.‘
Also, ohne ein wenig Anpassungsarbeit wird sich eine bessere Geschwindigkeit nicht von alleine ergeben.
Zara
5 Nov. 10 at 14:14
@Zara: „But we thought we could make it even easier — ideally these optimizations should happen with minimal developer and webmaster effort.“
http://googlecode.blogspot.com/2010/11/make-your-websites-run-faster.html
Mit der Installation sind ja bereits Standardeinstellungen aktiv, die sicher zu verwenden sind. Da das Modul ja dafür gedacht ist dass es auch Hoster einfach installieren und es dann jede Seite beschleunigt, macht es nicht so viel Sinn nun die Einstellungen genau auf eine Seite hin zu optimieren, gerade ein Hoster (wie „Go Daddy“ in dem Fall“) muss ja dafür sorgen dass es überall etwas bringt, er wird also sehr wahrscheinlich bei den Standardeinstellungen des Moduls bleiben, um höchst mögliche Kompatibilität zu gewährleisten.
Vielleicht ist das Fazit auch einfach dass die Standardeinstellungen noch nicht gut gewählt sind, aber eine Optimierung auf eine Seite hin ist nicht Sinn und Zweck des Moduls.
Michael Kliewe
5 Nov. 10 at 14:22
@Daniel: Opcode-Cache und Page-Filter sind zwei paar Schuhe.
KingCrunch
5 Nov. 10 at 17:29
Hi Michael,
aber was sagt denn an „should happen with minimal developer and webmaster effort“, dass immer eine Verbesserung per se eintritt?
Ich finde Deinen Test ja ganz ok, aber ich denke man sollte von solch einem Modul auch keine Wunder erwarten.
* „Vielleicht ist das Fazit auch einfach dass die Standardeinstellungen noch nicht gut gewählt sind“
Eben, „should happen“ und nicht „will happen“. Wie gesagt, ohne Anpassungen würde ich auch keine Wunder erwarten.
* „aber eine Optimierung auf eine Seite hin ist nicht Sinn und Zweck des Moduls.“
Sagst Du. Ich finde diesen Einsatzzweck durchaus Sinnvoll. Warum sollte das Modul denn für beliebige Webpräsenzen bei einem Massenhoster eingesetzt werden? Ich kann mir selber aber sehr gut vorstellen, das Modul genau auf eine Seite hin zu optimieren. Und wir sind auch gerade dabei es für eine stark frequentierte Seite zu testen. Beim Cheffe (und beim Kunden) haben wir schon mal nachgefragt, ob wir die Ergebnisse eventuell veröffentlichen dürfen. Falls ja, steuere ich sie gerne der Diskussion bei.
Zara
8 Nov. 10 at 17:10
@Zara: Das wäre natürlich spitze, je mehr Testergebnisse man hat, umso besser.
Es war ja auch nur ein erster Test mit Standardeinstellungen, schrieb ich ja auch. Ich habe auch nicht erwartet, dass bei einer bereits halbwegs optimierten Webseite noch viel rauszuholen ist. Zum selben Ergebnis sind auch andere Schnelltests gekommen.
Wer also bereits CSS+Javascript zusammenfasst + minified, gzip aktiviert hat und die Bilder durch optiPNG gejagt hat, hat schon die wichtigsten Maßnahmen von mod_pagespeed durchgeführt, der Rest ist nur Kleinkram (ungültigen HTML Code korrigieren und was es sonst noch so kann). Vor allem interessant ist das Modul für nicht optimierte Seiten von Leuten, die sie nicht optimieren können oder wollen. Und das ist eher bei Massenwebhostern der Fall als bei professionell erstellten Firmenwebseiten.
Wir können auch gespannt sein auf andere Maßnahmen, wie zB SPDY als Nachfolger für HTTP: http://www.chromium.org/spdy/spdy-whitepaper
Das soll auch bis zu 50% mehr Geschwindigkeit bieten. Ob es je Verbreitung findet ist die große Frage.
Michael Kliewe
8 Nov. 10 at 17:23
[…] Performance: Google will Webserver mit Apache beschleunigen. (Test dazu ») […]
Linkhub – Woche 44-2010 | pehbehbeh
8 Nov. 10 at 17:33
Das Modul hat meinen ganzen Server lahmgelegt… Bei Zugriff auf die Website meiner Kunden wurden unzählige Apache Prozesse gestartet…
Munin Screen von der letzten Woche, als das Modul aktiv war… http://img254.imageshack.us/img254/3131/bildschirmfoto20101111ux.png
Da muss noch ordentlich nachgebessert werden…
Jonas
11 Nov. 10 at 16:23
Hi, wird da echt ein Java Script von Google integriert?
Dominik
21 Nov. 10 at 14:28
Danke
sumasearch
14 Feb. 11 at 16:22
Und Google erfährt noch mehr über jeden einzelnen !
Ich trau den Brüdern nicht, und mir kommt das Modul auch nicht auf den Rechner !
Der Geschwindigkeits „vorteil“ (wenn den überhaupt einer da ist) ist so minimal das es in keiner Relation steht !
bodo
3 Juni 11 at 16:13
Inzwischen ist ja einige Zeit vergangen. Hat jemand Erfahrung, wie der aktuelle PageSpeed Mod sich gemausert hat?
Martin Nordensen
17 Juni 12 at 09:21
Grundsätzlich eine gute Idee. Greift aber an einer Stelle an, an der das Kind schon in den Brunnen gefallen ist. Ich ziehe es vor, Seiten so stark es geht zu cachen. Schließlich ändern sich die meisten Seiten zwischen zwei Aufrufen nicht. Damit kann man die Auslieferung zumindest des html-Teils der Webseite auch bei kleinen Shared-Hosting-Paketen in den unteren zweistelligen Millisekundenbereich drücken.
Klaus
18 Dez. 12 at 14:29
Ich habe das gestern auch einmal ausprobiert.
Das Ergebnis war ähnlich wie bei Dir. Der Blog hat noch länger geladen. Zudem war er auch kurzfristig nicht erreichbar – da kam nur eine weiße Seite zum Vorschein.
jacek@alkalische phosphatase
13 Dez. 13 at 07:41
[…] nicht so positiv aus wie es ursprünglich verkündet wurde. Teilweise wird sogar davon berichtet, dass der Aufbau der Seiten durch das neue Modul verzögert wird. Die Autoren vermuten, dass […]
mod_pagespeed - kaum Nutzen für Wordpress - Blogs optimieren | Blogs optimieren
2 Apr. 14 at 12:57
[…] “Ernüchternd” findet die Ergebnisse zum Beispiel Michael Kliewe, der das Ding sogleich getestet hat. Er schreibt in seinem Blog: […]
Googles neues <i>mod_pagespeed:</i> Tempogeber oder Bremser? - entwickler.de
22 Apr. 15 at 16:46