Hier ist Ashley Rich von Delicious Brains, die über alle Caching-Ebenen schreibt, die für eine WordPress-Website relevant sind. Ich denke, wir alle wissen, dass Caching kompliziert ist, aber verdammt, es ist eine Reise, um alle Caches zu verstehen, die hier funktionieren. Der Sinn von Cache ist Geschwindigkeit und die Reduzierung der Belastung der schlimmsten Engpässe und langsamsten/beschäftigtsten Teile eines Web-Stacks.
Hier ist mein eigenes Verständnis
- Dateien können vom Browser gecacht werden. Dies ist der schnellste mögliche Cache, da keine Netzwerkanfrage stattfindet. Assets wie Bilder, CSS und JavaScript werden oft auf diese Weise gecacht, da sie sich nicht besonders häufig ändern, aber Sie müssen sicherstellen, dass Sie den Browsern mitteilen, dass dies in Ordnung ist, und einen Mechanismus haben, um diesen Cache zu unterbrechen, wenn Sie dies benötigen (z. B. durch Ändern von Dateinamen). Sie cachen HTML sehr selten auf diese Weise, da es sich am meisten ändert und das Cache-Busting von HTML-Dateinamen komplizierter zu sein scheint, als es sich lohnt.
- Dateien können auf CDN-Ebene gecacht werden. Dies ist großartig, denn obwohl Netzwerkverkehr stattfindet, sind CDN-Server sehr schnell und wahrscheinlich geografisch näher an den Benutzern als Ihr Ursprungsserver. Wenn Benutzer Dateien von hier beziehen, belästigen sie Ihren Ursprungsserver nie. Sie benötigen auch eine Möglichkeit, diesen Cache zu unterbrechen, was wahrscheinlich durch Ändern von Dateinamen geschieht. Sie *können* HTML auf dieser Ebene auch ohne Ändern von Dateinamen cachen, wenn Sie einen Mechanismus haben, um diesen Cache global zu leeren, wenn sich Inhalte ändern.
- Der Ursprungsserver kann erstellte HTML-Seiten cachen. Auf einer WordPress-Website werden die Seiten mit PHP erstellt, was wahrscheinlich MySQL-Abfragen auslöst. Wenn der Server das Ergebnis der bereits ausgeführten Dinge speichern kann, bedeutet dies, dass er eine "statische" Datei als Antwort liefern kann, was er viel schneller tun kann, als PHP und MySQL ausführen zu müssen. Das funktioniert für ausgeloggte Benutzer, die alle die gleiche Antwort erhalten, aber nicht für eingeloggte Benutzer, die dynamische Inhalte auf der Seite haben (wie die WordPress-Adminleiste).
- Die Datenbank hat ihr eigenes spezielles Caching. Nachdem eine MySQL-Abfrage ausgeführt wurde, können die Ergebnisse in einem Objekt-Cache gespeichert werden, was bedeutet, dass dieselbe Anfrage aus diesem Cache kommen kann, anstatt die Abfrage erneut ausführen zu müssen. Sie erhalten dies bis zu einem gewissen Grad automatisch, aber idealerweise wird es mit einem persistenten Speicher verbunden, den Sie nicht automatisch erhalten.
Puh. Mit Jamstack wird es etwas einfacher, da Ihre Seiten vorab erstellt und bereits auf dem CDN gehostet werden, und im Fall von Netlify müssen Sie sich nicht einmal um das Cache-Busting kümmern.
Aber so komplex das auch ist, ich mache mir keine allzu großen Sorgen darüber. Diese WordPress-Website verwendet Flywheel für das Hosting, das sich um das Caching auf Datenbank- und Serverebene kümmert, ich habe Cloudflare davor mit spezieller WordPress-Optimierung für das CDN-Caching und mein eigenes Dateinamen-Cache-Busting (ich wünschte, dieser Teil wäre einfacher). Ich würde SpinupWP sicherlich vertrauen, es auch richtig zu machen, angesichts Ashleys großartigem Artikel, auf den ich hier verlinke.