PHPGangsta - Der praktische PHP Blog

PHP Blog von PHPGangsta


Test von Googles neuem Apache Modul mod_pagespeed

with 23 comments

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

Written by Michael Kliewe

November 5th, 2010 at 12:32 am

23 Responses to 'Test von Googles neuem Apache Modul mod_pagespeed'

Subscribe to comments with RSS or TrackBack to 'Test von Googles neuem Apache Modul mod_pagespeed'.

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

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

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

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

  5. Ist direkt von Google, siehe Changelog:

    http://code.google.com/p/modpagespeed/source/list

    Michael Kliewe

    5 Nov 10 at 11:07

  6. @Michael Kliewe: Das Weglassen der Anführungszeichen ist in HTML5 valide.

    David Müller

    5 Nov 10 at 11:44

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

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

  9. @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

  10. @Daniel: Opcode-Cache und Page-Filter sind zwei paar Schuhe.

    KingCrunch

    5 Nov 10 at 17:29

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

  12. @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

  13. […] Performance: Google will Webserver mit Apache beschleunigen. (Test dazu ») […]

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

  15. Hi, wird da echt ein Java Script von Google integriert?

    Dominik

    21 Nov 10 at 14:28

  16. Danke

    sumasearch

    14 Feb 11 at 16:22

  17. 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 Jun 11 at 16:13

  18. Inzwischen ist ja einige Zeit vergangen. Hat jemand Erfahrung, wie der aktuelle PageSpeed Mod sich gemausert hat?

    Martin Nordensen

    17 Jun 12 at 09:21

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

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

  21. […] 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 […]

  22. […] “Ernüchternd” findet die Ergebnisse zum Beispiel Michael Kliewe, der das Ding sogleich getestet hat. Er schreibt in seinem Blog: […]

  23. Wahnsinnig guter Content! Danke dafür!

    seo agency

    21 Jun 21 at 22:13

Leave a Reply

You can add images to your comment by clicking here.