Mit ModPagespeed den Webseiten-Turbo einschalten

Wer seine Website ordentlich designt hat, kann mit ModPagespeed auch nichts verbessern sondern verschlechtert die Performance sogar. Falsch! Oder zumindest teilweise falsch. Grundsaetzlich ist es natuerlich richtig, dass ein zusaetzliches Modul auch zusaetzlich Zeit frisst. Andererseits ermoeglichen sich mit ModPagespeed ein paar Optimierungen, die auch der beste Designer nicht leisten kann. Etwa die mehr oder minder gezielte Auslagerung der Daten ins schnelle RAM. Eine Option, vor der Systemadmins nicht nur aus Kostengruenden eher zurueckschrecken.

Eine komplette Website im RAM zu halten – nicht nur auf schnelleren SSD-Platten – verbietet sich schon wegen der damit potenziell verbundenen Datenverluste. Da blieb bisher allenfalls das Aufsetzen eines reverse Proxy, der seinen Cache im RAM haelt. Auch das hat seine Tuecken, aber es ist ein vertrautes Bild fuer das, was ModPagespeed sogar bei peinlichst genau optimierten Seiten zu leisten vermag. Und spaetestens seit Google angekuendigt hat, auch die Performance ins Ranking einer Website einfliessen zu lassen, ist die Ladezeit einer Webseite nicht nur entscheidend um die Absprungrate von Besuchern moeglichst gering zu halten. Es ist auch eine Frage, wieviel neue Besucher die Website ueberhaupt finden werden. Das Google, auf dessen Initiative letztlich ModPagespeed zurueck geht, dies kuenftig noch mehr gewichten wird, sollte spaetestens seit das Modul im am 10.Oktober aus dem Beta-Status raus ist (http://googlewebmastercentral.blogspot.de/2012/10/make-web-faster-with-modpagespeed-now.html) wohl klar sein. Dass andere SUMAs gleichziehen werden, ist schon fast ein Naturgesetz 😉 Höchste Zeit also, sich mit ModPagespeed mal naeher zu befassen

Ich habe eine Demo-Seite gebaut, mit der Ihr die Unterschiede testen koennt.

Grundsaetzlich funktioniert ModPagespeed wie ein Proxy-Server, der allerdings auch noch einiges an automatischen Optimierungen des Contents zu bieten hat. Der Ablauf beim ersten Aufruf einer Seite laeuft wie folgt ab

Client -> Apache-Webserver -> ModPageSpeed -> Webserver -> ModPagespeed Optimierer -> Apache-Webserver -> Client

Wie unschwer zu erkennen ist, sind da ein paar Verarbeitungsschritte hinzu gekommen. Und das kostet natuerlich Performance. Beim zweiten Aufruf der Seite sieht es dann aber schon ganz anders aus.

Client -> Apache-Webserver -> ModPageSpeed optimierter Content -> Apache-Webserver -> Client

Wie sinnvoll der Einsatz ist, haengt also davon ab, ob der optimierte Content mindestens die zusaetzlichen Verarbeitungsschritte ausgleicht. Bei unseren Test mit einer Dummy-Seite und den Default-Einstellungen bekamen wir folgende Werte

Also etwa 22 Prozent weniger Traffic. Das ist schon ganz schoen, aber noch nicht berauschend. Andererseits ist das schon ein sehr beachtlicher Performance-Schub, wenn man bedenkt, dass dafuer lediglich ein Modul aktiviert werden musste und kein Webdesigner tagelang von Hand mit der Optimierung befasst war! Die hier gesparte Zeit kann der Designer dann ja vielleicht gemeinsam mit dem Webmaster fuer die Optimierung von ModPagespeed verwenden. Denn dann kann sowas dabei rauskommen:

87 Prozent eingespart ohne sichtbare Änderungen an der Webseite. Das bedeutet fast eine Verzehnfachung der Performance! Okay das war zugegebenermassen auch eine ziemlich fette Dummy-Seite, die noch kein Webdesigner optimiert hatte. Trotzdem ist das Ergebnis schon beeindruckend. Nicht nur, wer im tiefsten Walde sitzt und mittels Akustikkoppler (http://de.wikipedia.org/w/index.php?title=Datei:Akustikkoppler_CCC_Datenklo.jpg) surft, wird sich darueber freuen koennen. Zumindest steigert unnoetiger Traffic nicht wirklich das Wohlbefinden. Warum ihn dann also durch die Leitungen blasen?

ModPagespeed vorab mal testen

Wer jetzt noch nicht ueberzeugt ist, dass ModPagespeed eine prima Erfindung ist, der sollte vielleicht einfach mal den Online-Test mit seiner eigenen Website machen. Wie der funktioniert, ist unter https://developers.google.com/speed/docs/pss/tryit beschrieben. Wer sich fuer die Details nicht interessiert, kann aber auch gleich zu http://www.webpagetest.org/compare springen.

Wen das noch nicht von den Vorteilen von ModPageSpeed ueberzeugt, der hat sich vielleicht vom seinem ganz subjektiven Empfinden hinter die Fichte fuehren lassen. Es kann also nicht schaden, die Geschwindigkeit der beiden Varianten zu messen. Zum Beispiel mit dem Thunderbird-Addon Lori (https://addons.mozilla.org/de/firefox/addon/lori-life-of-request-info/ = lori = life-of-request info). Auch ModPageSpeed liefert einiges an Zahlen. Falls statt Statistiken nur Fehlermeldungen erscheinen, sind bei der Website vielleicht die URLs umgebogen, was CMS ja gern machen. Dann einfach in der entsprechenden .htaccess eine kleine Erweiterung vornehmen. Bei WordPress zum Beispiel

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !^/mod_pagespeed


Ausserdem haben wir beim Test feststellen muessen, dass sich einige Module im Admin-Bereich von WordPress nicht wirklich mit ModPageSpeed vertragen. Aber letztlich geht es ja vor allem um Performance-Optimierung fuer die Besucher der Seite und nicht fuer deren Admins 😉 Bevor jetzt aber mit der grossen Keule

ModPagespeed off

in einer /wp-admin/.htaccess zugeschlagen wird, tut es vielleicht auch das deaktiviren einzelner Optimierungen. In unseren Tests bei mehr als 50 WordPress-Blogs mit verschiedenen Kombinationen von Plugins fuehrte

# rewrite_css raus, weil sonst Artikeluebersicht nicht funktioniert
ModPagespeedDisableFilters rewrite_css
# rewrite_javascript raus, weil der visuelle Editor sonst nicht funktioniert
ModPagespeedDisableFilters rewrite_javascript


zum Erfolg. Das geht wie bei allen Filtern von ModPageSpeed uebrigens auch kuerzer mit

ModPagespeedDisableFilters rewrite_css,rewrite_javascript


Ob eine Webseite mit ModPagespeed funktioniert, laesst sich uebrigens auch erstmal gefahrlos testen mit

http://example.com/index.htm?ModPagespeed=on&ModPagespeedFilters=rewrite_css

Das ist natuerlich ziemlich muehsam und beim mancher Software fast unmoeglich, wenn man sich ein umfassendes Bild verschaffen will. Also lieber flott einen Server erweitert. Das ist recht unkompliziert zu bewerkstelligen. Wer keinen Testserver bei uns hat und ModPagespeed erstmal auf einer eigenen Testinstallaion ausprobieren moechte, findet folgend das entsprechende Kochrezept.

ModPagespeed installieren

1.) ggf. muss etwas Software nachinstalliert werden (gperf, git, subversion). Wenn es trotzdem noch klemmt, hilft vielleicht ein Blick auf die vollstaendige Liste unter https://developers.google.com/speed/docs/mod_pagespeed/build_from_source?hl=de

2.) memcached-Server installieren, falls nicht ohnehin schon fuers Session-Management eingerichtet

3.) nun geht es los 😉 Als root geht es nicht. Also erstmal einen beliebigen Useraccount fuer die Installation nehmen.

mkdir -p ~/bin
cd ~/bin
svn co http://src.chromium.org/svn/trunk/tools/depot_tools
git clone https://chromium.googlesource.com/chromium/tools/depot_tools.git
export PATH=$PATH:~/bin/depot_tools
mkdir mod_pagespeed
cd mod_pagespeed
gclient config http://modpagespeed.googlecode.com/svn/branches/latest-stable/src
gclient config https://github.com/pagespeed/mod_pagespeed.git --unmanaged --name=src
git clone https://github.com/pagespeed/mod_pagespeed.git src
cd src
git checkout latest-stable
git checkout master
cd ..
gclient sync --force --jobs=1
cd src/
make BUILDTYPE=Release mod_pagespeed_test pagespeed_automatic_test


su irgendeinuser
cd ~
git clone https://chromium.googlesource.com/chromium/tools/depot_tools.git
export PATH=$PATH:~/depot_tools
git clone -b latest-stable --recursive https://github.com/pagespeed/mod_pagespeed.git
cd mod_pagespeed/
python build/gyp_chromium --depth=.
make BUILDTYPE=Release mod_pagespeed_test pagespeed_automatic_test
./out/Release/mod_pagespeed_test
./out/Release/pagespeed_automatic_test


make BUILDTYPE=Release
cd install/

chmod 755 install_apxs.sh
APXS_BIN=/opt/3uu/apache/bin/apxs ./install_apxs.sh

# ist okay, das mit diesem User aufzurufen
# das Skript fragt nach dem root-Passwort

APXS_BIN=/opt/3uu/apache/bin/apxs ./install_apxs.sh

An der Stelle braucht es das Passwort von root, um die Konfiguration des Indianers anzupassen. Das laesst sich aber auch spaeter noch erledigen. Mit einem „Installation succeeded.“ ist alles gut und der Apache muss nur durchgestartet werden. Aber besser erstmal die Konfiguration wie weiter unten beschrieben anpassen.

# Den Teil brauchen wir nur aus Tradition oder wenn mal nicht memcached eingerichtet
# ist bzw. Dateien groesser 1 MB gehandelt werden. Das ist ein selten doofes Limit
# der memcache-Implementierung, weil so doch wieder bei gebalancten Installationen
# etwas wie NFS gebraucht wird.
mkdir /vol/mod_pagespeed
chmod g+w /vol/mod_pagespeed/*
chgrp sshchroot /vol/mod_pagespeed/ -R

### Nach dem Start
cd /vol/mod_pagespeed/
chmod g+w *

So, nun noch den Indianer konfigurieren. Da wir es uns fuer einzelne Vhosts optional zuschalten wollen, erledigen wir die grundlegenden Sachen global, setzen ModPageSpeed aber auf „off“.

ModPagespeedFileCachePath "/vol/mod_pagespeed/cache/"
ModPagespeedMessageBufferSize 100000
# standardmaessig schalten wir es off und aktivieren es dann
# spaeter bei dem Vhost, den wir entsprechend testen wollen.
ModPagespeed off
# Attempt to load mod_version if it wasn't loaded or compiled in (eg on Debian)

LoadModule version_module /opt/3uu/apache/modules/mod_version.so

LoadModule pagespeed_module /opt/3uu/apache/modules/mod_pagespeed.so

Den Pfad zum Modul-Verzeichnis ggf. noch anpassen. Jetzt koennen wir uns um den VHost kuemmern.

ModPagespeed on
ModPagespeedFileCachePath "/vol/mod_pagespeed/cache/"
# hier statt 192.168.178.188 natuerlich die IP Eures memcached
ModPagespeedMemcachedServers 192.168.178.188:11211
# Deal with the Pagespeed mappings
ModPagespeedDomain http://*example.com
# Map it to request all through the local machine name
ModPagespeedMapOriginDomain www.example.com *example.com
# And tell it to load all static stuff from the filesystem not HTTP
ModPagespeedLoadFromFile http://www.example.com/ /vol/www/example.com/htdocs/
# Remove the header - no reason to publish it
Header unset X-Mod-Pagespeed
AddOutputFilterByType MOD_PAGESPEED_OUTPUT_FILTER text/html
ModPagespeedEnableFilters rewrite_javascript,rewrite_css,collapse_whitespace,elide_attributes,add_instrumentation,rewrite_images
# Bound the number of images that can be rewritten at any one time; this
# avoids overloading the CPU. Set this to 0 to remove the bound.
ModPagespeedImageMaxRewritesAtOnce 0
# Jpeg recompression quality (0 to 100, -1 strips metadata):
ModPagespeedJpegRecompressionQuality -1
# You can turn this off to let mod_pagespeed rename all JS files.
ModPagespeedAvoidRenamingIntrospectiveJavascript on

<Location /mod_pagespeed_beacon>
SetHandler mod_pagespeed_beacon
</Location>

<Location /mod_pagespeed_statistics>
SetHandler mod_pagespeed_statistics
</Location>

So, nun den Indianer neu starten und gluecklich sein 😉 Aber Achtung: Die erste Konfigurationsanweisung sorgt dafuer, dass der Besucher ein kleines Stueck JS bei jeder Seite mitgeliefert wird, dass entsprechende Daten an den Server liefert. Moeglicherweise ist das ja nicht bei jeder Seite gewollt.