Auch Entwickler brauchen Platz zum Spielen

21. Juli 2014 /

Cachify: Smartes, effizientes Caching-Plugin für WordPress

Cachify ist das ausgereifte, kostenlose Caching-Plugin für WordPress, welches die Blog-Performance steigert und Datenbankanfragen reduziert.
Cachify für WordPress

Mit zunehmender Anzahl an dynamischen Widgets, Templates und Plugins neigt ein WordPress-Blog dazu, träge zu werden. Unter Last des Besucheransturms häufen sich die Zugriffe auf die Datenbank, der Server hat durch die Abarbeitung flexibler Bereiche proportional mehr zu erledigen. Nicht verzögerungsfreie Auslieferung der Webseiten ist das Resultat der Belastung. Speziell für kleinere bis mittlere Projekte wurde Cachify entwickelt: smartes, übersichtliches Cache-Plugin, welches Seiteninhalte in statischer Form zwischenspeichert und Performance-schonend ausliefert. Dem Leser und Ranking zugute. Verfügbare Speichermethoden: Datenbank, APC, Festplatte und Memcached.

Sprungmarken


Features

Warum ausgerechnet Cachify? Mehrere Gründe sprechen dafür:

  • Kostenlos und werbefrei
  • Unterschiedliche Caching-Arten
  • Kompakt und übersichtlich
  • Performance-steigernd (Performance als Rankingfaktor)
  • Multisite-fähig
  • Deutschsprachige Bedienoberfläche
  • Lauffähig unter Apache und Nginx
  • Komplett dokumentiert
  • Buch in gedruckter und digitaler Form

Funktionsweise

Mit Sicherheit kann Cachify mit Monster-Plugins der Branche nicht mithalten, das Caching-Plugin erfüllt jedoch den Zweck vollkommen und äußerst zuverlässig. Und das mit sehr minimalen Mitteln und überschaubarem Code.

Was macht also Cachify? Ruft ein Besucher eine Blogseite auf, prüft das Cache-Plugin, ob diese Seite bereits im Cache als statischer Quelltext vorliegt. Im Positivfall kommt die zwischengespeicherte Version der Seite zur Ausgabe. Andernfalls befördert die smarte Cache-Lösung den aktuellen Seiteninhalt in den Zwischenspeicher, welcher sich je nach Einstellung in der WordPress-Datenbank, der Server-Festplatte oder im Server-Speicher via APC-Modul befindet. Beim nächsten Aufruf der Seite im Browser würde diese also aus dem Cache eingelesen und direkt an den Browser gesendet.

Der Vorteil der Technik wird schnell klar: Inhalte liegen in statischer Form zur Ausgabe vor und werden nicht erst durch unzählige Datenbankzugriffe und dynamische PHP-Scripte in die Ausgangsform zusammengeführt.

Zusätzlich profitiert auch die Ladezeit der Blogseiten, weil Webseiten prompter vom Server ausgeliefert werden. Im Testlabor konnte Cachify eine Reduzierung der Datenbankabfragen um 80 Prozent und die Ausführungszeit um bis zu 60 Prozent senken. Summa Summarum: Die Datenbank und der Server werden spürbar entlastet.

Cachify-Ausgabe im Quelltext
Cachify im Einsatz: Plugin-Ausgabe im Quelltext

Cache-Reset: Automatisch und manuell
Nach neu angelegten oder modifizierten Beiträgen leert Cachify den kompletten Cache, da nach der Veröffentlichung des Artikels zu viele Veränderungen bzw. Verschiebungen innerhalb der Archivseiten zu erwarten sind. Ein effizienteres Management würde die Komplexität der Cache-Lösung steigern. Ausnahme: Änderungen an Kommentaren bewirken einen Neuaufbau des Cache ausschließlich für die betroffene Blogseite.

Ebenfalls zugunsten der Übersichtlichkeit und der Einfachheit des Codes stossen selten ausgeführte Element-Aktionen wie beispielsweise neu angelegte Kategorien und Tags keinen Cache-Refresh an. Bei Bedarf die Cachify-Schaltfläche Cache leeren (Papierkorb-Icon) in der Admin Bar betätigen – daraufhin wird der aufbewahrte Zwischenspeicher eliminiert, mit der Neuindexierung der Daten wird begonnen. Netzwerkweit aktiviertes Plugin leert in diesem Fall den Cache aller Multisite-Blogs.

Cachify Adminbar Icon
Cachify-Cache leeren bequem in der WordPress Adminbar

Automatische Leerung des Cache-Vorrats

  • Nach Veröffentlichung neuer Beiträge
  • Nach Veröffentlichung neuer Seiten
  • Nach Veröffentlichung neuer Custom Post Types
  • Nach Veröffentlichung geplanter Beiträge (nur Cachify DB)
  • Nach WordPress-Aktualisierung
  • Beim Klick auf den Papierkorb-Button in der Adminleiste
  • Beim Speichern von Cachify- und wpSEO-Optionen

- Interne Ausnahmeliste (Bereiche, die vom Cache ausgenommen sind)

  • Passwort-geschützte Seiten
  • Feeds
  • Trackbacks
  • Robots
  • Vorschau
  • Mobile-Themes (WP-Touch, Carrington, Jetpack Mobile)
  • Suche
  • Fehlerseiten

Schlusswort
Die Dimension der Blogs mit eingesetztem Caching-Plugin ist sekundär: Das Ziel ist immer, die Datenbankanfragen und PHP-Ausführungen zu reduzieren, um den Server zu entlasten und die Anzeige-Geschwindigkeit zu beflügeln. Als Faustregel gilt: Je weniger Dynamik und Flexibilität, desto kluger der Cache, desto geschwinder die Webseiten.


Einstellungen

Einstellungsmöglichkeiten sind auf der Plugin-Optionsseite nach Wünschen und Gegebenheiten frei veränderbar. Nach dem Speichern der Optionen leert sich der Website-Cache und vorgenommene Einstellungen beginnen mit ihrer Wirkung. Nachfolgend werden einzelne Plugin-Optionen erklärt.

– Cache-Aufbewahrungsort
Vier verfügbare Methode für die Zwischenspeicherung der Inhalte. Zu beachten ist, dass bei APC, Memcached und Festplatte diverse Anpassungen an Server-Konfigurationsdateien notwendig sind (siehe weiter unten).

  • Datenbank steht immer zur Verfügung.
  • APC nur bei installiertem Alternative PHP Cache ab Version 3.1.4.
  • Memcached bei aktivem Memcached aufgesetzt auf Nginx.
  • Festplatte als Caching-Art kann ausschließlich bei aktivierten WordPress-Permalinks genutzt werden.

– Cache-Gültigkeit
Aufbewahrungsdauer der Inhalte im Cache in Stunden. Funktionsweise: Erreicht die Lebensdauer einer Webseite im Cache den festgelegten Zeitraum, wird dieser Eintrag aus dem Cache entfernt und durch aktuelleren Inhalt ersetzt. Bei CMS-Seiten lohnt sich eine Zahl im Monatsbereich. Eine 0 (Null) bedeutet einen unbefristet gültigen Cache. Bei Festplatte als Caching-Art kann diese Option aus technischen Gründen nicht berücksichtigt werden.


– Cache-Generierung: Kein Cache-Aufbau durch eingeloggte Nutzer
In aktivierter Form sorgt die Checkbox dafür, dass alle Blogleser ausgenommen eingeloggte und bereits kommentierende Nutzer den Cache initialisieren dürfen und die zwischengespeicherte Version einer Blogseite angezeigt bekommen. Praktisch, wenn angemeldete Blog-Autoren und Administratoren beispielsweise die integrierte Admin-Bar oder Editieren-Links im Theme eingeblendet bekommen, die gewiss nicht zum Bestandteil der zwischengespeicherten Cache-Seite werden sollen.

Nicht aktivierte Option bedeutet, angemeldete und kommentierende Nutzer sehen identische Ausgabe der Webseiten wie gewöhnliche Besucher (es wird also nicht unterscheiden und alle sehen alles gleich). Andernfalls dürfen angemeldete und kommentierende Nutzer keine Cache-Variante der Seite erzeugen bzw. ausgeliefert bekommen.

Bei APC, Memcached und Festplatte als Caching-Methode muss zusätzlich zur Option eine Anpassung der Server-Systemdatei (.htaccess etc.) vorgenommen werden, siehe dazu Informationen unten.

– Cache-Generierung: Neue Kommentare leeren den Cache
Die aktivierte Option setzt den kompletten Cache-Bestand bei neuen Kommentaren zurück. Kann nützlich sein, um die dynamische Ausgabe der Kommentaranzahl pro Beitrag auf Blogseiten wie die Startseite, Archivseiten, etc. aktuell zu halten.

Die Funktion wird ausschließlich auf kleineren Projekten empfohlen, wo selten kommentiert wird, da der Cachify-Cache andernfalls zu oft neu aufgebaut werden müsste.


– Cache-Ausnahmen: Post/Page-IDs
Erweiterung der Ausnahmeliste für einzelne Blogseiten. Eine Komma-separierte Liste an Post- und/oder Page-IDs, die vom Cache ausgeschlossen werden sollen.
Beispiel: 1, 2, 3

Integrierter Filter: cachify_skip_cache

– Cache-Ausnahmen: Browser User-Agents
Erweiterung der Ausnahmeliste für einzelne Browser. Komma-separierte Liste der User Agents (gerne nur der wesentliche Teil des Strings), die vom Cache ausgeschlossen werden sollen.
Beispiel: MSIE 6, Opera


– Quelltext-Minimierung
Minimierung (Minification) der Browser-Ausgabe. Überflüssige Zeichen wie Umbrüche und HTML-Kommentare werden aus dem Quelltext entfernt. Geht die Darstellung der Blogseite stellenweise kaputt, (z.B. Adsense-Werbebanner sind verschwunden), gehört die Option entweder gänzlich deaktiviert oder nur auf HTML beschränkt.

Integrierter Filter: cachify_minify_ignore_tags


Caching-Methoden

Wie oben bereits erwähnt, kann Cachify den Webseiten-Cache mithilfe von vier unterschiedlichen Cache-Techniken verwalten: Datenbank, APC, Memcached (nur unter Nginx) und Festplatte. Nachfolgend werden notwendige Anpassungen in Server-Systemdateien ausführlich beschrieben.

– Datenbank
Keine Erweiterung der Systemdatei vonnöten.

– APC (Alternative PHP Cache)
Ist APC (3.1.4 empfohlen) als PHP-Erweiterung auf dem Server installiert, so steht innerhalb der Plugin-Einstellungen eine entsprechende Option zur Auswahl bereit. Nach der Aktivierung legt Cachify die generierten HTML-Ansichten der aufgerufenen Blogseiten im Cache der PHP-Extension (Shared Memory) ab und benötigt beim Aufruf der Blog-Seiten keinerlei Datenbankanfragen sowie dynamische PHP-Befehle. Beim Abruf der Blogseiten aus dem APC-Cache ist die Reaktions- und Rückgabezeit des Servers überdurchschnittlich schnell.

Für den Zugriff auf den APC-Zwischenspeicher bringt Cachify eine Vermittlungsdatei – liegend unter plugins/cachify/apc/proxy.php – mit. Diese sogenannte Proxy-Datei analysiert den Cache-Vorrat auf die Existenz der aktuell aufgerufenen Webseite, liest den Inhalt im Erfolgsfall ein und sendet ihn direkt an den Browser.

Die Ausgabedateien speichert Cachify in GZIP-komprimierter Form ab, sodass keinerlei Prozesse für zusätzliche GZIP-Komprimierungen und DEFLATE-Vorgänge seitens Webserver notwendig sind. Das Caching-Plugin übernimmt die Kompression und die korrekte Ausgabe an den Server. Prozessor- und Speicherplatz-schonend.

Die Einbindung der Proxy-Datei unterscheidet sich je nach Webserver. Im Grunde handelt es sich um einen auto_prepend_file Aufruf für PHP-Dateien, welcher abhängig vom Hoster und vergebenen Privilegien in .htaccess oder php.ini eingebunden wird.

Beispiel für .htaccess (Apache):

<Files index.php>
    php_value auto_prepend_file /pfad/plugins/cachify/apc/proxy.php
</Files>

Beispiel für nginx-Instanzen:

location ~ \.php {
    include fastcgi_params;
    fastcgi_pass 127.0.0.1:9000;
    fastcgi_param PHP_VALUE auto_prepend_file=/pfad/plugins/cachify/apc/proxy.php;

    location ~ /wp-admin/ {
        include fastcgi_params;
        fastcgi_pass 127.0.0.1:9000;
        fastcgi_param PHP_VALUE auto_prepend_file=;
    }
}

Die Dateieinbindung dieser Art umgeht die zeitraubende Ausführung des nicht ganz “leichten” WordPress-Cores und spart alle Datenbankzugriffe ein. Positiver Nebeneffekt: Der WordPress-Quelltext bleibt unberührt und bleibt somit nach wie vor Upgrade-fähig.

– Memcached (nur für Nginx)
In Verbindung mit dem Webserver stellt Cachify eine weitere Caching-Methode zur Verfügung: Memcached. Nach der Auswahl der Plugin-Option (soweit verfügbar) und Anpassung der Nginx-Konfigurationsdatei glänzt die Technik mit ihrer überragenden Geschwindigkeit, da der Cache vom Plugin im Arbeitsspeicher (RAM) des Servers ablegt und vom Webserver (Nginx) direkt an den Browser ausgeliefert wird.

Geschwinder und unkomplizierter kann eine Cache-Ausliferung nicht funktionieren. Perfektes Zusammenspiel zwischen Webserver und Memcached.

Erweiterung der Nginx-Konfigurationsdatei

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33
## GZIP
gzip_static on;
## CHARSET
charset utf-8;
## INDEX LOCATION
location / {
error_page 405 = @nocache;
 
if ( $query_string ) {
return 405;
}
if ( $request_method = POST ) {
return 405;
}
if ( $request_uri ~ "/wp-" ) {
return 405;
}
if ( $http_cookie ~ (wp-postpass|wordpress_logged_in|comment_author)_ ) {
return 405;
}
default_type text/html;
add_header X-Powered-By Cachify;
set $memcached_key $host$uri;
memcached_pass localhost:11211;
}
## NOCACHE LOCATION
location @nocache {
try_files $uri $uri/ /index.php?$args;
}
view raw gistfile1.txt hosted with ❤ by GitHub

Hinweise zu Nginx-Anpassungen

  • Bei Domains mit FQDN muss die Nginx-Variable $host gegen $http_host getauscht werden.

Warum nur für Nginx?

  • Apache bringt keine direkte Verknüpfung zu Memcached mit – ein Umweg über eine PHP-Datei müsste erfolgen (Analog zu Cachify APC), um von dort aus auf Caching-Daten zuzugreifen und auszugeben. Manko: PHP-Interpreter wird gestartet und beansprucht zeitintensive Ausführungszeit.
  • Die Ausführungszeit verlangsamt sich zusätzlich, da ausgelesene Memcached-Daten vom PHP-Skript zunächst GZIP-komprimiert werden müssten, falls die Kompression auf der Serverebene abgestellt ist.
  • Memcached (nicht Memcache) ist auf kaum einem Apache-Webserver installiert. Selbst große Hoster bieten das Modul nicht an, da zuverlässige und Nutzer-separierte Speicherverwaltung nicht sichergestellt werden kann.

Nach zahlreichen Tests und Analysen steht fest, dass die Speicherung der Webseiten in Memcache in Verbindung mit einem Apache-Webserver keinen erwarteten Performance-Gewinn mit sich bringt – Cachify HDD als Caching-Art ist in diesem Fall viel effizienter.

Auf Webservern mit Nginx sieht es ganz anders aus: Nginx ist in der Lage auf Memcached-Bestand zuzugreifen und komprimiert auszuliefern. Ohne Zwischenschritte und in erwarteter Performance. Das Nginx-Modul HttpMemcachedModule gehört stets zum Lieferumgang des Webservers (Nginx).

Warum kein Memcache?
Die Binary-Implementierung von Memcache (also nicht Memcached) ist extrem fehlerhaft, so dass Daten nicht zuverlässig aufbewahrt werden können.

– Festplatte (HDD Cache)
Ist Festplatte als Aufbewahrungsort für Cache ausgewählt, legt Cachify die generierten HTML-Ansichten der angeforderten Blogseiten auf der HDD des Webservers ab – pro Webseite eine HTML-Datei. Der Server übernimmt dabei die Umleitung auf die zuständige Cache-Datei. Der Start des PHP-Interpreters entfällt dabei gänzlich und sorgt somit für einen zusätzlichen Performance-Schub.

Bevor die Option in Cachify-Einstellungen ausgewählt ist, gehört im WordPress-Verzeichnis wp-content ein neuer Ordner namens cache mit 777 als Rechte angelegt (später gern auch kleiner, wenn die Funktionsweise des Plugins nicht beeinträchtigt wird). Existiert dieser Pfad bereits, sind nur die Berechtigungen zu kontrollieren. Das Plugin wird zwar versuchen, den Ordner selbst zu erzeugen, doch im Fehlerfall würde das Skript mit einem Hinweis aussteigen. Aus diesem Grund lieber vorsorgen.

Die Vermittlung zwischen dem Seitenaufruf im Browser und der existierenden Cache-Datei steuert der Webserver: Apache oder Nginx. Entsprechend gehört diese Aufgabe an den Server delegiert. Dies geschieht durch eine Erweiterung der Apache-Datei .htaccess oder der Nginx-Konfigurationsdatei. Beispiele für Implementierungen folgen weiter unten.

Zusätzlich zu einer HTML-Variante der Webseiten fertigt Cachify eine GZIP-komprimierte Version an. Der Server greift auf die komprimierte Datei zurück und verzichtet dabei auf die eigene, zeitaufwändige Kompression der Inhalte. Man spart dabei CPU-Last, da Dateien bereits (vor)komprimiert sind.

Erweiterung der .htaccess (Apache)

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30
# BEGINN CACHIFY
<IfModule mod_rewrite.c>
# ENGINE ON
RewriteEngine On
 
# GZIP FILE
<IfModule mod_mime.c>
RewriteCond %{REQUEST_URI} /$
RewriteCond %{REQUEST_URI} !^/wp-admin/.*
RewriteCond %{REQUEST_METHOD} !=POST
RewriteCond %{QUERY_STRING} =""
RewriteCond %{HTTP_COOKIE} !(wp-postpass|wordpress_logged_in|comment_author)_
RewriteCond %{HTTP:Accept-Encoding} gzip
RewriteCond %{DOCUMENT_ROOT}/wp-content/cache/cachify/%{HTTP_HOST}%{REQUEST_URI}index.html.gz -f
RewriteRule ^(.*) /wp-content/cache/cachify/%{HTTP_HOST}%{REQUEST_URI}index.html.gz [L]
 
AddType text/html .gz
AddEncoding gzip .gz
</IfModule>
 
# HTML FILE
RewriteCond %{REQUEST_URI} /$
RewriteCond %{REQUEST_URI} !^/wp-admin/.*
RewriteCond %{REQUEST_METHOD} !=POST
RewriteCond %{QUERY_STRING} =""
RewriteCond %{HTTP_COOKIE} !(wp-postpass|wordpress_logged_in|comment_author)_
RewriteCond %{DOCUMENT_ROOT}/wp-content/cache/cachify/%{HTTP_HOST}%{REQUEST_URI}index.html -f
RewriteRule ^(.*) /wp-content/cache/cachify/%{HTTP_HOST}%{REQUEST_URI}index.html [L]
</IfModule>
# END CACHIFY
view raw .htaccess hosted with ❤ by GitHub

Hinweise zu .htaccess Anpassungen

  • Innerhalb der .htaccess besitzt die obige Erweiterung eine höhere Priorität und muss daher oberhalb der WordPress Rewrite-Regeln (markiert meist durch # BEGIN WordPress# END WordPress) platziert werden.
  • Einige (wenige) Hoster (domainFACTORY und 1und1 gehören dazu) stellen die Apache-Variable %{DOCUMENT_ROOT} nicht zur Verfügung. Das führt zu einem unvollständigen Datei-Pfad. In solchen Fällen bitte den Document-Pfad manuell (statt Variable) voranstellen, siehe Anleitung DOCUMENT_ROOT in .htaccess durch Serverpfad ersetzen.
  • Änderungen an der Datei .htaccess können nicht vorgenommen werden, wenn PHP als fcgi ausgeführt wird.
  • Kommt es teilweise zu fehlerhaften Weiterleitungen innerhalb des Blogs, so kann die Abschaltung des Apache Content Cache Abhilfe schaffen.
  • Ist in WordPress das WPTouch-Plugin installiert, müssen RewriteRules erweitert werden, siehe Gist.

Erweiterung der Nginx-Konfigurationsdatei

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35
## GZIP
gzip_static on;
 
## CHARSET
charset utf-8;
 
## INDEX LOCATION
location / {
if ( $query_string ) {
return 405;
}
if ( $request_method = POST ) {
return 405;
}
if ( $request_uri ~ /wp-admin/ ) {
return 405;
}
if ( $http_cookie ~ (wp-postpass|wordpress_logged_in|comment_author)_ ) {
return 405;
}
error_page 405 = @nocache;
try_files /wp-content/cache/cachify/${host}${uri}index.html @nocache;
}
 
## NOCACHE LOCATION
location @nocache {
try_files $uri $uri/ /index.php?$args;
}
 
## PROTECT CACHE
location ~ /wp-content/cache {
internal;
}
view raw gistfile1.nginxconf hosted with ❤ by GitHub

Hinweise zu Nginx-Anpassungen

  • Bei Domains mit FQDN muss statt ${host} die Variable ${http_host} verwendet werden.

Allgemeine Hinweise zu Cachify HDD

  • Das HDD-Caching in Cachify kann nur bei aktivierten WordPress-Permalinks ausgewählt und genutzt werden. Ein Schrägstrich am Ende des Permalinks wird ebenfalls vorausgesetzt. Für Permalinks ohne Slash am Ende ist die Nutzung eines speziellen .htaccess-Snippets vonnöten. Der Snippet-Code ersetzt den oben vorgestellten .htaccess-Eintrag.
  • Befindet sich der Blog in einem Unterverzeichnis und die dazugehörige .htaccess außerhalb des Blog-Verzeichnisses, gehört der Pfad zum Cache-Ordner angepasst. Beispiel als Gist.
  • Aus technischen Gründen kann bei dieser Caching-Methode die Plugin-Einstellung Kein Cache für eingeloggte bzw. kommentierende Nutzer nicht automatisch berücksichtigt werden. Sollen in WordPress angemeldete und kommentierende Nutzer ebenfalls die Cache-Version der Blogseiten angezeigt bekommen, müssen im obigen Code die beiden Zeilen mit der Cookie-Abfrage (RewriteCond %{HTTP_COOKIE}) einkommentiert werden (Raute davor stellen). Die Option Kein Cache für eingeloggte bzw. kommentierende Nutzer muss dennoch aktiviert bleiben.
  • Die eingestellte Cache-Gültigkeitsdauer kann nicht einbezogen werden. Muss der Cache-Bestand in bestimmten Zeitabständen geleert werden, so empfiehlt sich der Aufruf einer präparierten PHP-Datei per Cronjob.
  • Dadurch, dass Cachify HDD auf PHP verzichtet und die WordPress-Ausführung umgeht, können bei dieser Methode keine geplanten WordPress-Beiträge ausgeführt werden. Eine brauchbare Alternative wäre der Aufruf der WordPress-Datei wp-cron.php (zu lokalisieren im Hauptverzeichnis der WordPress-Instanz) mithilfe der Server-Cronjobs (Hoster fragen oder selbst einrichten) oder eines Dienstleisters wie cronjob.de

Steuerung der Cache-Leerung bei Artikel-Updates

Bei der Aktualisierung von Artikeln kann die notwendige Cache-Leerung manuell beeinflusst werden. Bis dato löschte Cachify bei jedem Artikel-Update den gesamten Cache automatisch, um Inhalte mit durchgeführten Änderungen wirklich auf allen Webseiten der WordPress-Website aufzufrischen.

Ab sofort können Autoren die Entscheidung treffen, ob nach der Speicherung der Artikeländerung nun der komplette Cachify-Cache oder nur der Cache der betroffenen Seite entfernt werden soll – praktisch, wenn die getätigte Änderung nur die eine Seite betrifft und keinerlei (optische) Auswirkung auf die restlichen Webseiten haben.

Cachify Publish-Status
Cachify Cache-Status beim Update der Artikel

Verfügbare Optionen in der Auswahlbox:

  • Gesamtcache löschen – leert den gesamten Cachify-Cache
  • Seitencache löschen – entfernt lediglich den Cache des Artikels

Die Auswahl ist nur bei bereits veröffentlichten Artikeln, Seiten und Post Types zugänglich. Die zuletzt selektierte Option wird Nutzer-abhängig gespeichert und beim nächsten Aufruf der Artikel-Bearbeitungsseite vorausgewählt.


Wissenswertes

Einige Zusatzinformationen für die Arbeit mit dem Caching-Plugin.

Cachify-Größe auf dem Dashboard
Cachify Cache-Größe auf dem Dashboard

- Nutzung des Browser-Cache
Auf Wunsch kann die HTML-Ausgabe der Blogseiten zusätzlich im Cache der Browser aufbewahrt werden – für einen frei wählbaren Zeitraum. Diese Technik eignet sich dann, wenn ein Projekt über wenig Dynamik verfügt (keine Kommentare, selten Artikel etc.). In solchen Fällen verfügt der Browser über eine lokale Kopie einer Blogseite, die nach definierter Zeit abläuft.

Für beispielsweise einen einstündigen Browser-Cache muss die .htaccess bzw. Nginx-Serverdatei wie abgebildet komplettiert werden:

Browser-Cache in .htaccess (Apache)

<IfModule mod_expires.c>
    <FilesMatch "\.(html|html\.gz)$">
        ExpiresActive On
        ExpiresDefault "access plus 1 hour"
    </FilesMatch>
</IfModule>

Browser-Cache bei Nginx (platziert zwischen error_page und try_files)

expires 1h;

- Anpassung der robots.txt
Damit Google und andere Suchmaschinen den statischen Inhalt des Cache-Ordners nicht indexieren (führt sonst zum doppelten Content), sollte die im Hauptverzeichnis einer WordPress-Installation befindliche Datei robots.txt erweitert werden, indem der Pfad zum Ordner mit Cache-Dateien gesperrt (disallow) wird. Und so könnte eine robots.txt aussehen:

User-agent: *
Disallow: /wp-content/cache/
Allow: /

- Cache-Leerung aus Drittanwendungen
Für den Fall, dass der Cachify Cache aus WordPress-Drittanwendungen geleert werden soll, stehen innerhalb des Plugins (ab Cachify 2.0.3) ausführbare Aktionen zur Verfügung:

if ( has_action('cachify_flush_cache') ) {
    do_action('cachify_flush_cache');
}

if ( has_action('cachify_remove_post_cache') ) {
    do_action('cachify_remove_post_cache', 123); // postID
}

- Weiterführende Links mit Analysen


Taschenbuch & eBook

Zugegeben ist die obige Plugin-Beschreibung nicht unbedingt sofort verständlich, da doch (zu) viele Optionen und Funktionen ausführlich vorgestellt werden. Aus diesem Grund wurde für Cachify und allgemein das Thema Caching in WordPress ein Buch erarbeitet und auf Amazon als Kindle eBook und gedrucktes Taschenbuch zum Kauf gestellt.

Verfügbare Formate

WordPress Performance Buch-Cover
WordPress Performance Buch-Cover

Im Buch geht es darum zu verstehen, wie das Caching-Plugin Cachify der WordPress-Performance positiv beiträgt, welche Techniken zur Beschleunigung der Webseiten existieren und woran die Unterschiede liegen. Schritt für Schritt wird Cachify in Betrieb genommen und mit empfohlenen Optionen versehen. Auch Ratschläge zu Optimierungsmaßnahmen auf Seiten des Servers und Browsers bringt das Buch im Lieferumfang mit.

Die Zielsetzung der Buchkapitel: Einsteiger und nicht unbedingt technisch versierte Blogger nehmen Geschwindigkeitsoptimierungen am Blog selbsttätig vor, ohne Modifizierungen am WordPress-Theme vorzunehmen und ohne eine Handvoll an Caching-Plugins zu installieren. Reinblättern lohnt sich also.

Der Buchkauf unterstützt die Weiterentwicklung des Caching-Plugins. Von jedem Verkauf (unabhängig vom Format) bekommt der Autor ca. 2 € ausgezahlt.


Support

Da muss nicht viel gesagt werden:

  • Cachify ist kostenfrei
  • Online-Dokumentation ist kostenfrei
  • Support gegen Spende
  • Installation gegen pauschale Gebühr


Hilfeleistung via PayPal, Flattr, Amazon ist jederzeit willkommen. Danke.


Download

› Cachify – Caching für WordPress ↓


Mindestanforderungen

  • WordPress 3.8
  • PHP 5.2.4
  • APC 3.1.4 (optional)
  • Memcached 1.4.15 (optional)

Hinweise

  • Je nach Caching-Methode ist es mit einem Zuwachs der Datenbank- bzw. Festplattengröße zu rechnen.
  • Ist hier im Playground im produktiven Einsatz.
  • Nach der Inbetriebnahme sind Blogseiten auf Fehlerfreiheit zu überprüfen.
  • Alle Aktionen an Kommentaren lösen einen Neuaufbau ausschließlich der betroffenen Artikelseite im Cache aus.

Schon gewusst?
Cachify verfügt über eine eigene Produktseite: Cachify.de


Häufige Fragen

Hat das obige Online-Handbuch nicht alle Fragen beantwortet? Vielleicht helfen nachfolgende Antworten auf die oft gestellten Fragen.

- PHP Fatal error: Cannot use output buffering in output buffering display handlers in Unknown on line 0
Nach der Inbetriebnahme des Caching-Plugins kann es zu abgebildeter Fehlermeldung kommen. Der Hinweis erscheint, weil keine Cache-Festplattendateien zur Ausgabe existieren. Das liegt vermutlich daran, dass Cachify keine Files im Cache-Ordner ablegen konnte. Bitte Schreibrechte für den Cache-Ordner (zu finden im WordPress-Verzeichnis wp-content) prüfen und ggf. korrekt setzen.

Cachify HDD: Zeichenkodierung funktioniert nicht korrekt
Durch die Umstellung auf Cachify HDD wird kein PHP ausgeführt. Bei falsch konfigurierten Servern kann dadurch zur fehlerhaften Darstellung der Sonderzeichen auf Webseiten kommen. Der Fehler lässt sich durch eine Erweiterung der Systemdatei .htaccess beheben: AddDefaultCharset UTF-8


Versionsverlauf

Version 2.1.8 vom 21.07.2014

  • HHVM-Support für Memcached unter Nginx

Version 2.1.7 vom 01.06.2014

  • Wegen Abmahnung gelöscht
  • Cache-Regenerierung beim Veröffentlichen von CPT
  • Weitere Sicherheitsmaßnahmen
  • Sourcecode-Refactoring

Version 2.1.6 vom 08.04.2014

  • Button “Cache leeren” sichtbar sowohl in WP 3.8 wie WP 3.9

Version 2.1.5 vom 07.04.2014

  • Unterstützung für WordPress 3.9
  • Einblendung des “Cache leeren” Buttons in allen Auflösungen

Version 2.1.4 vom 24.01.2014

  • Unterstützung für WordPress 3.8.1

Version 2.1.3 vom 31.12.2013

Version 2.1.2 vom 12.12.2013

  • Optimierung für WordPress 3.8
  • Optional: Cache-Leerung bei neuen Kommentaren

Version 2.1.1 vom 16.10.2013

  • Hook cachify_skip_cache für die Steuerung der Cache-Bildung pro Seite
  • Unterstützung des MP6 Plugins

Version 2.1.0 vom 04.10.2013

  • Cache-Reset beim Deaktivieren des Plugins

Version 2.0.9 vom 16.09.2013

  • Quelltext-Minimierung per Selectbox und Hook
  • Interne Umstellung auf Konstanten

Version 2.0.8 vom 21.08.2013

  • Wegen Abmahnung gelöscht

Version 2.0.7 vom 31.07.2013

  • Support für Memcached (Nginx only)
  • Kompatibilität zu WordPress 3.6
  • Cache-Neuaufbau bei Theme-Wechsel
  • Code-Optimierungen und Bereinigungen

Version 2.0.6 vom 23.03.2012

  • Cache-Neuaufbau für eine Blogseite bei neuem Kommentar erst dann, wenn der Kommentar freigeschaltet ist.

Version 2.0.5 vom 23.01.2013

  • Überarbeitetes Plugin-Handbuch
  • Änderung an Systemvoraussetzungen
  • Check für angemeldete Nutzer bei APC als Methode
  • Kein Cache bei Jetpack Mobile Theme
  • Cache-Leerung nach WordPress-Update

Version 2.0.4 vom 15.08.2012

  • Dashboard: Trennung der Cache-Gesamtgröße vor Diskussionswerten

Version 2.0.3 vom 01.08.2012

  • Support für Custom Post Types hinzugefügt
  • Erweiterung der WP-internen robots.txt um Disallow: /wp-content/cache/
  • Hook cachify_flush_cache zum Cache-Leeren

Version 2.0.2 vom 12.6.2012

  • Unterstützung für WordPress 3.4
  • Hochauflösendes Plugin-Icon für Retina-Displays
  • Eliminierung des Icons aus der Admin-Sidebar
  • Behandlung für ältere PHP-Versionen

Version 2.0.1 vom 12.3.2012

  • Cache-Reset beim Veröffentlichen geplanter Beiträge (Cachify DB)
  • Optimierung des Autoload-Prozesses
  • Textliche Anpassungen

Version 2.0 vom 5.3.2012

  • Offizielle Cachify-Homepage: cachify.de
  • Komplett überarbeitete Oberfläche der Einstellungen
  • Inline-Hilfe direkt im Plugin (ab WordPress 3.3)
  • Cache-Größe auf dem Admin-Dashboard
  • HDD-Cache für noch kürzere Response-Zeiten
  • Modularisierung des Quelltextes
  • Keine Cache-Ausgabe für Kommentatoren
  • WordPress 3.1 (3.3 empfohlen) & PHP 5.1.2 als Mindestanforderung
  • APC 3.0.0 (3.1.4 empfohlen) als Mindestanforderung
  • Cache-Reset pro Artikel bei Kommentarstatusänderungen

Version 1.5.1 vom 6.2.2012

  • APC Proxy: zlib.output_compression = Off für Apache Webserver

Version 1.5 vom 14.01.2012

  • Code-Formatierung
  • Veränderung des Toolbar-Buttons “Cache leeren”
  • Überarbeitung des regulären Ausdrucks für die HTML-Minimierung

Version 1.4 vom 23.12.2011

Version 1.3 vom 20.12.2011

Version 1.2.1 vom 01.12.2011

  • Icon für die Admin Bar

Version 1.2 vom 21.11.2011

  • Cache leeren Schalter für die Adminbar
  • Testbetrieb unter WordPress 3.3
  • Verknüpfung mit wpSEO (Cache-Leerung bei Optionsänderungen)

Version 1.1 vom 16.08.2011

  • Automatische Prüfung auf eventuelle Fehlgenerierungen
  • Modifizierung der Code-Struktur
  • Eliminierung der Inline-Hilfe (oben rechts)
  • Verknüpfung der Online-Hilfe mit einzelnen Optionen

Version 1.0 vom 21.06.2011

  • Leerung des Cache beim Aktualisieren von statischen Seiten
  • Seite mit Plugin-Einstellungen
  • Inline-Dokumentation innerhalb der Optionsseite
  • Ausschluss von Passwort-geschützten Seiten
  • WordPress 3.2 Support
  • Unterstützung der WordPress Multisite Blogs
  • Umstellung auf den template_redirect-Hook (Plugin-Kompatibilität)
  • Interne Code-Bereinigung

Version 0.9.2 vom 17.05.2011

  • HTML-Minimierung durch Entfernung unnötiger Leerräume
  • Flattr-Link

Version 0.9.1 vom 27.01.2011

  • Cache-Reset bei geplanten Beiträgen
  • Unterstützung für das Carrington-Mobile Theme

Version 0.9 vom 14.01.2011

  • Workaround für Redirects

Version 0.8 vom 11.01.2011

  • Blacklist für PostIDs
  • Blacklist für UserAgents
  • Ausnahme für WP Touch
  • Ausgabe des Zeitpunktes der Generierung
  • Umbenennung der Konstanten

Version 0.7 vom 10.01.2011

  • Davor, danach: Ausgabe des Speicherverbrauchs

Version 0.6 vom 09.01.2011

  • Live auf wordpress.org
Sergej Müller

[Der Autor]Sergej Müller ist enthusiastischer Software Engineer mit Schwerpunkten Webentwicklung, Apps und WordPress. Seit 2007 programmiert und vertreibt er wpSEO, das zugkräftige SEO-Plugin für WordPress-Blogs.

Thematisch ähnliche Beiträge