Cachify ist das ausgereifte Cache-Plugin für WordPress, welches die Blog-Performance steigert und Datenbankanfragen minimiert. Kostenlos.

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 ganz verzögerungsfreie Auslieferung der Webseiten ist das Resultat der Belastung. Speziell für kleinere bis mittlere Projekte wurde Cachify entwickelt: einfaches, übersichtliches Cache-Plugin, welches Seiteninhalte des Blogs in statischer Form zwischenspeichert und diese auf Anfrage Performance-schonend ausliefert. Verfügbare Methoden: Datenbank, APC, HDD.

Sprungmarken

• Funktionsweise
• Versionsverlauf
• Installation
• Download

Cachify-Plugin im Einsatz: Optimierungsergebnisse im Quelltext

Funktionsweise
Nach zahlreichen Testwochen und Verbesserungsrunden steht das Cache-Plugin Cachify kostenlos zur Nutzung bereit. Mit Sicherheit kann es mit vielfältigen Monster-Plugins der Branche nicht mithalten, erfüllt jedoch seinen 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. 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: Statischer Inhalt liegt bereits für die Ausgabe vor und wird 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.

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

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

WordPress Cache leeren bequem in der WordPress Toolbar

Optimierungswerte: Davor, danach
Um den Performance-Gewinn zu ermitteln, speichert das Plugin im Cache zusätzlich zum Seiteninhalt die Anzahl der Datenbankanfragen und die verbrauchte WordPress-Ausführungszeit (nicht zu verwechseln mit der Ladezeit im Browser). Beim Auslesen der Daten aus dem Zwischenspeicher werden diese Angaben den aktuellen Werten gegenübergestellt und im Browser-Quelltext abgebildet (siehe dazu den Screenshot oben).

Cachify Einstellungen
In der Standard-Ausführung des Cachify verfällt der gespeicherte Cache einer Blogseite automatisch nach zwölf Stunden. Diese wie andere Einstellungsmöglichkeiten sind auf der Plugin-Optionsseite nach Wünschen und Gegebenheiten frei veränderbar. Nach dem Speichern der Optionen leert sich der Cache und vorgenommene Einstellungen beginnen mit ihrer Wirkung. Nachfolgend werden einzelne Plugin-Optionen erklärt.

Ab Cachify 2.0: Umgestaltete Optionsseite

– Aufbewahrungsort für Cache
Technik für die Zwischenspeicherung der Inhalte. Insgesamt stehen 3 Methoden zur Auswahl: Datenbank, APC und Festplatte. Datenbank steht immer zur Verfügung. APC nur bei installiertem Alternative PHP Cache ab Version 3.0.0 (empfohlen 3.1.4). Festplatte als Caching-Art kann ausschließlich bei aktivierten WordPress-Permalinks genutzt werden.

Zu beachten ist, dass bei APC und Festplatte diverse Anpassungen an Server-Konfigurationsdateien notwendig sind (siehe weiter unten).
Datenbank ist als Standard definiert.

– Cache-Gültigkeit in Stunden
Aufbewahrungsdauer des Seiten-Cache in Stunden. Funktionsweise: Erreicht die Lebensdauer einer Webseite im Cache den festgelegten Zeitraum, wird dieser Eintrag aus dem Cache entfernt und durch einen aktuellen 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.
12 ist als Standard definiert.

– Minimierung der Ausgabe
Minimierung (Minification) der HTML-Ausgabe. Überflüssige Zeichen wie Umbrüche und HTML-Kommentare werden entfernt. Geht der Quelltext der Webseite stellenweise kaputt (z.B. Werbebanner sind verschwunden), so muss die Option deaktiviert werden.
“Aus” ist als Standard definiert.

– Ausnahme für (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

– Ausnahme für 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

– Kein Cache für eingeloggte bzw. kommentierende 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 des Cache werden sollen. “Kein Haken” als Wert bedeutet, angemeldete und kommentierende Nutzer sehen identische Ausgabe wie gewöhnliche Besucher der Seite (es wird also nicht unterscheiden und alle sehen alles gleich).

Bei aktiviertem APC-Cache spielt die Option keine Rolle, da an der betroffenen Cache-Ausgabestelle keine Nutzerollen verfügbar sind. Bei HDD-Cache muss eine Erweiterung vorgenommen werden, siehe dazu Informationen unten.
“An” ist als Standard definiert.

APC (Alternative PHP Cache) nutzen
Ist APC als PHP-Erweiterung auf dem Server installiert (apc >= 3.0.0, 3.1.4 empfohlen), so steht im Cache-Plugin automatisch eine Auswahl zur Aktivierung bzw. Nutzung des APC bereit. Nach der Aktivierung legt Cachify die generierten HTML-Ansichten der aufgerufenen Blogseiten im Cache (Shared Memory) der PHP-Extension ab und benötigt beim Aufruf der Seiten keinerlei Datenbankanfragen sowie dynamische PHP-Befehle. Durch einen direkten Aufruf der Blogseiten aus dem Cache ist die Reaktions- und Rückgabezeit des Servers sehr schnell.

Für den geplanten Zugriff auf den APC-Zwischenspeicher wird auf dem Server eine Proxy-Plugin-Datei – liegend unter cachify/apc/proxy.php – eingebunden, welche den Cache-Vorrat auf die Existenz der aktuell aufgerufenen Webseite analysiert und im Erfolgsfall direkt an den Browser sendet. Dabei speichert Cachify die Ausgabedateien in GZIP-komprimierter Form, so dass keinerlei Prozesse für zusätzliche 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 je nach Möglichkeit in der php.ini oder .htaccess eingebunden wird.

Beispiel für .htaccess:

<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. Schöner Nebeneffekt: Der WordPress-Code bleibt unberührt und ist nach wie vor Upgrade-fähig.

Cache auf der Server-Festplatte aufbewahren (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. 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 den 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. Zusätzlich zur HTML-Variante einer Webseite, fertigt Cachify eine GZIP-komprimierte Version an, damit der Server vor der Ausgabe an den Browser auf diese zurückgreifen und auf die eigene Kompression verzichten kann (man spart dabei CPU-Last, da alles bereits (vor)komprimiert).

Erweiterung der .htaccess

<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} !(comment_author|wp-postpass|wordpress)_
		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}/$1/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} !(comment_author|wp-postpass|wordpress)_
	RewriteCond %{DOCUMENT_ROOT}/wp-content/cache/cachify/%{HTTP_HOST}%{REQUEST_URI}/index.html -f
	RewriteRule ^(.*) /wp-content/cache/cachify/%{HTTP_HOST}/$1/index.html [L]
</IfModule>

Ergänzung

• Die obige Erweiterung besitzt innerhalb der .htaccess eine höhere Priorität und positioniert sich bestenfalls oberhalb der WordPress Rewrite-Regeln (markiert meist durch # BEGIN WordPress … # END WordPress).
• Einige wenige Hoster (domainFACTORY gehört 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-Root manuell voranstellen.

Erweiterung für Nginx

## 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 ~ (comment_author|wp-postpass|wordpress)_ ) {
	#	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;
}

Hinweise zu Cachify HDD

• HDD Caching in Cachify kann nur bei aktivierten WordPress-Permalinks ausgewählt und genutzt werden.
• 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 keine Cache-Version der Blogseiten angezeigt bekommen, müssen im obigen Code die auskommentierten Zeilen mit der Cookie-Abfrage einkommentiert werden. Die Option Kein Cache für eingeloggte bzw. kommentierende Nutzer muss weiterhin aktiviert bleiben.
• Die eingestellte Gültigkeitsdauer des Cache kann nicht einbezogen werden.
• 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.
• Cachify HDD und Cachify APC umgehen die Ausführung von WordPress. Das hat zufolge, dass in WordPress integrierte Funktionen wie Cronjobs (z.B. für geplante Beiträge) oder Statistik-Plugins (z.B. Statify) nicht gestartet werden.

Browser-Cache
Auf Wunsch kann die HTML-Ausgabe der Blogseiten zusätzlich im Browser-Cache aufbewahrt werden. Diese Technik eignet sich dann perfekt, 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 und reduziert den Ladevorgang einer Seite zusätzlich.

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

Apache (.htaccess)

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

Nginx (platziert zwischen error_page und try_files)

expires 1h;

Server-Antwortzeiten nach der Umstellung von Cachify DB auf HDD

Interne Ausnahmeliste (Bereiche, die vom Cache ausgenommen sind)

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

Leerung des Cache-Vorrats

• Veröffentlichung neuer Beiträge
• Veröffentlichung neuer Seiten
• Veröffentlichung geplanter Beiträge (nur Cachify DB)
• Klick auf den Papierkorb-Button in der Adminleiste
• Während der Speicherung von Cachify- und wpSEO-Optionen

Alle Aktionen an Kommentaren lösen einen Neuaufbau ausschließlich der betroffenen Artikelseite im Cache aus.

Anpassung der robots.txt
Damit Google und andere Suchmaschinen den Inhalt des Cache-Ordners nicht indexieren (würde sonst zum doppelten Content führen), sollte die im Hauptverzeichnis befindliche Datei robots.txt erweitert werden, indem der Pfad zum Ordner “verboten” (disallow) wird. Und so könnte eine robots.txt aussehen:

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

Hinweise

• Mindestvoraussetzungen des Cache-Plugins: WordPress ab 3.1 und PHP 5.1.2
• Beim Deinstallieren entfernt Cachify den kompletten Cache.
• Es ist mit einem Zuwachs der Datenbank- bzw. Festplattengröße zu rechnen.
• Ist hier im Playground im produktiven Einsatz (Cachify HDD).
• Nach der Inbetriebnahme sind Blogseiten auf Fehlerfreiheit zu überprüfen.

Cache-Reset aus WordPress-Apps
Für den Fall, dass der Cachify Cache aus einer WordPress-Anwendung geleert werden soll, steht innerhalb des Plugins eine entsprechende PHP-Funktion zur Verfügung:

if ( class_exists('Cachify') && method_exists('Cachify', 'flush_cache') ) {
    Cachify::flush_cache();
}

Schlusswort
Die Dimension des Blogs mit eingesetztem Cache-Plugin ist sekundär: Das Ziel ist immer, die Datenbankanfragen und PHP-Ausfürungen 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.

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

Versionsverlauf
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

• Xmas Edition

Version 1.3 vom 20.12.2011

• Unterstützung für APC-Erweiterung
• Umsiedlung der Schaltfläche innerhalb der Admin Bar

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

Installation

• Plugin downloaden
• Via FTP oder WordPress-Backend zu den Plugins hinzufügen
• Reiter Plugins aufrufen
• Plugin Cachify aktivieren
• Obere Dokumentation beachten
• Einstellungen vornehmen

Flattr
Unterstützung via Flattr ist jederzeit willkommen. Danke.

Download
› Cachify – Cache für WordPress ↓