In diesem Artikel werde ich versuchen, die meisten neuen und nicht so neuen Webmaster näher zu bringen, was ist der WordPress-Cache und wie können wir unseren Blog dazu bringen, schnellere Antwortzeiten anzubieten. Wir sind es gewohnt zu lesen, dass wir ein Cache-Plugin verwenden müssen, wenn wir in unseren WordPress-Blogs eine schnellere Antwort erzielen möchten. Nachdem er dies gelesen hat, wird jeder Administrator eines WordPress-Blogs von einem Cache-Plugin gestartet und möchte kein Plugin installieren. Er möchte das beste installieren. Die erste Überraschung ist, dass es kein besseres Cache-Plugin gibt , aber wir haben mehrere zur Verfügung, die sich besser oder schlechter an die Bedürfnisse und Bedingungen jedes Benutzers anpassen können.
Als nächstes werde ich versuchen, eine Reihe von Konzepten zu beschreiben, die Ihnen das Verständnis des WordPress-Cache erleichtern und Ihnen gleichzeitig bei der Auswahl von Konfigurationsoptionen in Cache-Plugins helfen.
Konzepte zum Verständnis des WordPress-Cache
Statischer Seiten-Cache (statisches Seiten-Caching).
Wenn wir ein Cache-Plugin in unserem WordPress-Blog installieren, wenden wir uns in den meisten Fällen dieser Art von Cache zu. Diese Technik besteht aus dem Speichern des Inhalts der Seiten unseres Blogs, dh der gesamte HTML-Code wird gespeichert. Auf diese Weise stellen wir sicher, dass WordPress nicht den gesamten Code der Seite mit PHP neu generieren muss, wodurch wiederum SQL-Anforderungen gestellt werden. Von hier aus können Sie sich vorstellen, dass das Bereitstellen von HTML-Code, der bereits direkt generiert wurde, viel weniger Ressourcen benötigt als das Neuerstellen und Bereitstellen.
Es ist klar, dass wir weniger Ressourcen verbrauchen, aber dies hat einen Nachteil, wenn unser Blog dynamische Elemente enthält, dh sie ändern sich mit der Zeit. Um diese “dynamischen Elemente” zu verstehen, werden wir uns vorstellen, dass in meinem WordPress-Blog jedes Mal, wenn jemand ihn besucht, mit PHP ein Abbild einer Uhr erstellt wird, die die Zeit angibt, die Minuten und Sekunden angibt. Das Cache-Plugin speichert den gesamten HTML-Code einschließlich des Bildes der Uhr, das den Zeitpunkt angibt, zu dem das Plugin die Seite erstellt hat (wir gehen davon aus, dass die Uhr 18 Stunden, 20 Minuten und 5 Sekunden anzeigt). Das Problem tritt auf, wenn ein Besucher um 18 Stunden, 21 Minuten und 2 Sekunden auf unserer Seite ankommt, da die Uhr den Zeitpunkt angibt, zu dem das Cache-Plugin die Seite generiert hat, und nicht die aktuelle Uhrzeit.
Das vorherige Beispiel soll Ihnen helfen, das Problem des statischen Seiten-Cache besser zu verstehen, da dieses Problem der Uhr mithilfe von Technologien wie AJAX oder Javascript leicht zu lösen wäre, der Zweck dieses Artikels jedoch nicht besteht.
Aus diesem Grund haben Cache-Plugins normalerweise Optionen, um festzulegen, wie oft die im Cache gespeicherten Seiten neu erstellt werden sollen. Einige Plugins generieren sogar die Seite, wenn wir den Artikel ändern, und generieren sogar die Archive von Kategorien und Labels erneut, sodass sie den neu veröffentlichten Artikel anzeigen.
Objekt-Cache (Objekt-Caching).
Der Objekt-Cache besteht aus dem Speichern kleiner Teile des Codes. Normalerweise sind diese Objekte Codes vom Typ get_option( 'algo' ); Das häufigste Beispiel für die Ausführung auf nahezu allen WordPress-Seiten ist get_option( 'blogname' ); Sie erhalten den Namen unseres Blogs. Die Ausführung dieser Objekte umfasst im Allgemeinen das Erstellen einer oder mehrerer SQL-Anforderungen, die eine erhebliche Menge an Ressourcen verbrauchen.
Permanente Objektzwischenspeicherung.
Die Objekte, über die wir zuvor gesprochen haben, müssen dauerhaft im Cache gespeichert werden, dh, sie sind im Laufe der Zeit im Cache verfügbar. Die verschiedenen WordPress-Cache-Plugins müssen eine Datei mit dem Namen object-cache.php im Ordner /wp-content/ erstellen, um den dauerhaften Objekt-Cache zu erhalten.
Sobald diese Datei erstellt wurde, wird die WordPress-Objekt-Cache-API gestartet, wodurch uns SQL-Anforderungen erspart und der Ressourcenverbrauch reduziert wird. Der Optimierungsprozess endet hier nicht, da wir bestimmen müssen, wo und wie dieser Objektcache gespeichert wird. Sie werden normalerweise auf der Festplatte gespeichert, was nicht die schnellste Option ist. Unsere beste Option ist die Verwendung einer Art von Opcode-Cache als APC oder eAccelerator (leider sind diese Optionen bei den meisten gemeinsam genutzten Hosts nicht verfügbar).
Als zusätzliche Information, sagen Sie, dass wenn Sie PHP in Version 5.5 oder höher verwenden, APC nicht mehr enthalten ist, da es durch Zend Opcache ersetzt wurde. Letzteres hat den Nachteil, dass es keinen Objekt-Cache unterstützt. Obwohl die Entwicklung von APC offiziell eingestellt wurde, gibt es eine Version der APCu- Alternative, die wir als Ersatz für APC verwenden können.
An diesem Punkt wundern sich viele von Ihnen vielleicht: “Wenn ich den statischen Seiten-Cache verwende, der den gesamten HTML-Code generiert und ihn dann den Besuchern zur Verfügung stellt, warum möchte ich den Objekt-Cache aktivieren?”
Ein Objekt-Cache-System wird uns bei der Ausführung des Cache-Plugins zugute kommen, wenn Sie den HTML-Code unserer Seiten generieren. Die Theorie besagt, dass die Generierung jeder Seite mit dem Cache von Festplattenobjekten länger dauert, aber weniger Serverressourcen verbraucht. Wenn unser Blog auch die Möglichkeit bietet, Benutzer zu registrieren und mit dem Blog zu interagieren (Kommentare posten, Bilder hochladen usw.), wird dringend empfohlen, ein Objekt-Cache-System zu verwenden. Aus diesem Grund schließen wir mit der Tatsache, dass ein Objekt-Cache-System für uns immer von Vorteil ist, da wir Ressourcen sparen.
Kurz gesagt, wenn wir WordPress optimieren, müssen wir ein Gleichgewicht zwischen einem angemessenen Ressourcenverbrauch und einer möglichst kurzen Reaktionszeit finden.
