Hosting & Performance
Wie wir WordPress schnell machen: LiteSpeed Enterprise, LSCache und Redis pro Website
Die schnellste WordPress-Anfrage ist die, die niemals ausgeführt wird – hier erfahren Sie, wie unser Stack die meisten Besuche aus dem Cache beantwortet, noch bevor PHP oder MySQL jemals aufgerufen werden, und was das für die Core Web Vitals bedeutet.
Die schnellste Anfrage ist die, die niemals ausgeführt wird
Eine standardmäßige WordPress-Anfrage ist rechenintensiv. Der Webserver übergibt die Anfrage an PHP, PHP startet WordPress, führt die Plugins aus, fragt MySQL Dutzende Male ab, stellt HTML zusammen und sendet erst dann Datenbytes zurück. Auf einer stark frequentierten Website findet dieser gesamte Ablauf für jeden Besucher statt, und genau hier geht fast Ihre gesamte Zeit bis zum ersten Byte verloren.
Unsere Antwort besteht darin, sicherzustellen, dass bei den meisten Besuchen davon überhaupt nichts stattfindet. Auf den von uns gehosteten Websites – über 100.000 PBN-Sites sowie herkömmliches Managed WordPress – wird die große Mehrheit der Front-End-Seitenansichten als vorgerenderte vollständige Seite direkt aus dem Cache ausgeliefert, 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.
Das Wichtige dabei ist, dass dies keine konkurrierenden Caches sind, zwischen denen Sie wählen müssen. Full-Page-Cache, Objekt-Cache und die CDN-Edge fangen jeweils eine andere Art von Anfrage ab, und der eigentliche Nutzen liegt darin, wie sie nahtlos ineinandergreifen.
LiteSpeed Enterprise + LSCache: die Full-Page-Schicht
Jede Website läuft auf LiteSpeed Enterprise mit LSCache auf Serverebene. Wenn eine Front-End-Antwort cache-fähig ist, versieht der Webserver sie mit LiteSpeed Cache-Control- und Tag-Headern, und LiteSpeed liefert die komplette Seite beim nächsten Zugriff direkt aus – es wird kein PHP-Prozess gestartet und keine MySQL-Abfrage ausgeführt. Das ist der mit Abstand größte Hebel für die WordPress-TTFB, da dadurch der gesamte Anwendungsstart aus dem kritischen Pfad entfernt wird.
Weil LSCache direkt im Webserver statt in einem PHP-Plugin läuft, greift es früher im Anforderungszyklus und hält Seiten in einer Form vor, die der Server sofort ausliefern kann. Ein Cache-Crawler hält beliebige Seiten im Speicher, sodass der erste Besucher nach einer Bereinigung nicht für die Generierung der Seite aufkommen muss. Das Resultat ist ein deutlich niedrigerer und gleichmässigerer TTFB als bei einem reinen Plugin-Cache, der auf einem herkömmlichen Stack aufsitzt, bei dem der Cache sich nach wie vor hinter PHP befindet.
Unser eigenes repo-taugliches Cache-Plugin wird auf jeder Website vorinstalliert und automatisch aktualisiert ausgeliefert, sodass WordPress von Haus aus korrekt mit LSCache verbunden ist. Auf einem Nicht-LiteSpeed-Ursprung gibt es einfach keine Full-Page-Header aus und hält sich im Hintergrund, während der Objekt-Cache und die Ausschlussregeln weiterhin ihre Arbeit tun – so gerät eine migrierte Site niemals in einen defekten, halbkonfigurierten Zustand.
Schnell bleiben ohne veraltete Inhalte: ESI und intelligentes Auto-Purge
Aggressives Full-Page-Caching hat zwei klassische Fehlerquellen: einem angemeldeten Benutzer die Seite eines anderen anzuzeigen und jemandem eine Seite zu präsentieren, die sich hätte ändern müssen. Beide werden auf der Caching-Ebene gelöst, anstatt weniger zu cachen.
ESI (Edge Side Includes) ermöglicht uns das Caching der Seite, während gleichzeitig Aussparungen für die Teile vorgenommen werden, die dynamisch bleiben müssen. In einem WooCommerce-Store werden Katalog-, Produkt- und Kategorieseiten als Full-Page-Cache für ein schnellstmögliches TTFB ausgeliefert, während ESI das Warenkorb-Fragment, die Mini-Warenkorb-Summen und den Kontostatus pro Anfrage rendert. Warenkorb, Kasse, „Mein Konto“ sowie alle Nonce- oder Session-Seiten sind standardmäßig ausgeschlossen. Käufer sehen immer ihren eigenen Warenkorb und eine funktionierende Kasse; alle anderen erhalten dennoch die Storefront aus dem Cache.
Die Aktualität wird durch eine intelligente Auto-Purge-Funktion gewährleistet. Purge-Hooks werden automatisch ausgelöst, wenn sich Inhalte, Produkte, Preise oder Bestellungen ändern, sodass die relevanten Caching-Seiten sofort und nicht erst nach Ablauf eines Zeitgebers aktualisiert werden. Sie können den Cache zudem jederzeit bei Bedarf über das Dashboard oder direkt in WordPress leeren. Das tagbasierte Bereinigen sorgt dafür, dass beim Bearbeiten eines Beitrags nur dieser Beitrag und dessen Archive gelöscht werden – nicht der gesamte Cache –, sodass eine einzelne Änderung nicht die gesamte Website verlangsamt.
Per-Site-Redis-Objektcache: Für alles, was keine vollständige Seite sein kann
Nicht jede Anfrage kann eine statische Vollseite sein. Eingeloggte Sitzungen, das WordPress-Admin, WooCommerce-Warenkörbe, die Suche und die dynamischen Fragmente, die ESI hinterlässt, müssen alle PHP ausführen. Bei diesen verschiebt sich das Ziel von „die Anwendung überspringen“ zu „die Datenbank überspringen“.
Jede Website erhält ihren eigenen dedizierten Redis-Objektcache. WordPress zwischenspeichert die Ergebnisse wiederholter Datenbankabfragen – Optionen, Transients, Beitrags- und Taxonomiesuchen, WooCommerce-Produkt- und Sitzungsdaten – im Arbeitsspeicher, sodass dieselbe Abfrage nicht bei jedem Aufruf erneut gegen MySQL ausgeführt wird. Der Effekt ist genau dort am deutlichsten, wo Vollseitencaching nicht helfen kann: schnellere Dashboards, schnellere Warenkörbe und eine deutlich geringere Datenbanklast bei hohem Traffic.
Der Objektspeicher ist pro Site eingerichtet und wird nicht geteilt, was sowohl für die Leistung als auch für die Isolierung von Bedeutung ist. In Kombination mit der pro Site geltenden Datenbank-Drosselung können rechenintensive oder schlecht geschriebene Abfragen einer Site nicht dazu führen, dass die Datenbank für benachbarte Sites hungrig bleibt. Sie können auf unserer Caching-Funktionsseite mehr darüber nachlesen, wie das gesamte mehrschichtige Setup zusammenwirkt, und unter Isolierung mehr über die Grenzen zwischen den Mandanten erfahren.
Das Edge-Netzwerk und der zugrunde liegende Transport
Im Ursprung gespeicherter Cache muss dennoch das Netzwerk überqueren. Vor dem Server befindet sich die CDN-Edge, sodass statische Assets und cachebare Seiten von einem Point of Presence in der Nähe des Besuchers ausgeliefert werden und der Ursprungsserver selbst unter Last ruhig bleibt. Für unsere Footprint-Free-Hosting-Linie ist dieselbe Edge ein Multi-CDN-Pool, der sich über mehrere Anbieter erstreckt und sowohl ein Footprint-Ziel als auch ein Performance-Ziel erfüllt; bei mainstream WordPress ist sie einfach eine schnelle, gut funktionierende Schicht, die Ursprungsserver im Leerlauf hält.
Darunter wird bei den Grundlagen nicht gespart. Websites laufen auf NVMe-Speicher mit HTTP/3, sodass die Bytes, die der Cache sendet, über einen modernen, multiplexed Transport ankommen, wobei bei jedem Cache-Miss schneller Speicher dahintersteht. Keine dieser Ebenen ist ein Add-on: LiteSpeed, LSCache, per-site Redis, NVMe und HTTP/3 bilden bei jedem Tarif die Basis, keine kostenpflichtige Upgrade-Stufe.
Was Core Web Vitals tatsächlich beeinflusst
Es lohnt sich, hier präzise zu sein, denn beim Hosting wird oft zu viel versprochen, was Core Web Vitals angeht. TTFB ist der Teil der Gleichung, für den der Server verantwortlich ist, und der darüber liegende Caching-Stack sorgt für die Optimierung – eine gecachte, über HTTP/3 vom Edge ausgelieferte vollständige Seite erreicht einen Wert, der nahe am absoluten Minimum für TTFB liegt. Da TTFB die entscheidende Grundlage für Largest Contentful Paint ist, verschafft ein schneller Ursprung jedem nachfolgenden Messwert einen Vorsprung, den er sonst nicht erhalten könnte.
Aber LCP, CLS und INP werden größtenteils im Browser von der Seite selbst entschieden: ein nicht optimiertes Hero-Image, render-blockierende CSS- und JavaScript-Dateien, Layouts, die sich beim Laden von Fonts und Anzeigen verschieben, sowie schwere Main-Thread-Arbeit durch Plugins. Kein Serverseiten-Caching der Welt behebt ein 2-MB-Hero-Image oder ein Theme, das megabyteiweise JavaScript ausliefert. Ehrliches Hosting sorgt dafür, dass der serverseitige Beitrag praktisch kostenlos und konstant bleibt, und 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 bei hohem Datenverkehr schnell bleibt; Sie halten die Nutzdaten klein und stabil. Genau dort, wo beides aufeinandertrifft – Cache-Warm-up, Edge-Delivery und die Aufrechterhaltung einer reaktionsfähigen Datenbank, damit dynamische Seiten nicht ins Stocken geraten –, ist unser Stack optimiert, und das macht verwaltetes WordPress auf dieser Plattform schneller als dieselbe Website bei einem herkömmlichen Host.
Häufig gestellte Fragen
Brauche ich trotzdem ein Caching-Plugin wie WP Rocket?
Nein. Die Full-Page-Caching-Funktion wird auf Webserver-Ebene durch LSCache von LiteSpeed verarbeitet, und unser eigenes Cache-Plugin – das vorinstalliert und automatisch aktualisiert wird – verbindet WordPress korrekt damit, während im Hintergrund ein pro Site eingerichteter Redis-Objektcache läuft. Das Hinzufügen eines zweiten Full-Page-Caching-Plugins beeinträchtigt den Cache auf Server-Ebene meistens eher, anstatt zu helfen, weshalb es weder erforderlich noch empfehlenswert ist.
Beschleunigt Caching Probleme mit meinem WooCommerce-Warenkorb oder eingeloggten Seiten?
Nein. Warenkorb, Kasse, mein-konto sowie sämtliche Nonce- oder Session-Seiten sind standardmäßig vom Cache ausgeschlossen. ESI sorgt dafür, dass der Warenkorb-Fragment und die Gesamtsummen auf ansonsten gecachten Seiten aktuell bleiben. Shopper sehen immer ihren eigenen Warenkorb und eine funktionierende Kasse, während der Shop-Bereich weiterhin aus dem Cache lädt.
Wie bleibt der Cache beim Veröffentlichen oder Bearbeiten aktuell?
Smart Auto-Purge wird über die relevanten WordPress-Hooks ausgelöst. Das Veröffentlichen oder Bearbeiten von Inhalten sowie das Ändern eines Produkts, Preises oder einer Bestellung leert daher nur die betroffenen Seiten und deren Archive – nicht den gesamten Cache –, und ein Crawler wärmt sie erneut auf. Sie können den Cache auch jederzeit bedarfsgesteuert über das Dashboard oder direkt aus WordPress heraus bereinigen.
Kann reines Hosting mir perfekte Core Web Vitals liefern?
Er bietet Ihnen die bestmögliche TTFB, die den serverseitigen Anteil und einen Vorsprung für den Largest Contentful Paint ausmacht. Aber LCP, CLS und INP werden größtenteils von der Seite selbst bestimmt – Bildgrößen, render-blockierende Ressourcen, Layout-Stabilität und JavaScript im Main-Thread. Unser Stack macht den Server-Beitrag schnell und konsistent; ein schlankes Front-End-Payload schließt den Rest der Lücke.
Verwandt
14 Tage kostenlos testen
Erstelle deine ersten Websites 14 Tage lang kostenlos — ganz ohne Kreditkarte. Du ziehst mit einem bestehenden Netzwerk um? Die erste Migration geht auf uns.
Kostenlos starten