WordPress Caching – der Turbo für deine WordPress Seite

wordpress-caching

Warum ist Caching so wichtig ?

Das Caching eines WordPress Blogs ist der wohl wichtigste Aspekt einer gelungenen Performance-Optimierung. Ohne Caching gibt es quasi keine echte Skalierbarkeit, ohne Caching sind hohen Besucherzahlen kaum denkbar. WordPress frisst viele Ressourcen und ist komplett dynamisch, was im Grunde nichts anderes bedeutet, als dass jede Seite, bei jedem Aufruf erst einmal komplett neu aus den Einzelteilen erstellt wird. Für jeden Nutzer, versteht sich. So fügt WordPress dann die einzelnen Bestandteile eures Blogs zu einem großen Ganzen zusammen und generiert daraus die fertige HTML-Seite. Die Sidebar wird mitsamt Widgets zusammengesetzt, das Artikel-Layout mit dem eigentlichen Inhalt wird aus der Datenbank abgerufen und das Theme baut daraus den eigentlichen Blog bzw. Blogpost auf. Ganz schön viel Aufwand für einen einzelnen Seitenaufruf, vor allem wenn man bedenkt, dass es davon gleich mehrere hintereinander oder gar gleichzeitig gibt, schließlich habt ihr mehr als eine handvoll Besucher und so wird der Server schnell mit hunderten von Anfragen bombardiert. Dynamik hat im Live-Betrieb eben so ihre Probleme, doch um die auszugleichen, ist ja das Caching da. Zum Glück macht WordPress die Sache einfach.

Mehr Statik braucht das Land

Allgemein ergibt sich bei WordPress das Problem, dass Dynamik uns nicht wirklich weiterbringt. Keine Frage, Dynamik war mal ganz groß, doch in Zeiten in denen ich auf dem Smartphone eine Website aufrufe und danach sofort den Hinweis bekomme, dass mein Tarif aufgrund zu hohen Datentransfers gedrosselt wurde, scheint Dynamik irgendwie fehl am Platz. Statik ist im Trend, Caching in jedem Bereich, sowie Performance-Optimierung bis ans absolute Limit. Vor allem aber Minimalismus, denn wer viel Daten überträgt, verursacht auch hohe Ladezeiten und wer auf Dynamik setzt, verursacht auch gleich noch eine Menge Serverlast. Also heißt es: Weniger Dynamik, mehr Statik!

Durch den Einsatz von Caching lässt sich der dynamische Seitenaufbau von WordPress massiv beschleunigen. Der Browser kontaktiert den Server, welcher wiederum die PHP-Dateien aufruft. Via PHP wird nun der Core von WordPress gestartet, der die notwendigen Informationen aus der Datenbank lädt. Diese Informationen gehen zurück zum Core und der Compiler erstellt die fertige HTML-Seite des Blogs. Diese wird zurück an den Browser gesendet.

WordPress Caching im Detail

Wenn wir uns über WordPress Caching unterhalten, dann sprechen wir nicht von einem Entweder-oder, sondern wir sprechen von vier grundsätzlich verschiedenen Arten des Cachings. Was genau das bedeutet und um welche Bereiche es hier eigentlich geht, habe ich mal für euch auseinandergenommen und hoffentlich auch recht einfach und verständlich zusammengefasst. Das ist bei technischen Themen nicht immer so leicht, aber ich glaube es ist mir dennoch gelungen die Grundlagen auf eine klare Beschreibung zu reduzieren.

Page Caching: Die einfachste Form des Cachings. Hier werden die dynamisch erzeugten Seiten von WordPress ganz einfach als statische HTML-Kopien auf der Festplatte des Servers, oder im RAM (Memory Cache) gespeichert. Statt jedes mal eine neue Seite zu erzeugen, werden fortan die bereits fertig generierten Kopien ausgeliefert. Das ist schnell und entlastet den Server, außerdem umgeht es die Seitengenerierung.

Database Caching: Die Datenbank ist das Herzstück von WordPress, denn hier liegen die eigentlichen Inhalte. Leider sind Datenbanken extrem ressourcenhungrig und oft der Flaschenhals (also die Schwachstelle) bei Hostern. Für jede Anfrage werden nun immer wieder dieselben Daten hin und hergeschickt. Der eine fragt an, die Daten werden gesendet. Der nächste fragt an, wieder werden exakt dieselben Daten gesendet. Das ist ineffizient. Solche Abfragen zu Cachen, nennt man Database Caching. Statt nun also immer dieselbe Anfrage erneut zu senden, wird sie einfach mitsamt dem Ergebnis des jeweiligen Queries zwischengespeichert, also gecached. Bei einem Datenbankintensiven CMS wie WordPress, ist so etwas extrem wichtig.

Object Caching: WordPress selbst besitzt bereits verschiedene Caching-Systeme, zum Beispiel die Transient API, oder eben auch den Object Cache. Allgemein werden diese Systeme zum Caching von WordPress Plugins genutzt, um Daten zwischenzuspeichern und so deutlich effizienter zu arbeiten. Dann können komplizierte Anfragen nämlich einfach gecached werden, weil die erneute Generierung zu aufwändig oder umständlich wäre.

Opcode Caching: Der Opcode Caching ähnelt dem Database Caching. Statt aber Datenbankabfragen zwischenzuspeichern, geht es hier um PHP-Code. Im Grunde basiert WordPress nämlich auf vielen kleinen PHP-Befehlen, wie im eigenen Theme bzw. den einzelnen Dateien auch sehr nachvollziehbar zu sehen ist. Diese Befehle werden nun vom PHP-Compiler nacheinander abgearbeitet und in ausführbaren Code für den Webserver umgewandelt. Opcode Caching kümmert sich nun um den Code, der aus dem PHP-Compiler herauskommt, speichert also das fertige Ergebnis.

HDD oder RAM Caching?

Beim Thema Caching hat der Nutzer meistens die Wahl zwischen der Festplatte (HDD) des eigenen Servers, oder aber dem RAM. Beim Thema Cache-Performance kommt es nun natürlich auf die jeweilige Hardware an. Wie ist die Festplatte verbunden, ist es eine SSD oder High Performance Hard Disk und so weiter. Grundsätzlich lässt sich sagen, dass der RAM eigentlich immer schneller ist. Arbeitsspeicher ist bei der Serverkonfiguration aber auch immer teurer und er wird eventuell noch für viele andere Dinge auf dem Server gebraucht. Wenn er nun für das Caching verantwortlich ist, fehlt die Kapazität also unter Umständen an anderer Stelle. Also erfordert es ein gesundes Maß an Hintergrundwissen und Erfahrung, um so etwas sinnvoll einzusetzen.

Bei WordPress hat sich daher das sogenannte Hard Disk Caching, also das Caching auf der Festplatte (HDD) als besonders wertvoll und effizient erwiesen. Das ist für die meisten günstiger und oft auch einfach effektiver, zumal Share-Hoster oder V-Server einem oft gar nicht die Wahl lassen und ihr demnach sowieso nur die HDD für den Cache zur Auswahl steht. RAM Caching ist letztendlich also eher etwas für erfahrene Anwender, während der normale Blogger dann doch lieber auf die Festplatte zum speichern des Caches setzt. Das funktioniert meist nämlich sicher und problemlos.

WordPress Caching Plugins

Für WordPress Blogger ist der erste Schritt in Sachen Optimierung eigentlich immer, ein passendes Caching Plugin zu installieren. Caching Plugins sorgen bei WordPress dafür, dass das System die Seiten eben nicht mehr dynamisch generiert, sondern sie statisch in einem Cache-Ordner ablegt. Statt die Seite, wie oben erklärt, also bei jedem Aufruf neu aus den einzelnen Bestandteilen zu generieren, wird das fertige Ergebnis als einfache HTML-Seite abgespeichert. Diese Seite liegt nun im Cache-Ordner und statt die Seite für jeden Nutzer neu zu generieren, leitet ein WordPress Caching Plugin nun alle Anwender immer erst einmal an den Cache weiter. Ist die Seite im Cache, bekommt der Besucher selbige sofort angezeigt. Wenn nicht, wird die von ihm generierte Seite in den Cache-Ordner abgelegt und ist fortan für alle nachkommenden Besucher verfügbar. Eigentlich ganz einfach.

Desto simpler ein Caching Plugin in WordPress funktioniert, desto besser. Je umfangreicher die Caching Engine ausfällt und je mehr Ausnahmen und Variablen sie berücksichtigt und kennt, desto ineffektiver wird sie zwangsläufig. von der kleinen Engine bis hin zum Monster, was allerlei Plugins, Dynamiken und Ausnahmen kennt, ist bei WordPress quasi alles vertreten. Getestet habe ich sie über die Jahre hinweg eigentlich ebenfalls alle, sei es aus reinem Interesse oder durch die Hoffnung für eine neue interessante Lösung. So viel „Neues“ gibt es im Bereich WordPress Caching aber gar nicht und vor allem die minimalen Erweiterungen haben sich dabei als besonders effizient erwiesen. Heute geht es bei den Plugins eher darum, neben Kompatibilität die Laufwege und Umleitungen so winzig und schnell wie nur irgendwie möglich zu generieren. Dem einen Caching Plugin gelingt das besser, dem anderen weniger.

Während W3 Total Cache früher das einzige ernstzunehmende Caching Plugin für WordPress war, welches noch dazu von einem prominenten Entwickler, nämlich dem Mashable CTO Frederick Townes, stammte, hat sich die Landschaft der Caching Plugins für WordPress heute zum Glück deutlich verändert. W3 Total Cache gilt für die meisten WordPress-Nutzer inzwischen als überladen, es ist eher die Lösung für extrem große und komplexe Blogs, die eine so mächtige Caching Engine überhaupt benötigen. Der große Erfolg in letzter Zeit war dagegen WP Rocket, denn das kommerzielle Caching Plugin machte wenig anders, aber alles ein wenig besser. Mit Einfachheit, hoher Kompatibilität und aktivem Support, überzeugte WP Rocket viele Kunden und im Test damals wie heute auch mich. Wer es noch schneller und noch einfacher möchte, sollte trotzdem zum Cache Enabler greifen. Das WordPress Caching Plugin baut auf der sehr minimalistischen Caching-Erweiterung Cachify auf. Ich selbst nutzte übrigens eine angepasste Version von Cachify für meine Blogs. Wer Support und etwas Schnick Schnack (Lazy Load und Co) möchte, kauft sich eine Lizenz für WP Rocket. Von allen anderen Caching Plugins rate ich inzwischen tatsächlich ab, weil ich entweder schlechte Erfahrungen gemacht habe, oder ganz einfach keinen Mehrwert gegenüber den erwähnten Lösungen feststelle. Als Methode sollte dabei immer der Disk Cache, also der HDD Cache in den Optionen gewählt werden. Memory, APC und Co haben sich in vielen Fällen als ineffizient erwiesen und die richtige Konfiguration ist für normale Anwender nicht immer verständlich oder ganz einfach umzusetzen, zumal es dann wieder zu Kompatibilitätsproblemen kommen kann.

Browser Caching mit .htaccess

Wie die perfekte htaccess aufgebaut sein sollte erfahrt ihr in unserem Artikel die ultimative htaccess für WordPress

Wer für WordPress erfolgreich ein Caching Plugin installiert und eingerichtet hat, der hat das Wichtigste bereits erledigt. Wobei, eigentlich ist der Browser Cache noch um einiges wichtiger, denn der bestimmt ob eine Datei erneut vom Server geladen werden muss, oder die Kopie im Cache des jeweiligen Browsers verbleibt und somit fortan genutzt werden kann. Um das ganze noch einmal zu verdeutlichen, folgendes Beispiel: Ihr surft auf einer Website vorbei und seht ein tolles Bild. Das Bild hat Postermaße, also eine sehr hohe Auflösung, und das Laden dauert ca. 10 Sekunden. Stück für Stück baut sich die Grafik gähnend langsam vor euch auf und als sie dann endlich vollständig geladen ist, seit ihr begeistert. Das Bild ist so toll, dass ihr es später noch einmal eurer Schwester zeigen wollt, wenn diese am Abend von der Arbeit kommt. Als sie dann kommt und ihr den Laptop auf die Couch holt, hofft ihr sofort, dass es nicht wieder 10 Sekunden dauert bis das Bild angezeigt wird. Beim Aufruf erscheint es dann auch tatsächlich sofort, nicht einmal 1 Sekunde musstet ihr warten. Warum? Weil das Bild beim ersten mal vom Server geladen werden musste, beim zweiten Aufruf aber schon im Browser Cache lag und sich deshalb auf eurer Festplatte befand, also direkt angezeigt werden konnte. Es war kein erneuter Connect zum Server notwendig, ebenso wenig wie der erneute Download.

Verstanden? Der Browser Cache speichert Bilder, Seiten, Dateien, eben alles was eine Website so mit sich bringt. Je nach Einstellung des Webmasters, braucht der Nutzer die Dateien im Cache beim erneuten Besuch also nicht noch einmal vom Server laden, sondern hat bereits eine lokale Kopie auf der eigenen Festplatte. Der Browser speichert die Seite also automatisch und behält sie genau so lange, wie es der Browser Cache der jeweiligen Website erlaubt. Das ist äußerst praktisch, nicht nur für den Nutzer der keine Ladezeiten für diese Dateien mehr benötigt, sondern auch für euch als Webmaster, denn so könnt ihr die Serverlast extrem reduzieren. Wenn das Bild beim Nutzer liegt, muss es schließlich nicht erst vom Server heruntergeladen werden. Das Resultat: Der Nutzer hat geringere Ladezeiten und der Webmaster erhöht allgemein die Performance, da der Server deutlich entlastet wird. Win-Win-Situation für alle.

Die am häufigsten verwendete Methode für das Browser Caching, sind die sogenannten Cache-Control Headers. Diese legen den genauen Ablauf einer Datei fest, sodass sie zum Beispiel nur für eine Woche, einen Monat, ein Jahr, oder vielleicht doch nur für eine Stunde im Browser Cache des jeweiligen Besuchers verbleibt. Hier solltet ihr euch also vorher überlegen, wie oft sich Inhalte bei euch ändern und den Wert entsprechend anpassen. Der Browser Cache lässt sich nämlich nicht aus der Ferne leeren, er leert sich also nur wenn der Nutzer ihn löscht oder der Cache-Reload durch mehrmaliges nachladen erzwungen wird. Soll heißen: Wenn ihr aus versehen den Browser Cache für HTML-Seiten auf ein Jahr festlegt, sieht der Nutzer im schlimmsten Fall ein Jahr dieselbe Seite, weil der Cache so lange gültig ist und er ihn für die Seite im Normalfall auch nicht extra erneuert. Also vorher nachdenken, dann umsetzten.

Doch zurück zu den erwähnten Cache-Control Headers, die sich innerhalb der .htaccess-Datei festlegen lassen. Mit diesen Headern ist es möglich, die Ablaufzeit sämtlicher Dateien festzulegen und auch einen Standard zu setzten. Die Cache-Control Header setzten dabei einen „max-age“ Wert, also einen Wert der angibt, wie lange der Cache seine Gültigkeit behält. Dieser Wert wird immer in Sekunden angegeben, was zu den folgenden Werten führt:

  • Eine Minute: max-age=60
  • Eine Stunde: max-age=3600
  • Ein Tag: max-age=86400
  • Eine Woche: max-age=604800
  • Ein Monat: max-age=2628000
  • Ein Jahr: max-age=31536000

Von der Zeitspanne abgesehen, gibt es noch einen weiteren Wert innerhalb der Cache-Control Header. Mit „public“, „private“ und „no-store“, wird nämlich noch der Typ festlegt. Mit „public“ ist im Grunde alles erlaubt, der Cache wird also normal angelegt und dieser Wert stellt mehr oder weniger den Standard dar. „pirvate“ wird für Seiten genutzt, die bei jedem Besucher anders aussehen oder spezielle, auf ihn angepasste Inhalte enthalten. „no-store“ bedeutet hingegen, dass der Cache diesen Bereich auf gar keinen Fall und in keiner Form speichern soll. Im Grunde ist es dasselbe wie „private“, nur dass es eben keine Ausnahme für User Agent Caching gibt.

Doch wie sieht so ein Cache-Control Header denn nun genau aus? Was müsst ihr wirklich in eure .htaccess einfügen, um den Browser Cache effektiv zu nutzen? Dazu komme ich jetzt, denn nun fügen wir die oberen Parameter zu einem fertigen Code zusammen. Im Beispiel werden Bilder für ein Jahr, CSS- und Javascript-Dateien für einen Monat, sowie alles andere für eine Stunde in den Cache gelegt. Diesen Code könnt ihr natürlich frei anpassen und verändern, sodass Dateitypen und Zeiten sich eurem Blog und den typischen Zeitspannen für Aktualisierungen anpassen.

<IfModule mod_headers.c> <filesMatch ".(jpg|jpeg|png|gif|ico)$"> Header set Cache-Control "max-age=31536000, public" </filesMatch> <filesMatch ".(css|js)$"> Header set Cache-Control "max-age=2628000, public" </filesMatch> Header set Cache-Control "max-age=3600, public" </IfModule>

Den Browser Cache auch für HTML-Seiten zu nutzen, ist sehr selten geworden, von mir aber absolut empfohlen. Nehmen wir mal an, ihr veröffentlicht pro Tag einen Artikel in eurem WordPress Blog. Jeden Tag um genau 12:00 Uhr. Um 11:59 kommt nun ein Besucher auf euren Blog und die HTML-Seite landet im Browser Cache. Das bedeutet, dass er den neuen Artikel um 12:00 Uhr nicht sieht, denn als er um 12:15 Uhr wieder auf eure Seite kommt, wird ihm immer noch der Browser Cache angezeigt, denn wir hatten ja eine Gültigkeit von einer Stunde angegeben. Im Klartext heißt das also: Die Seite liegt eine Stunde in seinem Cache, den neuen Artikel sieht er erst um 12:59 Uhr, also eine Stunde nach dem Aufruf, weil erst dann die Version im Cache ihre Gültigkeit verliert. Ist das jetzt schlimm? Nein, denn wenn ihr keine zeitkritischen Inhalte oder News veröffentlicht, ist es doch vollkommen egal ob der Artikel nun um Punkt 12:00, oder erst um 12:59 Uhr gelesen wird. Der Vorteil solcher Cache-Zeiten ist dagegen groß, denn in der gesamten Stunde lädt der entsprechende Besucher nicht einmal etwas von eurem Server herunter, was diesen entsprechend entlastet. Daher rate ich persönlich immer zu langen Cache-Zeiten. Aber beachtet den Hinweis oben: Dateien die im Cache liegen, lassen sich unter Umständen nicht ohne weiteres tauschen und werden erst nach Ablauf der Gültigkeit erneuert.

Liegt die vom Browser angeforderte Seite schon im Cache, ist kein Kontakt zum Webserver mehr notwendig. Die Seite wird komplett aus dem Browser Cache geladen. Schneller gehts nicht und die Serverlast ist gleich null.

 

Serverseitiges WordPress Caching

An das Thema Serverseitiges Caching sollte sich definitiv kein Anfänger heranwagen, denn zu viel kann verbockt werden. Der Profi braucht dagegen kein Wissen und so beschränke ich mich hier auf die einfache Erklärung des ganzen. Serverseitiges Caching basiert im Grunde darauf, dass der Server das Caching einer Website übernimmt und die Ressourcen entsprechend klug verteilt. Realisiert wird dies mit verschiedenen Modulen, die je nach Anwendungsgebiet aber auch richtig konfiguriert werden müssen. Für WordPress Blogs ist das ebenfalls denkbar, denn die meisten Managed WordPress Hoster setzten auf eine serverseitige Lösung und verbieten im Gegenzug Caching Plugins, da diese die Kompatibilität dann wieder gefährden oder gar echte Probleme verursachen. Ein Beispiel wäre hier der Anbieter WP Engine, der eine eigene Technologie namens EverCache aufgebaut hat und jegliche Art von Caching Plugin verbietet, da sich die Server selbst effektiv und zielgenau um das Thema Caching kümmern. Wer sich mit all dem also gar nicht beschäftigen will, kann seinen Blog einfach bei Raidboxes hosten und sich den Ärger sparen. Raidboxes statt WP Engine deswegen, weil Raidboxes ein deutscher Service, mit deutschen Servern und entsprechender Anbindung ist. Kleine Info hier noch am Rande: Nicht alles was sich Managed WordPress Hosting nennt, ist auch echtes Managed WordPress Hosting. Meistens handelt es sich nur um „Fake-Pakete“ auf denen WordPress vorinstalliert ist oder ähnliches, dann gibt es beim Server selbst aber kaum bis gar keine Anpassungen. Echte Managed WordPress Hoster wie Raidboxes passen aber auch die Server an und optimieren alles ganz gezielt so, dass es perfekt mit WordPress zusammenarbeitet und dessen Schwächen ausgleicht. Doch zurück zum Thema: Beim serverseitigen Caching gibt es am ende viele kleine Details zu beachten und Anfänger sollten einfach die Finger davon lassen. Eventuell werde ich diesen Absatz in Zukunft aber noch einmal ausbauen und ausführlich beleuchten, um auch für das serverseitige Caching entsprechende Tipps zu geben.

 

Ist Caching ein Google-Ranking Faktor?

Wie inzwischen bekannt ist, wertet Google die Performance einer Website als Ranking-Faktor. Dazu zählen die grundsätzlichen Ladezeiten, aber auch die Reaktionszeit bzw. Antwortzeit des Servers selbst. Beides lässt sich mit dem richtigen WordPress Caching perfektionieren. Ist das Caching Plugin nämlich sauber und korrekt eingerichtet, erhöht sich die Geschwindigkeit des eigenen Blogs enorm. Daraus resultiert dann, dass der Server entlastet wird und wieder mit schnelleren Antwortzeiten aufwartet. WordPress Caching ist also nicht nur für die Leser des eigenen Blogs von Vorteil, sondern mit perfekter Performance verbessert ihr auch immer euer Google-Ranking. Caching ist dabei ein sehr wichtiger und einfach zu beherrschender Aspekt, gerade weil WordPress hier viele Plugins als Fertiglösung anbietet. Ganz einfach also.

Effizientes WordPress Caching

Weil das Thema Caching, gerade in Bezug auf WordPress, doch ein recht komplexes Themengebiet ist, war es mir ein Anliegen selbiges detailliert aufzuschlüsseln und bestimmte Aspekte des Ganzen genauer zu beleuchten. Ich hoffe diese Seite erfüllt ihren Zweck und hilft vor allem Anfängern dabei, das Thema WordPress Caching und Caching allgemein besser zu verstehen. Für viele ist es nämlich immer noch gänzlich unbekannt und es gibt durchaus noch eine Menge WordPress Blogs die gar kein Caching Plugin einsetzten. Das basiert dann oft auf der Unerfahrenheit, denn nicht jeder liest sich in die Thematik ein und WordPress ist eben ein CMS für Anfänger, die oft nicht über den Tellerrand hinausblicken. Doch einen Blog zu führen bedeutet am Ende eben doch mehr, als nur hin und wieder einen Artikel zu verfassen. Auch die Technik, die Performance, sowie natürlich die allgemeine Sicherheit muss im Auge behalten werden.

Christian
Christian
Mein Name ist Christian und ich bin Mitgründer der Plattform fastWP. Hier im Magazin bin ich für die eher "technisch" lastigen Themen zuständig aber schreibe gerne über das Thema SEO, das nun bereits seit über 10 Jahren zu meiner Leidenschaft gehört.

HINTERLASSEN SIE EINE ANTWORT

Please enter your comment!
Please enter your name here

fastWP

Finde den passenden WordPress Dienstleister in deiner Region!

Deine Werbung hier?

Nutze die Reichweite von fastWP und erreiche deine Zielgruppe!