Server-Page-Cache: Wenn Ihre Website 1000× schneller antwortet

Eine Website, die in 2 Sekunden lädt, fühlt sich brauchbar an. Eine, die in 200 Millisekunden lädt, fühlt sich erstklassig an. Und eine, die in 2 Millisekunden antwortet, fühlt sich so an, als wäre der Inhalt schon da, bevor der Klick beim Server angekommen ist. Genau dieser Sprung passiert, wenn Sie Ihre Website mit einem Server-Page-Cache betreiben.

Dieser Artikel erklärt, was hinter dem Konzept steckt, warum es WordPress-Caching-Plugins um Grössenordnungen schlägt und wann ein Server-Page-Cache der richtige Hebel für Ihre Seite ist.

Was ein Server-Page-Cache eigentlich ist

Wenn ein Besucher Ihre WordPress-Seite aufruft, läuft im Hintergrund eine kleine Maschine an. PHP startet, fragt die Datenbank ab, lädt das Theme, prüft Plugins, baut das HTML zusammen und schickt es zurück. Auf einer typischen Shared-Hosting-Umgebung dauert das zwischen 200 und 800 Millisekunden, manchmal länger.

Ein Page-Cache speichert das fertige HTML nach dem ersten Aufruf zwischen. Beim nächsten Besucher wird die gespeicherte Version direkt ausgeliefert. PHP wird nicht mehr angeworfen, die Datenbank bleibt unangetastet, das Theme wird nicht neu zusammengebaut.

Der Unterschied zu einem WordPress-Caching-Plugin ist die Ebene. Ein Plugin wie WP Super Cache oder W3 Total Cache fängt den Aufruf erst ein, nachdem WordPress bereits gestartet ist. PHP läuft kurz an, das Plugin sagt “diese Seite hab ich schon”, liefert sie aus PHP heraus zurück und beendet sich. Schnell, aber PHP wird trotzdem hochgefahren.

Ein Server-Page-Cache lebt eine Ebene höher, direkt im Webserver (nginx). Der Webserver entscheidet selbst, ob er ausliefert oder PHP überhaupt aufruft. Ergebnis: PHP startet bei Cache-Treffern gar nicht mehr.

Warum der Unterschied so gross ist

Wir haben unter Last gemessen. 200 gleichzeitige Besucher hämmern zwei Minuten lang auf eine WordPress-Frontpage in einem Basic-Container mit 1 vCPU und 512 MB RAM.

Die langsamsten 5 Prozent der Antworten sind im gecachten Fall etwa 1000-mal schneller als ohne Cache. Aus 2,3 Sekunden werden 2 Millisekunden. Für den Besucher heisst das: die Seite ist sofort da, kein wahrnehmbares Laden.

Wichtig dabei: kein Fehler, kein Timeout, keine zusätzliche Hardware. Dieselbe Maschine, dieselben Ressourcen, einfach eine zusätzliche Schicht zwischen Webserver und PHP.

Wann sich der Server-Page-Cache lohnt

Wenn Ihre Seite vor allem Inhalte zeigt

Eine Firmenwebsite, ein Blog, eine Dienstleistungsseite, ein einfacher Onlineshop ohne Login-Bereich für Besucher: das sind die idealen Kandidaten. Die Inhalte ändern sich nicht ständig, dieselbe Seite wird oft wieder aufgerufen, jeder Besucher sieht im Wesentlichen dasselbe.

Wenn Sie unter Last stabil bleiben wollen

Werbekampagnen, Pressemitteilungen, virale Beiträge: alles, was kurzfristig viel Traffic bringt, ist ohne Cache eine Belastungsprobe für PHP und Datenbank. Mit Cache liefert nginx aus dem Speicher, die Last bleibt flach.

Wenn Sie an Ihren Core Web Vitals arbeiten

Google bewertet die Antwortzeit Ihres Servers (TTFB, Time to First Byte) als Teil der Core Web Vitals. Ein Server-Cache senkt TTFB drastisch und wirkt sich positiv auf das Ranking aus. Mehr dazu in unserem Artikel Core Web Vitals erklärt.

Wenn Sie auf einem kleinen Plan unterwegs sind

Mit aktivem Cache verarbeitet ein 1-vCPU-Container ein Vielfaches an Traffic, weil PHP für die meisten Aufrufe gar nicht startet. Sie müssen nicht zwingend auf einen grösseren Plan upgraden, sobald die Besucherzahlen wachsen.

Wann er weniger sinnvoll ist

Der Server-Page-Cache ist ein scharfes Werkzeug. In manchen Situationen passt er nicht ohne Weiteres.

Wenn Sie häufig Inhalte aktualisieren

Bei HostBott läuft der Cache mit einer Lebensdauer von einer Minute. Eine Änderung im WordPress-Editor wird also bis zu 60 Sekunden später für Besucher sichtbar. Für die meisten Seiten ist das problemlos. Wenn Sie aber eine Newsroom-Seite betreiben, auf der Aktualisierungen sofort erscheinen sollen, kann das stören. Eine “Cache leeren”-Funktion ist auf der HostBott-Roadmap und beseitigt diese Einschränkung.

Wenn Ihre Seite stark personalisiert ist

Onlineshops mit Warenkorb, Mitgliederbereiche, Foren mit Login: dort sehen unterschiedliche Besucher unterschiedliche Inhalte. Der HostBott-Cache erkennt typische WordPress-Login-Cookies, WooCommerce-Sessions und den /wp-admin-Bereich und umgeht den Cache automatisch. Bei sehr individuellen Custom-Frameworks oder selbstgebauten Cookies kann es vorkommen, dass der Cache nicht richtig differenziert. In dem Fall hilft eine Beratung, ob der Cache für Ihre Architektur passt.

Wenn Ihre Seite kaum Traffic hat

Bei weniger als einem Aufruf pro Minute läuft jeder Cache-Eintrag ab, bevor er ein zweites Mal genutzt wird. Der Effekt ist minimal. Bei dieser Grössenordnung lohnt sich der Cache nicht, schadet aber auch nicht.

Wenn Sie POST-basierte Funktionen testen

Formulare, Login-Versuche, API-Calls per POST werden vom Cache automatisch übergangen. Auch Aufrufe mit Query-Strings (alles mit ? in der URL) gehen direkt durch zu PHP. Damit funktionieren Suchen, Filter und Formulare ohne Probleme.

So aktivieren Sie den Cache bei HostBott

Im Panel finden Sie auf der Übersichtsseite Ihrer Website einen Schalter “Page-Cache” in der Konfigurations-Karte. Ein Klick aktiviert den Cache. Der Container wird automatisch neu gestartet, was rund 5 bis 10 Sekunden dauert. Nach dem Neustart ist der Cache aktiv.

Sie können den Cache jederzeit wieder deaktivieren. Dasselbe Klick, derselbe Neustart, der Cache ist weg. Sie verlieren dabei keine Daten, weder im WordPress noch in der Datenbank.

Was im Hintergrund passiert: nginx legt einen kleinen Bereich im Container-Speicher an, in dem die gecachten Seiten liegen. Bei jedem Aufruf prüft nginx, ob die angefragte Seite cachefähig ist. Wenn ja und die Seite ist im Cache, wird sie direkt ausgeliefert. Wenn nein, geht der Aufruf an PHP, die Antwort wird gespeichert, ab dem zweiten Aufruf greift der Cache.

Der Cache-Speicher ist auf 32 MB begrenzt und liegt nur im Arbeitsspeicher (nicht auf der Festplatte). Bei einem Container-Neustart ist er leer, baut sich aber innerhalb der ersten Minuten wieder auf.

Plugin-Cache zusätzlich oder stattdessen?

Eine berechtigte Frage. Beides gleichzeitig laufen zu lassen, ist normalerweise nicht nötig und kann zu Verwirrung führen, wenn beide Seiten unabhängig invalidieren. Unsere Empfehlung:

• Server-Page-Cache aktiviert: bringt den grössten Effekt für anonyme Besucher (TTFB im einstelligen Millisekundenbereich).
• WordPress-Caching-Plugins für Object-Cache und Fragment-Cache, wenn nötig: ergänzen den Server-Cache für eingeloggte Benutzer und für Bereiche, die der Server-Cache umgeht.
• Browser-Caching über Cache-Control-Header: greift auf einer dritten Ebene und reduziert Aufrufe komplett.

Mehr dazu in unserem Artikel WordPress Caching erklärt, der die verschiedenen Caching-Ebenen detailliert beschreibt.

Fazit

Ein Server-Page-Cache ist die effektivste Einzelmassnahme, um eine WordPress-Website schneller zu machen. Bei HostBott aktivieren Sie ihn mit einem Klick, der Effekt ist messbar und gross: Antwortzeiten fallen um Faktor 100 bis 1000, die Belastung des Containers sinkt drastisch, Core Web Vitals verbessern sich.

Für die meisten Firmenwebsites, Blogs und Inhaltsseiten ist die Frage nicht, ob er sich lohnt, sondern warum er nicht schon längst aktiv ist. Bei stark personalisierten Seiten oder hochfrequent aktualisierten Inhalten lohnt sich ein zweiter Blick auf die Konfiguration, idealerweise im Gespräch mit unserem Team.

Aktivieren, beobachten, im Zweifel deaktivieren: das Risiko ist null, der mögliche Gewinn enorm.