Managed WordPress-Hosting dient dazu, WordPress optimal laufen zu lassen. Es bietet eine Umgebung, die genau darauf abgestimmt ist, wie sich WordPress unter Last verhält, wie es mit Caching umgeht und wie es PHP ausführt.
Block-Themes ändern zwar nichts an den Grundlagen des Hostings, aber sie verändern, wo Leistungsengpässe auftreten. Hier wird die Rolle des Webhosts deutlicher. Die Infrastruktur allein macht eine Website nicht schnell; eine schlecht abgestimmte Infrastruktur macht sich in modernen WordPress-Workflows bemerkbar, besonders wenn dynamische Blöcke, der Site Editor, Vorschauen und angemeldete Sitzungen im Spiel sind.
Um zu verstehen, warum das so ist, hilft es, sich anzuschauen, was bei einer Seitenanfrage tatsächlich passiert und wie sich Hosting-Entscheidungen auf die Benutzererfahrung auswirken, wenn eine blockbasierte Architektur verwendet wird.
Was passiert, wenn eine WordPress-Website angefordert wird
Schauen wir uns eine einfache Anfrage an, die eine 200 OK-Antwort zurückgibt.
1. Der Browser sendet die Anfrage
Ein Nutzer gibt eine URL ein oder klickt auf einen Link. Wenn die IP-Adresse des Servers noch nicht im Cache gespeichert ist, führt der Browser eine DNS-Abfrage durch. Anschließend öffnet er eine TCP-Verbindung und handelt eine sichere TLS-Sitzung aus.
Bevor WordPress ins Spiel kommt, durchläuft die Anfrage den Webserver und alle konfigurierten Ebenen wie Firewalls oder Reverse-Proxys.
2. Cache-Prüfung
Der Server prüft, ob eine gültige zwischengespeicherte Version der angeforderten Website vorhanden ist.
Wenn ein HTML-Cache der gesamten Seite verfügbar und gültig ist, wird WordPress nicht ausgeführt. Die zwischengespeicherte Antwort wird sofort zurückgegeben.
Wenn kein Cache-Eintrag vorhanden ist oder wenn das Caching für angemeldete Benutzer, Vorschauen oder bestimmte Endpunkte absichtlich umgangen wird, wird die Anfrage an WordPress weitergeleitet.
3. WordPress startet
WordPress lädt seine Kerndateien, die aktiven Plugins und das aktive Theme. Es initialisiert Hooks und bereitet sich darauf vor, die Anfrage zu bearbeiten.
In dieser Phase rendert WordPress noch keine Ausgabe. Es ermittelt, welche Inhalte angefordert werden.
4. Auflösung der Hauptabfrage
Mithilfe von Rewrite-Regeln und Abfragevariablen erstellt und führt WordPress die Hauptdatenbankabfrage aus. Es ermittelt, ob die Anfrage einen einzelnen Beitrag, eine Seite, ein Archiv, ein Suchergebnis oder einen anderen Inhaltstyp betrifft.
Erst danach beginnt die Template-Auswahl.
5. Template-Auflösung
Hier beginnen sich Block- und klassische Themes strukturell zu unterscheiden.
Klassische Themes
WordPress wertet die Template-Hierarchie aus und wählt die passende PHP-Template-Datei aus, wie z. B. single.php, page.php oder archive.php. Diese Datei enthält PHP-Logik, die HTML direkt ausgibt.
Block-Themes
WordPress prüft, ob eine benutzerdefinierte Blockvorlage in der Datenbank vorhanden ist. Ist dies der Fall, hat sie Vorrang. Wenn nicht, greift WordPress auf die im Theme enthaltene Blockvorlagendatei zurück, wie z. B. single.html oder index.html.
Die ausgewählte Vorlage wird dann durch das Block-Rendering-System verarbeitet.
6. Layout-Zusammenstellung
Klassische Themes
Das Layout wird über PHP-Vorlagen aufgebaut. Diese Vorlagen kombinieren Markup, Logik und Funktionsaufrufe, um HTML-Ausgabe zu erzeugen.
Block-Themes
Das Layout wird aus Blockvorlagen, Vorlagenteilen und Beitragsinhalten zusammengesetzt. Das Block-Markup wird geparst, und jeder Block wird in HTML gerendert, bevor die endgültige Ausgabe generiert wird.
7. Inhaltsstruktur
Klassische Themes
Beitragsinhalte werden in der Datenbank hauptsächlich als HTML gespeichert. Bei der Ausgabe wendet WordPress vor dem Rendern Filter, Shortcodes und andere Verarbeitungsschritte an.
Block-Themes
Blockinhalte werden als HTML mit eingebetteten Block-Metadaten gespeichert, zum Beispiel:
<!-- wp:image {"id":123} -->
<img src="logo.png">
<!-- /wp:image -->Wenn WordPress diesen Inhalt verarbeitet, analysiert es die Blockstruktur, erkennt Attribute und Verschachtelungen und wendet Attribute und Stile auf Blockebene an, wie z. B. Abstände, Ausrichtung und Typografie, bevor es den endgültigen HTML-Code generiert.
8. Dynamisches Rendering
Dynamisches Rendering gibt es sowohl in klassischen als auch in Block-Themes. Viele klassische Themes nutzen benutzerdefinierte Abfragen, Widgets oder Shortcodes, die die Ausgabe zur Laufzeit generieren.
In blockbasierten Architekturen wird dynamisches Verhalten durch dynamische Blöcke formalisiert. Ein Query-Loop-Block generiert beispielsweise sein Markup während der Anfrage mithilfe von PHP, anstatt statisches HTML in der Datenbank zu speichern.
Wenn das Vollseiten-Caching umgangen wird, findet dieser Rendering-Workflow bei jeder Anfrage statt.
9. Styling
Bei klassischen Themes erfolgt das Styling in der Regel über statische CSS-Dateien, die vom Theme in die Warteschlange gestellt werden.
Bei Block-Themes ermöglichen globale Stile, die in theme.json und den Block-Metadaten definiert sind, WordPress, automatisch konsistentes CSS zu generieren. Dies reduziert den Bedarf an großen, manuell erstellten Stylesheets und zentralisiert die Designkonfiguration.
10. Endgültige Ausgabe
Nachdem Vorlagen, Inhalte, Blöcke und Stile verarbeitet wurden, erzeugt WordPress die endgültige HTML-Antwort.
Der Server sendet die Daten an den Browser. Falls konfiguriert, kann die Antwort dann für zukünftige Anfragen zwischengespeichert werden.
Wo Block-Themes die Last verlagern
Der soeben beschriebene Lebenszyklus einer Anfrage gilt sowohl für klassische als auch für Block-Themes. WordPress löst weiterhin Abfragen auf, wählt Vorlagen aus, führt PHP aus und gibt HTML zurück.
Was sich bei Block-Themes ändert, ist nicht die Grundlage, sondern wo die Arbeit stattfindet und wann sie nicht übersprungen werden kann. Erstens können Vorlagen in der Datenbank gespeichert werden. Wenn ein Benutzer eine Vorlage im Site-Editor bearbeitet, speichert WordPress diese Version und gibt ihr Vorrang vor der Datei im Theme-Verzeichnis. Das sorgt für mehr Flexibilität, bedeutet aber auch, dass bei Bereitstellungen und der Cache-Invalidierung die in der Datenbank gespeicherten Vorlagen berücksichtigt werden müssen.
Zweitens machen dynamische Blöcke das Rendering zur Laufzeit sichtbarer. Klassische Themes können durch benutzerdefinierte Abfragen, Widgets oder Shortcodes dynamische Ausgaben generieren. Block-Themes formalisieren dieses Muster durch dynamische Blöcke wie den Query-Loop-Block. Wenn das Vollseiten-Caching umgangen wird, führen diese Blöcke während der Anfrage PHP-Code aus.
Drittens stützen sich Editor-Workflows stark auf REST-Endpunkte. Das Speichern von Vorlagen, das Aktualisieren globaler Stile, die Vorschau von Änderungen und die Interaktion mit Mustern erzeugen nicht zwischengespeicherte Anfragen. Diese Pfade hängen direkt von der PHP-Ausführung, der Datenbankleistung und dem Objekt-Caching ab.
Schließlich zentralisieren globale Stile, die in theme.json definiert sind, Designentscheidungen. Wenn sich Stile oder Vorlagenstrukturen ändern, wird die Cache-Koordination wichtiger, um sicherzustellen, dass Besucher und Editoren die aktualisierte Ausgabe sofort sehen.
Keine dieser Veränderungen erfordert eine andere Art von Hosting. Sie machen jedoch bestimmte Schwächen der Infrastruktur deutlicher sichtbar, insbesondere in nicht zwischengespeicherten und angemeldeten Szenarien.
Vor diesem Hintergrund besteht der nächste Schritt darin, zu prüfen, was eine gut konfigurierte Hosting-Umgebung in einer blockbasierten Konfiguration leisten sollte.
Hosting-Überlegungen für blockbasierte Websites
Block-Themes führen keine neuen Hosting-Anforderungen ein. Sie machen es jedoch wichtiger, die bestehenden richtig umzusetzen.
Eine gut konfigurierte Umgebung sollte sowohl zwischengespeicherte als auch nicht zwischengespeicherte Pfade berücksichtigen, insbesondere für Redakteure und angemeldete Benutzer.
Koordiniertes Caching über alle Ebenen hinweg
Das Caching ganzer Websites bleibt die effektivste Performance-Ebene für anonymen Traffic. Öffentliche Websites sollten intensiv zwischengespeichert werden, während Vorschauen, angemeldete Sitzungen und bestimmte Endpunkte automatisch umgangen werden.
Auch das Objekt-Caching spielt eine wichtige Rolle. Durch das Speichern wiederholter Abfrageergebnisse und berechneter Datenstrukturen im Speicher reduziert ein Objekt-Cache die Datenbanklast und verbessert die Reaktionsgeschwindigkeit sowohl im Frontend als auch im Backend.
Die Cache-Invalidierung muss koordiniert werden. Wenn Inhalte, Vorlagen oder globale Stile aktualisiert werden, sollten die zugehörigen Websites umgehend aktualisiert werden. Eine schlechte Cache-Koordination kann zu veralteten Layouts, inkonsistenten Stilen oder verwirrendem Vorschau-Verhalten führen.
Ein CDN ergänzt diese Konfiguration, indem es statische Assets wie Bilder, Schriftarten und Skripte näher am Besucher zwischenspeichert.
Beim Caching geht es nicht um eine einzelne Ebene. Es geht darum, wie diese Ebenen zusammenarbeiten.
PHP-Kapazität und Laufzeitleistung
Wenn das Vollseiten-Caching umgangen wird, führt WordPress PHP aus, um Abfragen zu lösen, Vorlagen zu rendern und dynamische Blöcke zu verarbeiten.
Dadurch wird die PHP-Kapazitätsplanung wichtig. Die Umgebung sollte genügend PHP-Threads bereitstellen, um die erwartete Parallelität ohne Warteschlangenbildung zu bewältigen. Speichergrenzen sollten so konfiguriert werden, dass unter Last kein Swapping auftritt.
OPcache sollte aktiviert und richtig dimensioniert sein, damit PHP-Bytecode nicht wiederholt neu kompiliert werden muss. Während der Bereitstellung sollte OPcache aktualisiert werden, damit aktualisierter Code sofort ausgeführt wird.
Diese Vorgehensweisen gelten für alle WordPress-Websites, aber blockbasierte Workflows können Leistungsprobleme bei dynamischem Rendering deutlicher machen.
Datenbank- und Objekt-Caching
Im Site Editor angepasste Blockvorlagen werden in der Datenbank gespeichert. Blockinhalte enthalten strukturierte Metadaten, die WordPress vor der Ausgabe auswertet. Diese Verarbeitung ist zwar effizient, hängt aber dennoch von der Reaktionsgeschwindigkeit der Datenbank ab, wenn das Caching umgangen wird.
Ein persistenter Objekt-Cache reduziert wiederholte Abfragen und trägt dazu bei, die Leistung sowohl für Frontend-Besucher als auch für Editoren, die im Dashboard arbeiten, zu stabilisieren.
Beobachtbarkeit und Überwachung
Da sich immer mehr Aktivitäten in Laufzeitpfade verlagern, wird Transparenz immer wichtiger. Hosts und Website-Betreiber sollten Folgendes überwachen:
- Cache-Trefferquoten
- PHP-Worker-Auslastung und Warteschlangenlänge
- Leistung von Datenbankabfragen
- REST-API-Antwortzeiten
- Zeit bis zum ersten Byte bei zwischengespeicherten und nicht zwischengespeicherten Anfragen
Block-Themes erfordern keine spezielle Infrastruktur. Sie machen es jedoch einfacher zu erkennen, wenn die Infrastruktur nicht optimal konfiguriert ist.
WordPress so betreiben, wie es heute funktioniert
Block-Themes ändern nichts daran, was WordPress vom Hosting benötigt. Sie machen es nur deutlicher, wenn diese Anforderungen nicht erfüllt werden.
Wenn Vorlagen in der Datenbank liegen, wenn dynamische Blöcke zur Laufzeit gerendert werden und wenn Editoren auf nicht zwischengespeicherte REST-Anfragen angewiesen sind, ist die Infrastruktur nicht mehr unsichtbar. Entweder unterstützt sie den Workflow reibungslos oder sie steht im Weg.
Genau hier macht Managed Hosting für WordPress den Unterschied.
Bei Kinsta ist der gesamte Stack speziell auf die heutige Funktionsweise von WordPress ausgelegt – von koordiniertem Caching und persistenter Objekt-Caching bis hin zu optimierter PHP-Leistung und globaler CDN-Bereitstellung auf einer leistungsstarken Cloud-Infrastruktur. Das Ziel ist es, sicherzustellen, dass sowohl Besucher als auch Editoren eine konsistente Leistung erleben, selbst wenn das Rendering dynamisch erfolgt.
Blockbasiertes WordPress ist nicht schwerer. Es ist transparenter. Und wenn das Fundament solide ist, wirkt sich diese Transparenz zu deinem Vorteil aus.
Bud Kraus has been working with WordPress as an in-class and online instructor, site developer, and content creator since 2009. He has produced instructional videos and written many articles for WordPress businesses.
