WordPress-Websites beschleunigen 4: ein Zwischenergebnis

In drei Artikeln vorher (hier, hier und hier) habe ich einiges beschrieben, wie man WordPress-Website beschleunigen kann. Das allermeiste ist logischerweise auch für andere Website gültig. Hier so ein kleines Vorher-Nachher-Bild.

Hier zuerst die Statistiken vor der Optimierung:

Vor den Optimierungen
Vor den Optimierungen

Links sind die Angaben, wenn ein Besucher zum ersten Mal kommt (leerer Cashe) und rechts ist das Ergebnis wenn der Besucher wieder kommt. Anschließend habe ich zwei einfache Änderungen in der .htacces-Datei durchgeführt und habe dieses Ergebnis erreicht:

Nach den Optimierungen
Nach den Optimierungen

Für diese recht ansehnliche Verbesserung sind folgende Code-Zeilen verantwortlich:

# mod_deflate (gzip) aktivieren
<FilesMatch "\\.(js|css|html|htm|php|xml)$">
SetOutputFilter DEFLATE
</FilesMatch>

# ExpiresHeader: verhindert bedingte GET-Anfragen
<IfModule mod_expires.c>
ExpiresActive on
ExpiresDefault "access plus 35 days"
</IfModule>

Der erste Block aktiviert auf dem Apachen 2 die Komprimierung (gzip) und es werden alle relevanten Dateitypen komprimiert. Sinnvoll ist eigentlich nur die Komprimierung der Textdateien, die Grafiken sind im Web eh schon komprimiert und man würde lediglich den Server um sonst bemühen wenn man versuchen würde auch die Bilder und Grafiken bei der Übertragung zu komprimieren.

Der zweite Block verpasst den Dateien im Cache eine zusätzliche Information. Üblicherweise entsteht bei gecashten Dateien trotzdem eine zusätzliche Kommunikation zwischen dem Browser und dem Server:

Browser:
Hallo Server, ich habe hier ein Bild im Cache. Bin mir nicht sicher ob es noch aktuell ist. Schaue mal bitte nach.
Server:
Lass mal schauen … OK, dass Bild ist noch 12 Tage lang gültig.
Browser:
Fein, dann kann ich das Bild direkt aus dem Cache laden.

Bei so einer “Kommunikation” handelt es sich um eine bedingte GET- bzw. HTTP-Anfrage, in der sich der Browser vergewissert, dass die gecachten Komponenten noch aktuell sind. Mit der Anweisung ExpiresDefault "access plus 35 days" sagen wir dem Browser: “Egal wann der Cache zum Einsatz kommt, aber alle Dateien in deinem Cache sind noch mind. 35 Tage lang gültig, lade Sie daher bitte direkt aus dem Cache”.

Ich habe hier vorher lediglich 21 Tage als Wert gehabt. Allerdings hat mir die neue Erweiterung von Google angemerkt, dass die zu kurz sei und das man einen Wert größer 30 Tage nehmen sollte.

Sicherlich, es gibt viel mehr Maßnahmen die man machen kann und dies auch schon im Vorfeld: CSS-Dateien schlank halten, “Entrümpelung” von unnötigem Code in den Themes, Grafiken verkleinern etc. Aber die oberen beiden Maßnahmen sind schnell erledigt, einmal gemacht und entfalten eine starke Wirkung.

Bei anderen Maßnahmen, wie z. B. alle CSS- und JS-Dateien zu jeweils einer verschmelzen um die HTTP-Anfragen zu minimieren, hat man in den Redaktionssystemen wie WordPress nicht immer die volle Kontrolle, speziell dann wenn man gut zwei Dutzend Plugins einsetzt.

Wir arbeiten seit 20 Jahren mit WordPress und bieten diverse Dienst­leistungen rund um das System an. Kontaktiere uns für weitere Informationen oder für ein Angebot.

Verwandte Beiträge:

23 Kommentare

  1. Die optimierung für neue Besucher ist ja nicht schlecht aber sind die meisten Browser nicht so eingestellt daß der Cache nach der Session geleert wird? Zumindest bei meinem Firefox ist das so und ich kann mich nicht erinnern daß ich da mal was umgestellt habe. Dürfte also der default Wert sein.

  2. @Matt
    Da hat Micha definitiv Recht, sonst würde das ganze Caching gar keinen Sinn machen, wenn der Browser diesen gleich wieder verwirft. Deswegen schreibt man dem Browser mit den oben genannten Angaben in der .htaccess auch die Gültigkeit von mindestens 35 Tagen vor.

  3. Hmm, vielleicht kannst du etwas Licht ins Dunkel bringen:

    Ich erweiterte meine .htaccess um deinen Codeschnipsel und es funktionierte im Firefox problemlos. Große Geschwindigkeitszuwächse konnte ich nicht feststellen, da auch ich mit Super Cache arbeite und zudem relativ wenig geladen werden muss. Ich ließ es trotzdem drin, könnte ja sein, dass ich mal einen Besucheransturm bekomme :mrgreen:

    Nun testete ich die Beta von Opera 10 (unter Linux) und bekam beim Öffnen meiner Seite angeboten, eine deflate.gz herunterladen zu können.

    Nach dem Auskommentieren der Codeschnipsel funktioniert die Webseite auch in Opera 10 beta wieder fehlerfrei.

    Hab ich etwas falsch gemacht? Liegts an Opera 10b? Deine Seite kann ich ohne Probleme aufrufen und auch bei anderen Seiten hab ich dies noch nicht entdeckt.
    Es wundert mich halt, dass meine Seite im Firefox problemlos funktionierte!?

  4. @Marc,

    ich habe jetzt meine Websites mit Opera 10 beta (Win Vista) getestet und alles bestens. Könnte das evtl. mit der Konfiguration deines Servers zusammenhängen so das Opera denkt “Oh, das ist was zum downloaden”?

    Evtl. mal den Hoster ansprechen.

  5. Das sollte das Y!Slow Addon für das Firefoxplugin Firebug sein.

    Danke für die Artikel, da ich auch gerade ein Projekt (kein Blog) optimiere werd ich die anderen Teile auch gleich mal lesen. … Den Schritt aus diesen Artikel habe ich bereits eingebaut und konnte auch eine massive Geschwindigkeitsverbesserung feststellen.

  6. Ich hab grad mal bei meinem Provider angefragt warum “mod_expires.c” nicht installiert ist, ich also “ExpiresDefault” nicht benutzen kann.
    Antwort:

    das Modul ist in der Tat nicht aktiv und kommt auch bei uns nicht im Einsatz.
    Die Traffic Ersparnis beläuft sich auf nahezu 0.
    Zum Beispiel ich habe meinen Browser so eingestellt, das er überhaupt nichts cached, sondern sich die Informationen immer neu holt. Das ist inzwischen bei sovielen Rechnern der Fall das es fast keinen Sinn macht soetwas überhaupt noch einzusetzen.

    Soviel dazu… 😉

    1. Ich würde mir an deiner Stelle einen besseren Provider suchen. Das Dateien gecached werden ist die Standardeinstellung und die aller wenigsten Browser-Nutzer verändern solche Sachen wie z. B. Cache, Javascript-Unterstützung oder verändern die Standardschriftgrößen.

  7. Wenn im letzten Satz ein “nicht” fehlt, geb ich dir recht. 😉
    Ich hab auch probiert die Bilder, durch ein PHP-Script zu schleusen und den Header anzupassen. Funktioniert auch, allerdings kommen dann einige Bilder nicht (oder vielleicht zu spät?) im Browser an. Merkwürdig.
    Aber die Sprits funktionieren super. Manchmal braucht man einfach einen Tritt. :mrgreen:

  8. Zum Beispiel ich habe meinen Browser so eingestellt,

    Und somit vertritt er genau 0,001% der Nutzerschaft, denn die meisten lassen die Browser-Einstellungen so wie die sind. Und das ist gut so.

  9. Ich würde Euch empfehlen, Eure htaccess folgendermaßen aufzubauen:

    #Force caching of some common files for some time in the browser's cache, to save bandwidth.
    #"Mod_expires" needs to be installed in your Apache server, to use this feature.
    <IfModule mod_expires.c>
    ExpiresActive On
    ExpiresDefault "access plus 1 minutes"
    ExpiresByType text/html "access plus 1 minutes"
    ExpiresByType text/css "access plus 1 months"
    ExpiresByType text/javascript "access plus 1 months"
    ExpiresByType text/plain "access plus 1 months"
    ExpiresByType application/x-javascript "access plus 1 months"
    ExpiresByType application/x-shockwave-flash "access plus 1 months"
    ExpiresByType image/gif "access plus 1 years"
    ExpiresByType image/jpeg "access plus 1 years"
    ExpiresByType image/jpg "access plus 1 years"
    ExpiresByType image/png "access plus 1 years"
    ExpiresByType image/x-icon "access plus 1 years"
    <FilesMatch ".*booster_mhtml\.php$">
    ExpiresActive Off
    </FilesMatch>
    </IfModule>
    #Alternative caching using Apache's "mod_headers", if it's installed.
    #Caching of common files - ENABLED
    <IfModule mod_headers.c>
    <FilesMatch "\.(ico|pdf|js|css|gif|png|jpg|jpeg|ico|txt|html|htm)$">
    Header set Cache-Control "max-age=2592000, public"
    </FilesMatch>

    Der obere Block entspricht (etwas ausformulierter) dem was Perun in seiner .htaccess macht, verwendet also mod_expires, so es denn angeboten wird.
    Der untere Teil stellt eine Alternative dar, die es mit einem mod_headers versucht. Dementsprechend könnte Tom dann diesen Teil nutzen. So sein Hoster denn mod_headers unterstützt.

    BTW: Selbst Strato unterstützt mittlerweile mod_expires!

    Den WordPress-Performance-Interessierten sei zu guter Letzt noch die aktuelle iX 07/2010 ans Herz gelegt, die diesbezüglich einen ganz interessanten Artikel enthält.

    Grüße in die Runde!

  10. Schepp, als Ergänzung würde ich noch dazu schreiben, dass man die Zeilen mit nicht verwendeten Dateitypen ruhig entfernen sollte, da jede Zeile eigene, auch wenn winzige Performance bei der Verarbeitung kostet. Hält man so nebenbei die htaccess sauber.

    Sonst top 😉

  11. Hallo Schepp,

    so weit ich mich erinnern kann, meckert Page Speed von Google alle Cachings an die Kleiner als 30 Tage + X sind. Daher meine Angabe von 35 Tagen.

  12. Vlad, diesen Hinweis (ist ja kein Fehler) mit weniger 30 Tagen ist mir auch aufgefallen. Allerdings hatte ich im Web nichts zu der Ursache gefunden (warum 30 Tage zu wenig sind). Daher hab ich den Wert auch nicht angepasst. Weiß jemand mehr?

  13. @Perun Ah, okay. Auf Google Pagespeed schaue ich nicht so drauf. YSlow reicht mir vollkommen und ist mit diesen Werten soweit zufrieden (und vor allem ich selbst). Aber klar, wenn es um den Googleschen Rankingfactor geht, dann sollte man es besonders dem Googleschen Tool Recht machen. Und wenn die 35 Tage wollen, dann serviere man ihnen 35 Tage 😉

  14. Hallo! Erstmal vielen Dank für die tolle Serie an Artikel, top.

    Ich habe beim Caching folgendes Problem:

    Aktiviere ich mod_expires, funktioniert dies auch laut Pagespeed. Nun habe ich in meinem Blog einen neuen Artikel veröffentlicht, dieser wurde jedoch bei Aufruf der Hauptseite nicht angezeigt (=zieht die Cache-Version). Drücke ich strg + F5, wird die Seite komplett neu geladen und der neue Artikel wird auch angezeigt.

    Ist das so richtig? Für Stammleser könnte dieser Effekt natürlich sehr ärgerlich sein “ahh, schon wieder nichts neues :mrgreen:”. Habe ich bei meinen Einstellungen etwas falsch gemacht? Ich habe o.g. Code in die htaccess gepackt und in das Hauptverzeichnis meines Servers kopiert…

    Freue mich auf euer Feedback.

Kommentare sind geschlossen.