In diesem Video erklärt Jan Thiel, was Caching eigentlich bedeutet und wie Eure Webseiten durch die intelligente Caching-Lösung von WLWP richtig schnell werden.
Bei WLWP bieten wir Euch eine voll konfigurierte Webseite auf WordPress Basis, mit handverlesenen Plugins und Themes, die garantiert im Einklang miteinander funktionieren. Zusätzlich kümmern wie uns um alle anstehenden Updates, fertigen regelmässige Backups Eurer Daten an und stehen jederzeit mit Rat und Tat zur Verfügung.
Jan Thiel erklärt, warum von WLWP beherbergte Seiten dank einem Zusammenspiel spezieller Caching-Lösungen besonders schnell sind (und was du machen kannst um diese Lösung für dich zu nutzen).
Um es kurz zu machen: Vermeide – wo immer möglich – PHP auszuführen und sorge dafür, dass möglichst viel auf der Server-Ebene „geregelt“ wird. Das gilt auch / vor allem für das Caching.
In diesem Video erklärt Jan Thiel, welche Caching-Philosophie bei WLWP zur Anwendung kommt, damit unseren Kunden der schnellstmögliche Zugriff auf ihre WordPress-Seiten ermöglicht wird.
Gleich vorweg: es gibt nicht DAS beste Caching. Es gibt diverse Stellen, an denen man cachen kann, sowie diverse Möglichkeiten, mit denen man cachen kann. „Varnish“ ist zum Beispiel dafür gedacht, vor einen Webserver geschaltet zu sein und dort Web-Inhalte zu cachen, also Webseiten oder auch nur Teile von Webseiten.
Memcache oder Redis zum Beispiel sind nichts anderes als Mini-Datenbanken, die nur im schnellen RAM des Computers laufen, im Arbeitsspeicher. Dort kann man dann Sachen auslagern, die man sonst zum Beispiel in der MySQL-Datenbank hätte. Die MySQL-Datenbank ist zwar auch nicht langsam, aber ein Redis oder Memcache im Arbeitsseicher ist um ein Hundertfaches schneller.
Daten, die also dort in diesem Memcache oder Redis liegen, ersparen uns einen Datenbankzugriff und machen die ganze Seite schneller. Zugriffe, die im „Varnish“ landen, ersparen uns, dass überhaupt der Webserver oder WordPress angesprochen werden. Der Kunde merkt nichts davon, für den Kunden gibt es keinen Unterschied, der Aufruf bei WordPress wird jedoch nie dort ankommen.
Für den Kunden heißt das lediglich, dass die Seite nach dem Aufruf blitzschnell geladen wird. Nun gibt es weitere Caching-Mechanismen, wie Database-Caching oder Object-Caching, je nachdem, welchen Bereich dieser langen Kette (Kunde, Browser, Webserver, PHP, WordPress, MySQL-Datenbank) man cachen will.
Auch hierbei gibt es nicht die «Beste Lösung», sondern viele verschiedene.
Man kann sagen, dass der meiste Gewinn an Geschwindigkeit durch das Caching beim Kunden – nämlich ganz vorne – erreicht werden. Das kennt man, dass dort im Browser-Cache – so nennt sich das – CSS und JavaScript-Dateien liegen. Und zum Teil auch Webseiten. Das ist unglaublich schnell, weil der Browser vom Kunden sofort weiß: «Ich muss jetzt nicht diese lange Kette durchgehen, um von hier hinten wieder meine Daten zu bekommen, sondern ich habe die bereits und die haben sich nicht geändert.»
Daten, die ich beim Kunden nicht cachen kann, können vielleicht vorne im Varnish-Cache gelagert werden, da muss der Kunde nur mit dem Varnish kommunizieren und bekommt seine Webseite oder die Dateien zurück. Hinten bleibt die Kette PHP, WordPress, MySQL dabei unangetastet. Das Spiel lässt sich jetzt so fortführen. Gehe ich die Kette durch, komme ich beim Webserver an und bei PHP. Jetzt kann ich im PHP wiederum ein Opcode-Caching aktivieren. Das ist auf ganz tiefer Ebene ein Mechanismus, der Programmcode cached, sprich, der muss nicht immer wieder erzeugt, wieder durchlaufen werden, sondern der wird einfach ausgeführt.
Das heißt in dem Fall: PHP muss nicht das ganze WordPress neu durchlaufen, sondern ruft die gewünschten Daten einfach aus dem Cache ab und spart dadurch viel Zeit. Ich glaube, diese Kette ist relativ verständlich. Dort, wo ich cachen kann, sollte ich es tun und im Endeffekt erspart mir das imer einen weiteren Zugriff nach hinten durch. Disclaimer am Rande: Man kann nicht alles cachen. Es gibt durchaus Szenarien, in denen man nicht cachen will. Der Administrator zum Beispiel will nicht auf einer sich im Cache befindlichen Seite arbeiten, denn er muss ja das sehen, was wirklich da ist. Daher stellen sich die Fragen: «Wieviel kann ich cachen?» Und: «Womit kann ich cachen?»
Eine BuddyPress-Installation – große Community – kann man nicht mit einem Varnish-Cache zwischenspeichern, weil de facto jede Seite sehr dynamisch ist und ständig neu erzeugt werden muss. Man kann sehr wohl aber mit einem Opcode-Caching im PHP arbeiten oder Datenbankzugriffe cachen. Daher: es gibt nicht die beste Lösung, es gibt nicht das eine Produkt. Man sollte cachen, wo man kann. Man muss aber auch wissen, wo es sich besonders anbietet und wo nicht. Wenn man nämlich zu viel cached, kann das Ganze auch nach hinten losgehen. Dementsprechend: Caching ja, aber mit Bedacht.
Jan Thiel erklärt in diesem Video warum „Managed WordPress Hosting“ nicht gleich „Managed WordPress Hosting“ ist, wie man den Unterschied zwischen den verschiedenen Anbietern von Managed WordPress Hosting erkennt und worauf man achten sollte, wenn man sein WordPress Blog oder Webseite bei einem guten Anbieter unterbringen will.
Weiterlesen