Ein paar Gedanken aussem Ländle

Page-Speed-Probleme mit CSS-Dateien von Textpattern

Wie man von einem Problem erfährt …

Unter den Google Webmaster-Tools befindet sich „Page-Speed“. Dazu erklärt Google:

Google ist bestrebt, seinen Nutzern möglichst relevante Suchergebnisse und eine großartige Nutzererfahrung zu bieten. Schnelle Websites erhöhen die Zufriedenheit der Nutzer und verbessern die Gesamtqualität des Webs, insbesondere für Nutzer mit einer langsamen Internetverbindung. Wir hoffen, dass Webmaster durch die Verbesserung ihrer Websites auch zu einem insgesamt schnelleren Web beitragen.

Diese Überlegung ist nachvollziehbar. Es ist mit ein Grund, warum ich selbst damals mehr auf Textpattern setzte und weniger auf das bekanntere Wordpress. Textpattern ist schnell und die Autoren von Texpattern sind daran interessiert, dass es so bleibt. Das ist aber ein Grund mehr, dass mich die Warnungen von PageSpeed gestört haben, und das ohne dass mir zunächst einmal klar war, was sie besagen sollten.

Beginnen wir mit den Vorschlägen, die Page-Speed gemacht hat am Beispiel einer einzigen URL, hier die URL http://devsup.de/artikel/sennheiser-cx-400-philips-she-9501-kopfhoerer, die auf den Beitrag Sennheiser CX 400 oder Philips SHE 9501 – die Vorüberlegungen zeigt.

Vorschläge von Page Speed
bq. Dies sind einige Beispielseiten Ihrer Website sowie einige Vorschläge, wie Sie diese optimieren können. Diese Informationen basieren auf dem Page Speed-Tool.

Und dann gibt es für diese URL ein paar Einträge. Diese sind von oben nach unten zu lesen mit dem Hintergedanken: Bitte nachdenken, ob man bei folgendem etwas sparen könnte. Doch ließt man diese Liste durch, dann kann man zunächst einmal nichts sparen. Gut, wir haben wir zwei CSS-Dateien und die könnte man sehr gut als eine Datei ausliefern, dann haben wir 2 DNS-Lookups, einen für Google-Analytics und einen für AdSense und hier kommt man wieder ins grübeln, den hier könnte höchstens Google optimieren und beide Zugriffe über eine url regeln, wenn PageSpeed resp. Google meint, dass hier etwas zu optimieren sei.

Dann ließt man wieder etwas über zuzuschaltender gzip-Option oder Komponente, das aber ist etwas, dass Browser und Server unter sich ausmachen.

In den Anmerkungen wird gesagt:
bc. Im Durchschnitt benötigen Seiten auf Ihrer Website 2,0 Sekunden zum Laden (aktualisiert am 31.12.2009). Dies ist schneller als 68 % der Websites. Das folgende Diagramm zeigt an, wie sich die durchschnittliche Ladezeit Ihrer Website in den letzten Monaten verändert hat.

Die Werte 2.0 Sekunden und schneller als 68% der Websites meint “nach den folgenden Änderungen”. Ich habe mir den vorherigen Wert nicht gemerkt, aus der Erinnerung waren es etwa 4 Sekunden und 50%. Wir sprechen also nicht über „Katastrophen“, wir sprechen über Feintuning.

Der Websniffer

Es gibt eine Reihe von installierbaren Tools, mit der die folgenden Tests lokal durchgeführt werden können. Von den möglichen Optionen und vor allem von der Technik her gefällt mir der das externe Angebot , der Websniffer am besten. Wie die lokalen Komponenten auch aussehen, sie müssten eine Checkbox haben mit der Funktionalität „Accept-Encoding“, also sie müssten einem Browser erlauben oder verbieten können gzip zu akzeptieren.

Der Websniffer ist eine Webseite – also der text http://web-sniffer.net/ steht in der URL des eigenen Browsers. In der Webseite selbst gebe ich als „zu besuchende Seite“ http://devsup.de/ an. Damit wird der Websniffer zu einem „Man in the Middle“ er kann nun meine Nachrichten untersuchen und ggf. verändern und er kann die Antworten von meine Webseite ändern resp. ergänzen.

Erste Schritte mit gZip

Im ersten Schritt gilt also zu klären, ob der Webserver gzip einsetzt oder nicht. Im folgenden Screenshoot ist die URL eingetragen meiner Startseite, und die Checkbox Accept-Encoding ist aktiviert.

Man kann wechselweise die Checkbox setzen und löschen und dabei die Abfage wiederholen. Man wird sehen, dass sich die Änderungen in den roten Feldern der folgenden beiden Bilder bemerkbar machen.

Das erste Bild zeigt die Daten des sogenannten HTTP-Request-Headers. Das ist eine kleine Datei, die im Normalfall von meinem Browser zum Server geschickt wird, um diesen zum Versand der „Startseite“ aufzurufen. Wichtig ist: Mit gesetzter Checkbox „Accept-Encoding“ wird die Zeile „Accept-Encoding: gzip“ an den Server weiter gesendet, ohne diese Checkbox fehlt die Zeile. Damit wird dem Server ein uralter Browser simuliert, der zu gzip unfähig ist.

Diese Anfrage löst das Absenden des HTTP-Response-Headers aus. Das ist eine kleine Datei, die vom Server zum Browser geschickt wird unmittelbar vor der eigentlichen Datei. Dieser hat nun drei Einträge, die näher zu betrachten sind.

Der Eintrag „Vary:Accept-Encoding“ wird immer gesetzt, auch wenn nicht „Encoded“ wird. Es ist aber an der Stelle eher ein „ich würde ja, wenn du könntest“. Es wenn das Encoding aktiviert wird, erst dann erscheint die beiden folgenden Zeilen. „Content-Encoding: gzip“ weist hin auf die Verwendung des Kompressionsverfahrens und „Content-Length:3802“ gibt die Dateigröße an, die im Anschluss gesendet wird.

Im Screen-Shoot des Response-Headers ist ganz unten noch die Überschrift zum nächsten Kapitel zu sehen. Die ist der einfachheit halber im gleichen Bild belassen worden. Wir sehen an der Überschrift, die der Websniffer anzeigt: Die Datei wurde von 12,64 KiB auf 3,71 KiB komprimiert, gesendet und dann wieder dekomprimiert. Das gzip-Kompressionsverfahren funktioniert also zwischen Browser und Server.

Zusammenfassung: Wir haben gesehen, wie die Kompression funktioniert und wir haben gesehen, dass sie bei Textpattern funktioniert. Nur: PageSpeed von Google moniert ja nicht die html-Dateien an, sondern die CSS-Dateien und dort funktioniert dieser Mechanismus nicht, wie man leicht nachprüfen kann, wenn man http://devsup.de/textpattern/css.php?n=default in den Websniffer einfügt.

Die Suche nach dem idealen schönen guten und wahren.

Nun ist es ja regelmäßig so, dass man – so man irgend etwas entdeckt hat – ein anderer schon vor einem da war. Also googelt man ein wenig nach dem Problem. Man findet dann, dass um 2005 herum die gzip-Option in Textpattern (http://textpattern.kbbu.de/plugin/speed-up-textpattern) eingeführt wurde, man findet außerhalb von Textpattern auch eine Diskussion, ob man css und js-Dateien nicht auch zippen könne und es werden sogar Vorschläge gemacht, wie das über einfache .htaccess-Anweisungen getan werden kann (http://www.alinki.com/de/blog/archives/27).

Doch noch ein weitere Punkt an der Stelle ist von Bedeutung. CSS-Dateien sind in der Regel für den gesamten Webauftritt gültig. Jede Unterseite greift auf die gleiche CSS-Datei zurück und so kann man beim einfachen Klick auf eine andere Unterseite einfach auf die bisherige Datei zurückgreifen. Dieses Caching ist im Grunde sogar wichtiger als das gzip.

Mit dem bisher Geschriebenen kann man noch nicht viel anfangen. Wenn ich wirklich eine Verbesserung finden will, dann muss ich sie inhaltlich konkretisieren oder eben nachsehen, wie es andere tun.

Für das „Nachsehen“ ist nun eine Eigenschaft von Textpattern klar relevant:

RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^(.+) - [PT,L]

Hier wird ein Rewrite definiert für genau den Fall, für den eine URL nicht einem Dateinamen zugewiesen werden kann. Das bedeutet:

http://devsup.de/textpattern/css.php?n=default ist ein Aufruf einer tatsächlich vorhandenen Datei css.php mit dem Parameter n=default. Damit wird diese Datei aufgerufen. http://devsup.de/xxx ist ein Aufruf einer nicht existierenden Datei. Dieser Aufruf wird an http://devsup.de/index.php weiter geleitet und da das Texpattern damit auch nichts anfangen kann wird die Errorpage angezeigt. Und http://devsup.de/artikel/sds-plus-quick schließlich ist der Aufruf einer nicht existierenden Datei, dem aber die index.php die Ausgabe (http://devsup.de/artikel/sds-plus-quick SDS (Hilti), SDS-Plus (Bosch) und SDS-Quick Bohrer – eine kleine Übersicht) zuordnen kann.

Mit diesem Wissen gehe ich mit dem Browser in die Textpattern-„Datei“ http://devsup.de/textpattern/css.php?n=default und kopiere alles heraus und speichere dies in einer Datei default.css. Diese lade ich hoch auf den Server nach http://devsup.de/css/ und dort habe ich dann unter http://devsup.de/css/default.css einen Zugriff auf ein echte Serverdatei, die unter Kontrolle des Webservers Apache steht. Dann machen wir folgendes

1. Wir tragen die URL http://devsup.de/css/default.css in den Websniffer ein
2. Wir akzeptieren gzip
3. Das gzip-Signal steht im HTTP-header
4. Das gzip wird nicht bestätigt, statt dessen wird mit „Accept-Ranges: bytes“ auf eine Zählgröße hingewiesen und dann mit „Content-Length: 11412“ die Dateigröße angegeben.
5. Ganz zum Schluss wird klar: Auch der Apache zipped die css Dateien nicht. Er überträgt sie maximal etwas komfortabler, in dem er angibt, dass er 11412 bytes senden wird.

Doch an der Stelle fällt etwas weiteres auf, der Apache cacht.

Der Apache fügt jeder Datei die Tags „Last-Modified: datum“ und „Etag: checksumme“ hinzu. Und damit kann der Browser nach dem Senden des Headers entscheiden, dass er diese Datei nicht noch einmal herunter laden möchte. Erst wenn man etwas ändert – oder wenn der Browser die Datei inzwischen gelöscht hat, muss er „nachbestellen“.

Die Folgen für Textpattern.

Textpattern ist in der Tat – jedenfalls nach Page-Speed deutlich schneller, wenn man – wie hier im Workaround gezeigt – die CSS-Datei erst einmal auslagert und sie als Datei vom Apachen ausliefern läst, wobei man an dieser Stelle auch die .htaccess nutzen kann und sollte, um die CSS-Dateien zu zippen. Bei Javascript müsste man es ja ohnehin so machen.

Für Textpattern ergibt sich die Wunschliste nach

1. Last-Modified-Tag im HTTP-Response-Header einer CSS-Datei
2. Etag: im HTTP-Response-Header einer CSS-Datei
3. Gzip-Auslieferung der css-Datei.

Weitere Infos im Textpattern-Forum

_

— Wolfgang Uhr · Mittwoch Januar 6, 2010

Kommentare

Hinweise zur Kommentareingabe

Merken

Name


E-Mail


Web


Nachricht