Du siehst diese Seite bestimmt deswegen, weil Du in den Suchmaschinen nach einer deutschen Anleitung für das WordPress Plugin W3 Total Cache gesucht hast. Dieser Artikel ist der zweite Teil einer ganzen Reihe an Anleitungen zu diesem Plugin. In einem anderen Artikel bin ich bereits auf die Grundeinstellungen von W3 Total Cache eingegangen und habe dort erklärt, welchen Zweck die verschiedenen Einstellungen erfüllen sollen. In diesem zweiten Teil möchte ich nun auf die detaillierten Einstellungen der Funktion: „Page Cache“ eingehen und versuche damit zu erklären, was davon auf jeden Fall aktiviert werden sollte und was man je nach Servereinstellung deaktiviert lassen kann. Lasst uns also mit der Anleitung beginnen.

Hinweis

Diese Anleitung zu W3 Total Cache ist der zweite Teil einer ganzen Reihe. Den ersten Teil dieser Anleitung habe ich bereits in diesem Artikel verfasst. Dort wird auf die generellen Einstellungen von W3 Total Cache eingegangen.



Wo finde ich die Einstellung: „Page Cache“?

Ich gehe in dieser Anleitung davon aus, dass das Plugin W3 Total Cache in Eurer WordPress Seite installiert und aktiviert ist. Wenn dies der Fall ist, können wir sofort zu den Einstellungen in W3 Total Cache übergehen. Klicken wir dazu in unserem WordPress Dashboard (Was ist ein Dashboard?) auf: „Performance“.

Woredpress Plugin W3 Total Cache - Menü Performance Cache

Es öffnet sich nun das W3 Total Cache Dashboard, welches ich in unserem ersten Teil der Anleitung bereits beschrieben habe. Wir können nun im linken Menü unserer WordPress Seite auf: „Page Cache“ klicken, um in die erweiterten Einstellungen des „Page Cache“ zu gelangen. (Hier rot markiert)

Page Cache: General:

Wordpress W3 Total Cache - Erweiterte Einstellungen bearbeiten - General

Es öffnen sich nun die Einstellungen zum Page Cache von W3 Total Cache. Ab jetzt werden wir uns von Menü zu Menü durcharbeiten. Lasst uns also als Erstes mit den generellen Einstellungen (General) beginnen. Wie im Screenshot zu sehen ist, gibt es verschiedene Möglichkeiten, unsere WordPress Seite zu cachen. Anbei die Auflistung und die dahinter steckende Funktion, die mit der aktivierten bzw. deaktivierten Option erreicht werden soll.

  • Cache front page: Diese Funktion sollte in jedem Falle aktiviert werden, da sie bewirkt, dass die Startseite unserer WordPress Seite gecached wird. Da die meisten Besucher hier zuerst landen, sollte diese Seite auch in das Caching einbezogen werden.
  • Cache feeds: site, categories, tags, comments: Wenn wir einen oder mehrere RSS Feeds unserer Internetseite zur Verfügung stellen und diese Feeds dann auch einem Dienst wie beispielsweise Feedburner zur Verfügung stellen, können wir dadurch die Performance unserer Servers schonen. Diese Feeds werden dann nämlich ebenfalls gecached.
  • Cache SSL (https) requests: Wenn unsere Internetseite mit SS betrieben wird, kann man diese Funktion durchaus aktivieren. Dadurch werten SSL (HTTPS://) Anfragen ebenfalls auf unserem Webserver gecached. Wie man SSL in WordPress aktiviert, hat Tobias Redmann in seinem Blog recht leicht verständlich erklärt.
  • Cache URIs with query string variables: Ist diese Funktion aktiviert, werden auch Suchergebnisse unserer WordPress Seite gecached. Diese Funktion lässt sich aber nur dann aktivieren, wenn man in den generellen Einstellungen unter: „Page Cache Method“ nicht die Funktion: „Disk: Enhanced“ ausgewählt hat. Man könnte, um die Funktion zu aktivieren, auf: „Disk: Basic“ umstellen. Was aber das komplette Page Caching verlangsamt. Da dieses Caching Verfahren wesentlich langsamer ist. Warum das so ist, werden wir in einem späteren Teil unserer Anleitung erfahren.
  • Cache 404 (not found) pages: Es kommt immer wieder vor, dass in unserer WordPress Seite eine Seite verschwindet oder umbenannt wurde und somit nicht mehr erreichbar ist. Es wird dann den Suchmaschinen eine Error 404 (Seite nicht gefunden) Fehlermeldung ausgegeben . Aktivieren wir diese Funktion jedoch in W3 Total Cache, kann es passieren, dass diese Cache Version unserer 404-Seite als gefundene Seite auf unserem Webserver ausgegeben wird. Das würde bedeuten, dass die Suchmaschinen fälschlicherweise den HTTP Statuscode 200 (Bedeutet: Die Anfrage wurde erfolgreich bearbeitet und das Ergebnis der Anfrage wird in der Antwort übertragen.) Da wir als verantwortungsbewusste Administratoren unserer Internetseite vermeiden wollen, dass eine Seite nicht erreichbar ist, werden wir diese Funktion nicht benötigen und riskieren auch gar nicht erst die falsche Meldung. Wer mehr über HTTP Statuscodes erfahren möchte, kann sich gerne mal den Wikipedia-Eintrag dazu durchlesen.
  • Cache requests only for „domain.de“ site address: Diese Funktion sollte in jedem Fall aktiviert werden, da wir W3 Total Cache damit befehlen, ausschließlich unsere Domain zu cachen. Welche Domain zu unserer WordPress Seite gehört, haben wir ja bei der Installation von WordPress festgelegt. Wer diese Einstellung ändern oder überprüfen möchte, muss in den allgemeinen Einstellungen von WordPress nachschauen.
  • Don’t cache pages for logged in users: Diese Funktion bewirkt, dass angemeldete Benutzer Zugriff auf ihre personalisierte und vor allem Seite erhalten, die sich nicht im Cache befindet. Registrierte bzw. angemeldete Nutzer unserer Webseite benötigen unsere Seite nicht als Cache, da sie sonst auch von unangemeldeten Benutzern eingesehen werden könnte. Diese Funktion würde also eher ein Sicherheitsrisiko darstellen. Daher empfehle ich, die Funktion zu aktivieren.
  • Don’t cache pages for following user roles: Diese Funktion macht nur dann einen Sinn, wenn die vorige Funktion deaktiviert ist. Hier können wir festlegen, für welche Benutzergruppen (also Administratoren, Autoren, Moderatoren, etc.) unsere Seite in den Cache abgelegt werden soll oder nicht.

Man könnte diese Funktion aber auch beispielsweise dazu nutzen, dass der Administrator unserer Seite, nie  Seiten angezeigt bekommt, die sich im Cache befinden. Das macht zum Beispiel dann Sinn, wenn man gerade am Theme der Seite arbeitet oder Einstellungen vornimmt, die nur nach dem Löschen des Cache sichtbar werden.

Page Cache:  Cache Preload:

Wordpress Cache - Page Cache - Preload

  • Update interval: In W3 Total Cache wird damit die Möglichkeit geboten, festzulegen in welchen Abständen der Cache unserer Internetseite aktualisiert werden soll. In unserem Beispiel werden alle 900 Sekunden (das entspricht 15 Minuten) unsere Seite gecached. Bei einem normalen Blog, wie es meiner ist, reicht das durchaus aus. Würden wir jetzt eine riesige Worpdress Seite betreiben, in der permanent neue Artikel, Kommentare, etc. geschrieben werden, sollten wir den Wert verringern. Das würde jedoch auch bedeuten, dass mehr Serverlast anfallen wird.
  • Pages per interval: Mit dieser Funktion können wir festlegen, wie viele Seiten bei einem Durchlauf von W3 Total Cache gecached werden. Mit der aktuellen Einstellung werden 10 Seiten in einem Durchlauf berücksichtigt, was bei der Größe meiner Internetseite durchaus ausreichend ist. Wer einen schwächeren Webeserver nutzt, sollte den Wert vielleicht verringern. Wer wiederum einen stärkeren Webserver hat und auch eine größere Seite betreibt, kann den Wert auch erhöhen. Das sollte einfach mal ausprobiert werden.
  • Sitemap URL: Mit dieser Funktion können wir festlegen, ob die Sitemap unserer Seite gecached wird. Falls Du noch keine Sitemap Datei erstellt hast, kann ich Dir das Plugin: „Wordpress Seo“ von Yoast Seo empfehlen. Dieses findest Du unter folgendem Download Link.
Yoast SEO
Yoast SEO
Entwickler: Team Yoast
Preis: Kostenlos
  • Yoast SEO Screenshot
  • Yoast SEO Screenshot
  • Yoast SEO Screenshot
  • Yoast SEO Screenshot
  • Yoast SEO Screenshot
  • Yoast SEO Screenshot

Page Cache: Purge Policy:

 Wordpress Purge Ploicy - Feeds, Kommentare, Beiträge cachen

Mit dieser Funktion können wir W3 Total Cache so einstellen, dass es sich an unserer Vorgaben hält, wenn es den veralteten Cache unserer Seiten, Beiträge bzw. Artikel löschen soll. Der Cache wird in W3 Total Cache auch nur dann gelöscht, wenn wir eine neuen Beitrag, Seite oder einen Kommentar veröffentlichen. Veralteter Cache wird dann automatisch gelöscht, wenn wir eine Seite oder einen Artikel bearbeiten bzw. aktualisieren. Die Standardeinstellungen kann man in der Regel ohne weiteres übernehmen, da dadurch auch am wenigsten Rechenleistung unseres Webservers beansprucht wird.

Da wir unsere WordPress RSS Feeds in der Regel im RSS2.0 Format zur Verfügung stellen, können wir auch diese Einstellung lassen, wie sie hier im Screenshot zu sehen ist.

  • Purge Limit: Mit dem Purge Limit legen wir fest, wie viele Artikel oder Seiten aus dem Cache gelöscht werden, wenn wir beispielsweise einen dazugehörigen Artikel erstellen oder bearbeiten. Damit soll erreicht werden, dass nicht alle dazugehörigen Artikel oder Seiten (Beispielsweise im Archiv) gleichzeitig gelöscht und wieder gecached werden.
  • Additional Pages: Sollten wir in unserer WordPress Installation Seiten haben, die nicht zum WordPress Standard gehören, können wir diese mit dieser Einstellung ebenfalls W3 Total Cache dazu bewegen, diese Seiten oder Verzeichnisse beim Cachen bzw. beim Löschen des Caches zu berücksichtigen.
  • Purge sitemaps: Diese Einstellung ist für das Löschen des Sitemap.xml Caches zuständig. Sollte unsere Sitemap.xml Datei irgendwelche Sonderzeichen beinhalten, können wir diese hier festlegen. Die meisten unter uns werden zur Erstellung der Sitemap.xml Datei das WordPress Seo Plugin von Yoast nutzen, was dann wiederum bedeutet, dass wir hier keine Einstellungen vornehmen müssen.

Page Cache: Advanced:

Wordpress-Advanced-Page-Cache-Einstellungen-W3-Total-Cache

Wordpress Advanced Quiery Strings in W3 Total Cache

Wordpress Advanced Cache Exception List

In den erweiterten Einstellung von W3 Total Cache – Page Cache, kann man nun noch unzählige Feinabstimmungen vornehmen. Beginnen wir wieder mit der ersten Einstellung und arbeiten uns dann von Einstellung zu Einstellung nach unten durch.

  • Late initialization: Aktivieren wir diese Funktion, kann das Reaktionszeit unserer WordPress Seite bzw. die des Webservers negativ beeinflussen. Diese Funktion können wir mit unseren aktuellen Einstellungen jedoch nicht aktivieren, da wir in den generellen Einstellungen: „Disk:Enhanced“ ausgewählt haben.

Mit dieser Funktion wird es ermöglicht, das Caching bestimmter Teile einer Seite zu aktivieren bzw. zu deaktivieren. Um diese Funktion ein wenig zu verdeutlichen, habe ich folgendes Beispiel. Nehmen wir an, dass sich in einer WordPress Seite, eine von uns erstellte Tabelle mit Jahreszahlen aus dem vorherigen Geschäftsjahr befindet. Nun könnte man W3 Total Cache soweit konfigurieren, dass diese Tabelle in unserer WordPress Seite nicht neu gecached wird, sondern nur der Rest, der sich um dieser Tabelle befindet. In solch einem Fall spricht man vom: „fragment caching“.

Ich weiß, man kann mit dieser Funktion wesentlich mehr anstellen, aber ich hoffe, dass ich die Funktion damit verständlicher erklärt habe, als es die Programmierer und Entwicklerseiten im Netz machen bzw. gemacht haben. Wer wiederum von dieser Funktion Gebrauch machen möchte, muss erstens die Einstellung in den generellen Einstellungen machen. Zweitens sollte er sich dann in der W3 Total Cache FAQ (Häufig gestellte Fragen) die Anleitung dazu durchlesen.

  • Compatibility mode: Diese Funktion sollten wir in jedem Fall aktivieren. Dadurch wird auf unseren Webservern rund 20% Rechenleistung eingespart. Wie diese Funktion genau arbeitet, kann ich leider nicht erklären, da ich im Netz nur Empfehlungen gefunden habe, diese Einstellung zu aktivieren. Unter anderem vom W3 Total Cache Entwickler. Sorry, aber wenn jemand mir da auf die Sprünge helfen möchte, kann er das gerne tun. J
  • Charset: Sollte es beim Cache unserer Seiten zu Fehlern in der Zeichenkodierung kommen, können wir mit dieser Funktion testen, ob es an dem Plugin W3 Total Cache liegt. Sollten keine Probleme bei der Charset (Zeichenkodierung) unserer Internetseite geben, können wir diese Funktion ohne weiteres deaktiviert lassen. Sollte es bei aktivierter Funktion dennoch zu Problemen kommen, müsste das Problem woanders gesucht werden.
  • Reject HEAD requests: Unter „Head Request“ versteht man Daten, die in einer Internetseite enthalten sind. Eine Teil dieser Daten sind beispielsweise Informationen darüber, ob bzw. wann eine Internetseite das letzte Mal aktualisiert wurde. Aktivieren wir diese Funktion, werden diese Head Requests nicht gecached. Da dies aber häufig zu weißen leeren Seiten führt, empfehle ich diese Funktion zu deaktivieren.
  • Garbage collection interval: Diese Einstellung spielt dann eine Rolle, wenn wir unseren Cache auf der Festplatte unseres Webservers ablegen. Da dies bei den meisten Shared Hosting Anbietern der Fall ist, können wir hier festlegen, in welchem Intervall veralteter Cache gelöscht wird. Standardmäßig sind hier 3600 Sekunden (das entspricht 60 Minuten) eingestellt. Diese Einstellung können wir auch ohne weiteres übernehmen. Ab dem Moment, wo der Traffic unserer Internetseite ansteigt, können wir darüber nachdenken, den Zeitraum bis zum nächsten Löschvorgangs des Caches zu verkürzen. Das würde dann aber auch mehr Rechenleistung für unseren Webserver bedeuten.
  • Comment cookie lifetime: In diesem Einstellungspunkt von W3 Total Cache können wir festlegen, wie lange Cookies zu Kommentaren im Browser unserer Seitenbesucher gültig sind. Verringern wir diesen Wert, wird die Lebensdauer dieser Cookies verringert. W3 Total Cache arbeitet so, dass Seiten, die durch einen Besucher kommentiert wurden, nach– wie in unserem Fall – 1800 Sekunden (das entspricht 30 Minuten) neu gecached werden. Zum Vergleich, Worpdress ist so eingestellt, dass Kommentar Cookies eine Lebensdauer von 30000000 Sekunden (das entspricht mehr als 347 Tage). Wer diese Funktion in W3 Total Cache komplett deaktivieren möchte und lieber den WordPress Standard übernehmen will, muss hier den Wert: „-1“ eintragen.
  • Accepted query strings: In diesem Feld können wir Query Strings eintragen. Insofern wir keine Programmierer sind und uns nicht damit auskennen, wozu diese Strings gedacht sind, ignorieren wir dieses Feld.
  • Rejected User Agents: In diesem Feld können wir festlegen, ob ein bestimmter User Agent den Cache ausgeliefert bekommt oder nicht. Diese Einstellung sollten wir ebenfalls ignorieren, wenn wir nicht genau wissen, warum wir bestimmte User Agents vom Caching ausschließen sollen.
  • Rejected cookies: Mit dieser Einstellung können wir W3 Total Cache dazu bewegen, bestimmte Seiten nicht zu cachen, die ein von uns festgelegtes Cookie beinhalten. Diese Einstellung können wir ebenfalls ignorieren, da dies in Regel den Programmierern oder professionelleren Anwendern unter uns dient.
  • Never cache the following pages: Mit dieser Einstellung können wir festlegen, welche WordPress Seiten nicht beim Caching berücksichtigt werden. Diese Einstellung ist eher für Programmierer interessant und kann für uns als „Normalsterbliche“ so belassen werden.
  • Cache exception list: In dieser Enstellung können wir festlegen, dass bestimmte Seiten und Verzeichnisse von W3 Total Cache gecached werden. Auch wenn sie im vorigen Menü eingetragen sind. Hier kann man also quasi die Ausnahmen zu nicht zu cachenden Seiten bzw. Strukturen eintragen.
  • Specify page headers: Wenn wir weitere Header festlegen möchten, die beim Caching berücksichtigt werden, müssen wir diese hier eintragen. Diese Einstellung können wir – als normaler Benutzer – so belassen, wie sie in den Standardeinstellungen vorgegeben ist.

it dieser Funktion wird es ermöglicht, das Caching bestimmter Teile einer Seite zu aktivieren bzw. zu deaktivieren. Um diese Funktion ein wenig zu verdeutlichen, habe ich folgendes Beispiel. Nehmen wir an, dass sich in einer WordPress Seite, eine von uns erstellte Tabelle mit Jahreszahlen aus dem vorherigen Geschäftsjahr befindet. Nun könnte man W3 Total Cache soweit konfigurieren, dass diese Tabelle in unserer WordPress Seite nicht neu gecached wird, sondern nur der Rest, der sich um dieser Tabelle befindet. In solch einem Fall spricht man vom: „fragment caching“.

Ich weiß, man kann mit dieser Funktion wesentlich mehr anstellen, aber ich hoffe, dass ich die Funktion damit verständlicher erklärt habe, als es die Programmierer und Entwicklerseiten im Netz machen bzw. gemacht haben. Wer wiederum von dieser Funktion Gebrauch machen möchte, muss erstens die Einstellung in den generellen Einstellungen machen. Zweitens sollte er sich dann in der W3 Total Cache FAQ (Häufig gestellte Fragen) die Anleitung dazu durchlesen.

  • Compatibility mode: Diese Funktion sollten wir in jedem Fall aktivieren. Dadurch wird auf unseren Webservern rund 20% Rechenleistung eingespart. Wie diese Funktion genau arbeitet, kann ich leider nicht erklären, da ich im Netz nur Empfehlungen gefunden habe, diese Einstellung zu aktivieren. Unter anderem vom W3 Total Cache Entwickler. Sorry, aber wenn jemand mir da auf die Sprünge helfen möchte, kann er das gerne tun. J
  • Charset: Sollte es beim Cache unserer Seiten zu Fehlern in der Zeichenkodierung kommen, können wir mit dieser Funktion testen, ob es an dem Plugin W3 Total Cache liegt. Sollten keine Probleme bei der Charset (Zeichenkodierung) unserer Internetseite geben, können wir diese Funktion ohne weiteres deaktiviert lassen. Sollte es bei aktivierter Funktion dennoch zu Problemen kommen, müsste das Problem woanders gesucht werden.
  • Reject HEAD requests: Unter „Head Request“ versteht man Daten, die in einer Internetseite enthalten sind. Eine Teil dieser Daten sind beispielsweise Informationen darüber, ob bzw. wann eine Internetseite das letzte Mal aktualisiert wurde. Aktivieren wir diese Funktion, werden diese Head Requests nicht gecached. Da dies aber häufig zu weißen leeren Seiten führt, empfehle ich diese Funktion zu deaktivieren.
  • Garbage collection interval: Diese Einstellung spielt dann eine Rolle, wenn wir unseren Cache auf der Festplatte unseres Webservers ablegen. Da dies bei den meisten Shared Hosting Anbietern der Fall ist, können wir hier festlegen, in welchem Intervall veralteter Cache gelöscht wird. Standardmäßig sind hier 3600 Sekunden (das entspricht 60 Minuten) eingestellt. Diese Einstellung können wir auch ohne weiteres übernehmen. Ab dem Moment, wo der Traffic unserer Internetseite ansteigt, können wir darüber nachdenken, den Zeitraum bis zum nächsten Löschvorgangs des Caches zu löschen.
  • Comment cookie lifetime: In diesem Einstellungspunkt von W3 Total Cache können wir festlegen, wie lange Cookies zu Kommentaren im Browser unserer Seitenbesucher gespeichert werden. Verringern wir diesen Wert, wird die Lebensdauer dieser Cookies verringert. W3 Total Cache arbeitet so, dass Seiten, die durch einen Besucher kommentiert wurden, nach maximal – wie in unserem Fall – 1800 Sekunden (das entspricht 30 Minuten) neu gecached werden. Zum Vergleich, Worpdress ist so eingestellt, dass Kommentar Cookies eine Lebensdauer von 30000000 Sekunden (das entspricht mehr als 347 Tage). Wer diese Funktion in W3 Total Cache komplett deaktivieren möchte und lieber den WordPress Standard übernehmen will, muss hier den Wert: „-1“ eintragen.
  • Accepted query strings: In diesem Feld können wir Query Strings eintragen. Insofern wir keine Programmierer sind und uns nicht damit auskennen, wozu diese Strings gedacht sind, ignorieren wir dieses Feld.
  • Rejected User Agents: In diesem Feld können wir festlegen, ob ein bestimmter User Agent den Cache ausgeliefert bekommt oder nicht. Diese Einstellung sollten wir ebenfalls ignorieren, wenn wir nicht genau wissen, warum wir bestimmte User Agents vom Caching ausschließen sollen.
  • Rejected cookies: Mit dieser Einstellung können wir W3 Total Cache dazu bewegen, bestimmte Seiten nicht zu cachen, die ein von uns festgelegtes Cookie beinhalten. Diese Einstellung können wir ebenfalls ignorieren, da dies in Regel den Programmierern oder Professionellen unter uns dient.
  • Never cache the following pages: Mit dieser Einstellung können wir festlegen, welche WordPress Seiten nicht beim Caching berücksichtigt werden. Diese Einstellung ist eher für Programmierer interessant und kann für uns als „Normalsterbliche“ so belassen werden.
  • Cache exception list: In dieser Enstellung können wir festlegen, dass bestimmte Seiten und Verzeichnisse von W3 Total Cache gecached werden. Auch wenn sie im vorigen Menü eingetragen sind. Hier kann man also quasi die Ausnahmen zu nicht zu cachenden Seiten bzw. Strukturen eintragen.
  • Specify page headers: Wenn wir weitere Header festlegen möchten, die beim Caching berücksichtigt werden, müssen wir diese hier eintragen. Diese Einstellung können wir – als normaler Benutzer – so belassen, wie sie in den Standardeinstellungen vorgegeben ist.



Ein Teil dieser Einstellungen wird erst aktiv, wenn man auch die dazugehörige Browser Cache Einstellungen aktiviert. Wie das funktioniert, werde ich dann in der Anleitung zu den detaillierten Browser Cache Einstellungen in W3 Total Cache erklären.

Ich hoffe, dass ich mit diesem Artikel das WordPress W3 Total Cache ein wenig verständlicher machen konnte. Ich finde, je mehr man sich mit dem Plugin auseinander setzt, umso interessanter wird es. Es gibt zwar zahlreiche Internetseiten im Internet, die diverse Einstellungen vorgeben bzw. empfehlen und damit den ersten Umgang mit W3 Total Cache erleichtern, aber meiner Meinung nach, sollte man sich auch mit den weiteren Einstellungen befassen und sich zumindest im Klaren sein, was diese Einstellungen dann bewirken.

Falls Ihr Probleme, Fragen oder Verbesserungsvorschläge zu dieser Anleitung habt, würde ich mich über einen Kommentar dazu freuen. Im nächsten Teil dieser Anleitung werde ich dann auf die erweiterte Einstellung zu Minify eingehen. Bis dahin wünsche ich Euch viel Spaß mit dem Plugin.

GD Star Rating
loading...
W3 Total Cache Anleitung – Page Cache erklärt, 5.0 out of 5 based on 3 ratings
0 Kommentare

Dein Kommentar

An Diskussion beteiligen?
Hinterlasse uns Deinen Kommentar!

Schreibe einen Kommentar

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