WordPress & Webwork

Ladezeit-Optimierung: Caching bei (WordPress-) Websites verbessern

Im folgenden Artikel wird erklärt, wie man mit einfacher Anpassung am Caching-Verhalten die Ladezeit einer (WordPress-) Website deutlich verbessern kann

Wer mich kennt oder etwas länger Beiträge auf perun.net liest, der wird mitbekommen haben, dass ich die kleinen, einfachen Lösungen bevorzuge, die eine starke Wirkung entfalten. So eine Lösung in Bezug auf die Optimierung der Ladezeiten der Websites ist das verbesserte Caching.

Worum geht es genau?

Über diesen Vorgang habe ich hier im Weblog bereits an mehreren Stellen geschrieben, aber dennoch wird es von vielen unterschätzt.

Kommt ein Besucher zu wiederholten Mal auf deine Website, so hat er zwar diverse Dateien von deiner Website im Cache, aber die werden nicht direkt aus seinem Browser geladen sondern es findet dennoch eine Kommunikation zwischen dem Browser des Besuchers und deinem Webserver statt. In dieser Kommunikation wird abgeklärt ob die Dateien noch aktuell sind und ob der Browser sie aus seinem Cache oder doch vom Server herunterladen soll.

Diese zusätzliche Kommunikation auch bedingte GET-Anfragen genannt sind zusätzliche und in der Regel unnötige http-Anfragen. Die Performance-Optimierung einer Website besteht nicht nur aus Verringerung der Gesamtgröße aller übertragenen Quellen sondern auch die Verringerung der http-Anfragen, da die Browser nur eine begrenzte Anzahl an http-Anfragen gleichzeitig verarbeiten können.

Mit dem folgenden Code, den du am besten an das Ende der .htaccess-Datei einfügst löst man das Problem:

# Caching verbessern
<FilesMatch "\.(ico|jpg|jpeg|png|gif|js|css|swf|svg|eot)$">
ExpiresActive on
ExpiresDefault "access plus 35 days"
Header unset ETag
FileETag None
</FilesMatch>

Mit dem oberen Code weist du den Browser deines Besuchers, dass sofern er, die in der Zeile spezifizierten Dateitypen, im Cache hat, diese direkt aus dem selbigen lädt ohne noch einmal mit dem Webserver zu kommunizieren.

Die Anweisung ExpiresDefault "access plus 35 days" sagt dem Browser: "Egal wann der Cache zum Einsatz kommt, alle Dateien dieser Website in deinem Cache sind noch mind. 35 Tage lang gültig, lade Sie daher bitte direkt aus dem Cache".

In der folgenden Abbildung sieht man die Auswirkung des oberen Code auf einer Website. Oben sind die Angaben vor dem Einfügen des Codes und darunter nach dem Einfügen des Codes:

Caching bei WordPress-Websites verbessern

Wie man aus der Abbildung sieht ist die Wirkung ordentlich. Von einer solchen Maßnahme profitieren alle Websites egal ob statisch oder mit einem CMS betrieben. Aber ich denke, dass vor allem WordPress-Websites, die durch diverse Themes und Plugins, über viele zusätzliche referenzierte Quellen verfügen, um so mehr von einer solchen Anpassung profitieren.

Das Diagramm habe ich mit den Entwickler-Tools aus der Firefox Developer Edition erstellt.

Hierbei will ich noch einmal anmerken, dass von dieser Anpassung nur wiederkehrende Besucher profitieren und das der obere Code auf Apache 2 funktioniert. Nutzer von ngnix oder ISS finden u.a. hier und hier die entsprechenden Angaben.

Nachteile der Lösung

Wie auch bei den Medikamenten, so auch bei solchen Lösungen. Keine Wirkung ohne eine mögliche Nebenwirkung. Der Haken ist, dass der Besucher zum Beispiel die alte CSS-Datei aus dem Cache lädt, obwohl du bereits Änderungen an der selbigen durchgeführt hast. Abhilfe könnte es schaffen, dass du entweder bestimmte Dateitypen aus dem oberen Code heraus nimmst, oder wenn deine Website sagen wir mal über mehrere CSS-Dateien verfügst und du nur an einer des öfteren Änderungen durchführst, dass du diese mit einem URL-Parameter versiehst, den du bei jeder Änderung anpasst, zum Beispiel:

.../style.css?v=123

Dateien mit ? in der URL werden nicht gecacht. Das ist nicht unbedingt die eleganteste Lösung, aber sie erreicht Ihren Zweck. Eine Alternative findet man in diesem Artikel.

Nachtrag: in den Kommentaren hat man mich darauf hingewiesen, dass man auch eine Abfrage einbauen sollte ob das Modul auch von dem Webhoster aktiviert wurde. Hier noch einmal der obere Code, der allerdings zuerst prüft ob das Modul aktiv ist um um 500er Fehlermeldungen zu vermeiden:

<FilesMatch "\.(ico|jpg|jpeg|png|gif|js|css|swf|svg|eot)(\.gz)?$">
    <IfModule mod_expires.c>
        ExpiresActive On
    </IfModule>
    <IfModule mod_headers.c>
        ExpiresDefault "access plus 35 days"
        Header unset ETag
    </IfModule>
    FileETag None
</FilesMatch>

14 Reaktion(en)

  1. Daniel

    Hallo Vladimir,

    toller Tipp, der bei mir zu einer merklichen Verbesserung geführt hat. Vielen Dank.

    Vielleicht solltest Du den Hinweis von Jens oben noch aufnehmen, welche Module aktiviert sein müssen. Auf meinem Plesk/Odin V-Server musste ich mod_expires aktivieren. Vorher hatte ich den 500er Fehler.

    vg, Daniel

    1. Vladimir

      Hallo Daniel,

      danke für den Hinweis. Da ich bei Kunden schon seit längerem keine solche Meldung hatte, bin ich davon ausgegangen, dass die mittlerweile standardmäßig aktiv ist. Zumal mir in den letzten Wochen und Monaten aufgefallen, dass diverse Webhoster automatisch die Seiten komprimiert ausliefern. Daher ging ich davon aus, dass solche Fehlermeldungen der Vergangenheit angehören.

  2. Pingback: Der heiße Scheiß der Woche (063) - matterne.eu

  3. Pingback: Monatsrückblick September und Oktober - Habutschu!

  4. Bernhard

    Ganz optimal scheint die Einstellung aber nicht zu sein. Denn wenn sie es wäre, würde der Browser nicht nur auf einen erneuten Download der Dateien verzichten (da sie unverändert sind), sondern sie gar nicht erst anfragen.

    Bist du sicher, dass der Screenshot zu der Einstellung passt?

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

✉ WordPress-Newsletter ✉

Tipps und News als E-Mail in deinem Postfach? Dann abonniere einfach den ersten deutsch­sprachigen Word­Press-Newsletter:


Der Newsletter ist hinterher jederzeit abbestellbar.

Eintragen!