Hosting & Leistung
Wie wir WordPress schnell machen: LiteSpeed Enterprise, LSCache und Redis pro Website
Die schnellste WordPress-Anfrage ist diejenige, die nie ausgeführt wird — hier erfahren Sie, wie unser Stack die meisten Besuche aus dem Cache beantwortet, noch bevor PHP oder MySQL überhaupt aufgerufen werden, und was das für Core Web Vitals bedeutet.
Die schnellste Anfrage ist diejenige, die niemals ausgeführt wird
Eine standardmäßige WordPress-Anfrage ist aufwendig. Der Webserver übergibt an PHP, PHP startet WordPress, führt die Plugins aus, fragt MySQL einige Dutzend Male ab, baut das HTML zusammen und sendet erst dann Bytes zurück. Auf einer stark frequentierten Website findet dieser gesamte Ablauf für jeden einzelnen Besucher statt, und genau hier geht fast Ihre gesamte Time-to-First-Byte verloren.
Unsere Antwort besteht darin, sicherzustellen, dass bei den meisten Besuchen nichts davon überhaupt geschieht. Über die von uns gehosteten Websites hinweg – mehr als 100.000 PBN-Websites sowie reguläres verwaltetes WordPress – wird die überwiegende Mehrheit der Frontend-Seitenaufrufe als vorgerenderte vollständige Seite direkt aus dem Cache bereitgestellt, ohne PHP aufzurufen oder die Datenbank zu berühren. Der Rest dieses Beitrags befasst sich damit, wie die Schichten, die dies ermöglichen, ineinandergreifen und wo jede einzelne ihren Platz verdient.
Der entscheidende Ansatz ist, dass dies keine konkurrierenden Caches sind, zwischen denen Sie wählen müssen. Full-Page-Cache, Object-Cache und der CDN-Edge erfassen jeweils eine andere Art von Anfragen, und der eigentliche Mehrwert liegt darin, wie sie ineinandergreifen.
LiteSpeed Enterprise + LSCache: die Ganzseiten-Ebene
Jede Website läuft auf LiteSpeed Enterprise mit LSCache auf Serverebene. Wenn eine Frontend-Antwort zwischenspeicherbar ist, versieht der Webserver sie mit LiteSpeed cache-control- und Tag-Headern, und LiteSpeed liefert die vollständige Seite beim nächsten Aufruf direkt aus — es wird kein PHP-Prozess erzeugt und keine MySQL-Abfrage abgesetzt. Das ist der mit Abstand größte Hebel für die WordPress-TTFB, da der gesamte Anwendungsstart aus dem kritischen Pfad entfernt wird.
Da LSCache direkt im Webserver und nicht in einem PHP-Plugin arbeitet, greift es früher im Anfragezyklus ein und speichert Seiten in einem Format, das der Server sofort leeren kann. Ein Cache-Crawler hält beliebte Seiten warm, sodass der erste Besucher nach einer Bereinigung nicht für die Neugenerierung der Seite aufkommen muss. Das Ergebnis ist eine deutlich niedrigere und konsistentere TTFB als bei einem reinen Plugin-Cache, der auf einem herkömmlichen Stack aufgesetzt ist, bei dem sich der Cache weiterhin hinter PHP befindet.
Unser eigenes Cache-Plugin auf Repository-Niveau wird auf jeder Website vorinstalliert und automatisch aktualisiert ausgeliefert, wodurch WordPress von vornherein korrekt mit LSCache verknüpft wird. Auf einem Origin-Server, der nicht LiteSpeed ist, gibt es einfach keine Full-Page-Header aus und hält sich im Hintergrund, während der Objekt-Cache und die Ausschlussregeln weiterhin ihre Aufgabe erfüllen — so wird eine migrierte Website niemals in einem fehlerhaften, halb konfigurierten Zustand hinterlassen.
Schnell bleiben, ohne veraltete Inhalte auszuliefern: ESI und intelligente automatische Bereinigung
Aggressives Page-Caching hat zwei klassische Fehlermodi: einem angemeldeten Benutzer die Seite eines anderen bereitzustellen und jedem Benutzer eine Seite bereitzustellen, die sich eigentlich hätte ändern müssen. Beide Probleme werden auf der Caching-Ebene gelöst und nicht durch weniger Caching.
Mit ESI (Edge Side Includes) können wir die Seite zwischenspeichern und gleichzeitig Lücken für die Teile freihalten, die dynamisch bleiben müssen. In einem WooCommerce-Shop werden Katalog-, Produkt- und Kategorieseiten für die schnellstmögliche TTFB als vollständiger Seitencache bereitgestellt, während ESI das Warenkorb-Fragment, die Gesamtsummen des Mini-Warenkorbs und den Kontostatus pro Anfrage rendert. Warenkorb, Kasse, Mein Konto sowie alle Nonce- oder Sitzungsseiten sind standardmäßig ausgeschlossen. Käufer sehen stets ihren eigenen Warenkorb sowie einen funktionierenden Checkout; die Shop-Oberfläche wird weiterhin für alle aus dem Cache geladen.
Die Aktualität wird durch intelligentes automatisches Bereinigen sichergestellt. Bereinigungs-Hooks werden automatisch ausgelöst, wenn sich Inhalte, Produkte, Preise oder Bestellungen ändern, sodass die relevanten zwischengespeicherten Seiten sofort und nicht nach einem Timer aktualisiert werden; zudem können Sie die Bereinigung bei Bedarf über das Dashboard oder direkt aus WordPress heraus vornehmen. Tag-basierte Bereinigung bedeutet, dass die Bearbeitung eines Beitrags nur diesen Beitrag und seine Archive leert – nicht den gesamten Cache –, sodass eine einzelne Änderung nicht zu einem Kaltstart der gesamten Website führt.
Site-spezifischer Redis-Objekt-Cache: für das, was keine vollständige Seite sein kann
Nicht jede Anfrage kann eine statische vollständige Seite sein. Angemeldete Sitzungen, der WordPress-Adminbereich, WooCommerce-Warenkörbe, die Suche und die dynamischen Fragmente, die ESI live belässt, müssen alle PHP ausführen. Bei diesen verlagert sich das Ziel von „die Anwendung überspringen“ zu „die Datenbank überspringen“.
Jede Website erhält ihren eigenen dedizierten Redis-Objekt-Cache. WordPress speichert die Ergebnisse wiederholter Datenbankabfragen – Optionen, Transients, Beitrags- und Begriffssuchen sowie WooCommerce-Produkt- und Sitzungsdaten – im Arbeitsspeicher, sodass dieselbe Abfrage nicht bei jedem Aufruf an MySQL gerichtet werden muss. Der Effekt zeigt sich genau dort am deutlichsten, wo der Ganzseiten-Cache nicht helfen kann: schnellere Dashboards, schnellere Warenkörbe und eine deutlich geringere Datenbanklast bei hohem Datenverkehr.
Der Objekt-Cache ist pro Website eingerichtet und wird nicht geteilt, was sowohl für die Leistung als auch für die Isolation von Bedeutung ist. In Kombination mit der datenbankbezogenen Drosselung pro Website können schwerfällige oder schlecht geschriebene Abfragen einer Website die Datenbank für deren Nachbarn nicht überlasten. Weitere Informationen darüber, wie das gesamte mehrschichtige System ineinandergreift, finden Sie auf unserer Caching-Funktionsseite, und mehr über die Grenzen zwischen den Mandanten erfahren Sie im Abschnitt zur Isolation.
Der Edge und der darunterliegende Transport
Cache, der sich auf dem Ursprungsserver befindet, muss dennoch das Netzwerk durchqueren. Vor dem Server befindet sich die CDN-Edge, sodass statische Inhalte und zwischenspeicherbare Seiten von einem Präsenzpunkt in der Nähe des Besuchers ausgeliefert werden und der Ursprungsserver selbst unter Last entlastet bleibt. Für unsere footprint-freie Hosting-Reihe ist dieselbe Edge ein Multi-CDN-Pool, der über mehrere Anbieter verteilt ist, was sowohl einem Footprint-Ziel als auch der Leistung dient; bei herkömmlichem WordPress ist sie schlicht eine schnelle, zuverlässige Schicht, die Ursprungsserver im Leerlauf hält.
Im Hintergrund wird an den Grundlagen nicht gespart. Websites laufen auf NVMe-Speicher mit HTTP/3, sodass die vom Cache gesendeten Bytes über einen modernen, gemultiplexten Transport ankommen, mit schnellem Speicher hinter jedem Cache-Miss. Keine dieser Ebenen ist ein kostenpflichtiges Zusatzmodul: LiteSpeed, LSCache, Redis pro Website, NVMe und HTTP/3 sind der Standard bei jedem Tarif, keine Upsell-Stufe.
Was Core Web Vitals wirklich verbessert
Es lohnt sich, präzise zu sein, da Hosting in Bezug auf Core Web Vitals oft übertrieben angepriesen wird. Die TTFB ist der Teil der Gleichung, den der Server verantwortet, und der obige Caching-Stack sorgt dafür, dass sie sinkt — eine vollständige, im Cache gespeicherte Seite, die über HTTP/3 vom Edge bereitgestellt wird, entspricht in etwa dem niedrigsten erreichbaren TTFB-Wert. Da die TTFB die Vorstufe des Largest Contentful Paint darstellt, verschafft ein schneller Ursprungsserver jeder nachgelagerten Metrik einen Vorsprung, den sie sonst nicht haben könnte.
Aber LCP, CLS und INP werden größtenteils im Browser von der Seite selbst entschieden: ein nicht optimiertes Hero-Bild, Render-blockierendes CSS und JavaScript, ein Layout, das sich beim Laden von Schriftarten und Anzeigen verschiebt, sowie eine starke Belastung des Hauptthreads durch Plugins. Kein noch so umfangreiches Server-Caching behebt ein 2 MB großes Hero-Bild oder ein Theme, das Megabytes an JavaScript ausliefert. Ehrliches Hosting sorgt dafür, dass der Serverbeitrag praktisch nicht ins Gewicht fällt und konsistent bleibt; danach liegt es an der Website, das Frontend schlank zu halten.
Diese Arbeitsteilung ist das nützliche mentale Modell. Wir garantieren, dass die Anfrage den Browser schnell erreicht und auch bei hohem Datenverkehr schnell bleibt; Sie halten die Nutzlast gering und stabil. Genau dort, wo beides zusammentrifft — Cache-Aufwärmung, Edge-Bereitstellung und die Sicherstellung einer reaktionsschnellen Datenbank, damit dynamische Seiten nicht ins Stocken geraten —, ist unser Stack optimiert. Das ist es, was verwaltetes WordPress auf dieser Plattform schneller macht als dieselbe Website bei einem herkömmlichen Host.
Häufig gestellte Fragen
Benötige ich noch ein Caching-Plugin wie WP Rocket?
Nein. Das Caching ganzer Seiten wird auf dem Webserver von LSCache von LiteSpeed übernommen, und unser eigenes Cache-Plugin – vorinstalliert und automatisch aktualisiert – bindet WordPress korrekt daran an, mit einem Redis-Objekt-Cache pro Website im Hintergrund. Die zusätzliche Nutzung eines zweiten Plugins für das Caching ganzer Seiten arbeitet in der Regel eher gegen den Cache auf Serverebene, als dass es nützt; es ist daher weder erforderlich noch empfehlenswert.
Wird das Caching meinen WooCommerce-Warenkorb oder Seiten für angemeldete Benutzer beschädigen?
Nein. Warenkorb, Kasse, my-account und alle Nonce- oder Sitzungsseiten sind standardmäßig vom Cache ausgeschlossen, und ESI hält das Warenkorb-Fragment sowie die Gesamtsummen auf ansonsten gecachten Seiten aktuell. Kunden sehen stets ihren eigenen Warenkorb und einen funktionierenden Checkout, während die Storefront weiterhin aus dem Cache geladen wird.
Wie bleibt der Cache aktuell, wenn ich Inhalte veröffentliche oder bearbeite?
Die intelligente automatische Bereinigung wird bei den relevanten WordPress-Hooks ausgelöst, sodass das Veröffentlichen, Bearbeiten von Inhalten oder Ändern eines Produkts, eines Preises oder einer Bestellung nur die betroffenen Seiten und deren Archive löscht – nicht den gesamten Cache – und ein Crawler diese wieder aufwärmt. Sie können die Bereinigung auch bei Bedarf über das Dashboard oder direkt in WordPress durchführen.
Kann Hosting allein mir perfekte Core Web Vitals liefern?
Es bietet Ihnen die bestmögliche TTFB, die den Anteil des Servers darstellt und einen Startvorteil für Largest Contentful Paint bietet. LCP, CLS und INP werden jedoch weitgehend von der Seite selbst bestimmt — Bildgrößen, Rendering-blockierende Ressourcen, Layout-Stabilität und JavaScript im Hauptthread. Unser Stack sorgt für einen schnellen und konsistenten Serverbeitrag; die schlanke Haltung der Frontend-Payload schließt die restliche Lücke.
Verwandt
14 Tage lang kostenlos testen
Starten Sie Ihre ersten Websites 14 Tage lang kostenlos — keine Kreditkarte erforderlich. Ziehen Sie ein bestehendes Netzwerk um? Migrationen sind unbegrenzt und kostenlos.
Kostenlos starten