{"id":75825,"date":"2026-03-27T10:21:26","date_gmt":"2026-03-27T09:21:26","guid":{"rendered":"https:\/\/kinqsta.com\/de\/?p=75825&preview=true&preview_id=75825"},"modified":"2026-03-31T13:06:06","modified_gmt":"2026-03-31T12:06:06","slug":"block-themes-wordpress-hosting","status":"publish","type":"post","link":"https:\/\/kinqsta.com\/de\/blog\/block-themes-wordpress-hosting\/","title":{"rendered":"Wie moderne Block-Themes das WordPress-Hosting ver\u00e4ndern"},"content":{"rendered":"

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\u00e4lt, wie es mit Caching<\/a> umgeht und wie es PHP ausf\u00fchrt.<\/p>\n

Block-Themes<\/a> \u00e4ndern zwar nichts an den Grundlagen des Hostings, aber sie ver\u00e4ndern, wo Leistungsengp\u00e4sse 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\u00f6cke, der Site Editor<\/a>, Vorschauen und angemeldete Sitzungen im Spiel sind.<\/p>\n

Um zu verstehen, warum das so ist, hilft es, sich anzuschauen, was bei einer Seitenanfrage tats\u00e4chlich passiert und wie sich Hosting-Entscheidungen auf die Benutzererfahrung auswirken, wenn eine blockbasierte Architektur verwendet wird.<\/p>\n

<\/div><\/kinsta-auto-toc>\n

Was passiert, wenn eine WordPress-Website angefordert wird<\/h2>\n

Schauen wir uns eine einfache Anfrage an, die eine 200 OK-Antwort<\/a> zur\u00fcckgibt.<\/p>\n

1. Der Browser sendet die Anfrage<\/h3>\n

Ein Nutzer gibt eine URL ein oder klickt auf einen Link. Wenn die IP-Adresse des Servers noch nicht im Cache gespeichert ist, f\u00fchrt der Browser eine DNS-Abfrage<\/a> durch. Anschlie\u00dfend \u00f6ffnet er eine TCP-Verbindung und handelt eine sichere TLS-Sitzung<\/a> aus.<\/p>\n

Bevor WordPress ins Spiel kommt, durchl\u00e4uft die Anfrage den Webserver und alle konfigurierten Ebenen wie Firewalls oder Reverse-Proxys.<\/p>\n

2. Cache-Pr\u00fcfung<\/h3>\n

Der Server pr\u00fcft, ob eine g\u00fcltige zwischengespeicherte Version der angeforderten Website vorhanden ist.<\/p>\n

Wenn ein HTML-Cache der gesamten Seite<\/a> verf\u00fcgbar und g\u00fcltig ist, wird WordPress nicht ausgef\u00fchrt. Die zwischengespeicherte Antwort wird sofort zur\u00fcckgegeben.<\/p>\n

Wenn kein Cache-Eintrag vorhanden ist oder wenn das Caching f\u00fcr angemeldete Benutzer, Vorschauen oder bestimmte Endpunkte absichtlich umgangen wird, wird die Anfrage an WordPress weitergeleitet.<\/p>\n

3. WordPress startet<\/h3>\n

WordPress l\u00e4dt seine Kerndateien, die aktiven Plugins und das aktive Theme. Es initialisiert Hooks und bereitet sich darauf vor, die Anfrage zu bearbeiten.<\/p>\n

In dieser Phase rendert WordPress noch keine Ausgabe. Es ermittelt, welche Inhalte angefordert werden.<\/p>\n

4. Aufl\u00f6sung der Hauptabfrage<\/h3>\n

Mithilfe von Rewrite-Regeln und Abfragevariablen erstellt und f\u00fchrt WordPress die Hauptdatenbankabfrage aus. Es ermittelt, ob die Anfrage einen einzelnen Beitrag, eine Seite, ein Archiv, ein Suchergebnis oder einen anderen Inhaltstyp betrifft.<\/p>\n

Erst danach beginnt die Template-Auswahl.<\/p>\n

5. Template-Aufl\u00f6sung<\/h3>\n

Hier beginnen sich Block- und klassische Themes strukturell zu unterscheiden.<\/p>\n

Klassische Themes<\/h4>\n

WordPress wertet die Template-Hierarchie aus und w\u00e4hlt die passende PHP-Template-Datei aus, wie z. B. single.php, page.php oder archive.php. Diese Datei enth\u00e4lt PHP-Logik, die HTML direkt ausgibt.<\/p>\n

Block-Themes<\/h4>\n

WordPress pr\u00fcft, 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\u00fcck, wie z. B. single.html oder index.html.<\/p>\n

Die ausgew\u00e4hlte Vorlage wird dann durch das Block-Rendering-System verarbeitet.<\/p>\n

6. Layout-Zusammenstellung<\/h3>\n

Klassische Themes<\/h4>\n

Das Layout wird \u00fcber PHP-Vorlagen aufgebaut. Diese Vorlagen kombinieren Markup, Logik und Funktionsaufrufe, um HTML-Ausgabe zu erzeugen.<\/p>\n

Block-Themes<\/h4>\n

Das Layout wird aus Blockvorlagen, Vorlagenteilen und Beitragsinhalten zusammengesetzt. Das Block-Markup wird geparst, und jeder Block wird in HTML gerendert, bevor die endg\u00fcltige Ausgabe generiert wird.<\/p>\n

7. Inhaltsstruktur<\/h3>\n

Klassische Themes<\/h4>\n

Beitragsinhalte werden in der Datenbank haupts\u00e4chlich als HTML gespeichert. Bei der Ausgabe wendet WordPress vor dem Rendern Filter, Shortcodes und andere Verarbeitungsschritte an.<\/p>\n

Block-Themes<\/h4>\n

Blockinhalte werden als HTML mit eingebetteten Block-Metadaten gespeichert, zum Beispiel:<\/p>\n

<!-- wp:image {\"id\":123} -->\n\n<img src=\"logo.png\">\n\n<!-- \/wp:image --><\/code><\/pre>\n
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\u00e4nde, Ausrichtung und Typografie, bevor es den endg\u00fcltigen HTML-Code generiert.<\/p>\n
8. Dynamisches Rendering<\/h3>\n
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.<\/p>\n
In blockbasierten Architekturen wird dynamisches Verhalten durch dynamische Bl\u00f6cke formalisiert. Ein Query-Loop-Block generiert beispielsweise sein Markup w\u00e4hrend der Anfrage mithilfe von PHP, anstatt statisches HTML in der Datenbank zu speichern.<\/p>\n
Wenn das Vollseiten-Caching umgangen wird, findet dieser Rendering-Workflow bei jeder Anfrage statt.<\/p>\n
9. Styling<\/h3>\n
Bei klassischen Themes erfolgt das Styling in der Regel \u00fcber statische CSS-Dateien<\/a>, die vom Theme in die Warteschlange gestellt werden.<\/p>\n
Bei Block-Themes erm\u00f6glichen globale Stile, die in theme.json<\/code> und den Block-Metadaten definiert sind, WordPress, automatisch konsistentes CSS zu generieren. Dies reduziert den Bedarf an gro\u00dfen, manuell erstellten Stylesheets und zentralisiert die Designkonfiguration.<\/p>\n
10. Endg\u00fcltige Ausgabe<\/h3>\n
Nachdem Vorlagen, Inhalte, Bl\u00f6cke und Stile verarbeitet wurden, erzeugt WordPress die endg\u00fcltige HTML-Antwort.<\/p>\n
Der Server sendet die Daten an den Browser. Falls konfiguriert, kann die Antwort dann f\u00fcr zuk\u00fcnftige Anfragen zwischengespeichert werden.<\/p>\n
Wo Block-Themes die Last verlagern<\/h2>\n
Der soeben beschriebene Lebenszyklus einer Anfrage gilt sowohl f\u00fcr klassische als auch f\u00fcr Block-Themes<\/a>. WordPress l\u00f6st weiterhin Abfragen auf, w\u00e4hlt Vorlagen aus, f\u00fchrt PHP aus und gibt HTML zur\u00fcck.<\/p>\n
Was sich bei Block-Themes \u00e4ndert, ist nicht die Grundlage, sondern wo die Arbeit stattfindet und wann sie nicht \u00fcbersprungen werden kann. Erstens k\u00f6nnen Vorlagen<\/a> 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\u00fcr mehr Flexibilit\u00e4t, bedeutet aber auch, dass bei Bereitstellungen und der Cache-Invalidierung die in der Datenbank gespeicherten Vorlagen ber\u00fccksichtigt werden m\u00fcssen.<\/p>\n
Zweitens machen dynamische Bl\u00f6cke<\/a> das Rendering zur Laufzeit sichtbarer. Klassische Themes k\u00f6nnen durch benutzerdefinierte Abfragen, Widgets oder Shortcodes dynamische Ausgaben generieren. Block-Themes formalisieren dieses Muster durch dynamische Bl\u00f6cke wie den Query-Loop-Block. Wenn das Vollseiten-Caching umgangen wird, f\u00fchren diese Bl\u00f6cke w\u00e4hrend der Anfrage PHP-Code aus.<\/p>\n
Drittens st\u00fctzen sich Editor-Workflows stark auf REST-Endpunkte. Das Speichern von Vorlagen, das Aktualisieren globaler Stile, die Vorschau von \u00c4nderungen und die Interaktion mit Mustern erzeugen nicht zwischengespeicherte Anfragen. Diese Pfade h\u00e4ngen direkt von der PHP-Ausf\u00fchrung, der Datenbankleistung und dem Objekt-Caching ab.<\/p>\n
Schlie\u00dflich zentralisieren globale Stile, die in theme.json<\/a><\/code> definiert sind, Designentscheidungen. Wenn sich Stile oder Vorlagenstrukturen \u00e4ndern, wird die Cache-Koordination wichtiger, um sicherzustellen, dass Besucher und Editoren die aktualisierte Ausgabe sofort sehen.<\/p>\n
Keine dieser Ver\u00e4nderungen erfordert eine andere Art von Hosting. Sie machen jedoch bestimmte Schw\u00e4chen der Infrastruktur deutlicher sichtbar, insbesondere in nicht zwischengespeicherten und angemeldeten Szenarien.<\/p>\n
Vor diesem Hintergrund besteht der n\u00e4chste Schritt darin, zu pr\u00fcfen, was eine gut konfigurierte Hosting-Umgebung in einer blockbasierten Konfiguration leisten sollte.<\/p>\n
Hosting-\u00dcberlegungen f\u00fcr blockbasierte Websites<\/h2>\n
Block-Themes f\u00fchren keine neuen Hosting-Anforderungen ein. Sie machen es jedoch wichtiger, die bestehenden richtig umzusetzen.<\/p>\n
Eine gut konfigurierte Umgebung sollte sowohl zwischengespeicherte als auch nicht zwischengespeicherte Pfade ber\u00fccksichtigen, insbesondere f\u00fcr Redakteure und angemeldete Benutzer.<\/p>\n
Koordiniertes Caching \u00fcber alle Ebenen hinweg<\/h3>\n
Das Caching ganzer Websites<\/a>\u00a0bleibt die effektivste Performance-Ebene f\u00fcr anonymen Traffic. \u00d6ffentliche Websites sollten intensiv zwischengespeichert werden, w\u00e4hrend Vorschauen, angemeldete Sitzungen und bestimmte Endpunkte automatisch umgangen werden.<\/p>\n
Auch das Objekt-Caching<\/a> 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.<\/p>\n
Die Cache-Invalidierung muss koordiniert werden. Wenn Inhalte, Vorlagen oder globale Stile aktualisiert werden, sollten die zugeh\u00f6rigen Websites umgehend aktualisiert werden. Eine schlechte Cache-Koordination kann zu veralteten Layouts, inkonsistenten Stilen oder verwirrendem Vorschau-Verhalten f\u00fchren.<\/p>\n
Ein CDN erg\u00e4nzt diese Konfiguration, indem es statische Assets wie Bilder, Schriftarten und Skripte n\u00e4her am Besucher zwischenspeichert.<\/p>\n
Beim Caching<\/a> geht es nicht um eine einzelne Ebene. Es geht darum, wie diese Ebenen zusammenarbeiten.<\/p>\n
PHP-Kapazit\u00e4t und Laufzeitleistung<\/h3>\n
Wenn das Vollseiten-Caching umgangen wird, f\u00fchrt WordPress PHP aus, um Abfragen zu l\u00f6sen, Vorlagen zu rendern und dynamische Bl\u00f6cke zu verarbeiten.<\/p>\n
Dadurch wird die PHP-Kapazit\u00e4tsplanung wichtig. Die Umgebung sollte gen\u00fcgend PHP-Threads<\/a> bereitstellen, um die erwartete Parallelit\u00e4t ohne Warteschlangenbildung zu bew\u00e4ltigen. Speichergrenzen<\/a> sollten so konfiguriert werden, dass unter Last kein Swapping auftritt.<\/p>\n
OPcache sollte aktiviert und richtig dimensioniert sein, damit PHP-Bytecode nicht wiederholt neu kompiliert werden muss. W\u00e4hrend der Bereitstellung sollte OPcache aktualisiert werden, damit aktualisierter Code sofort ausgef\u00fchrt wird.<\/p>\n
Diese Vorgehensweisen gelten f\u00fcr alle WordPress-Websites, aber blockbasierte Workflows k\u00f6nnen Leistungsprobleme bei dynamischem Rendering deutlicher machen.<\/p>\n
Datenbank- und Objekt-Caching<\/h3>\n
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\u00e4ngt aber dennoch von der Reaktionsgeschwindigkeit der Datenbank ab, wenn das Caching umgangen wird.<\/p>\n
Ein persistenter Objekt-Cache reduziert wiederholte Abfragen und tr\u00e4gt dazu bei, die Leistung sowohl f\u00fcr Frontend-Besucher als auch f\u00fcr Editoren, die im Dashboard arbeiten, zu stabilisieren.<\/p>\n
Beobachtbarkeit und \u00dcberwachung<\/h3>\n
Da sich immer mehr Aktivit\u00e4ten in Laufzeitpfade verlagern, wird Transparenz immer wichtiger. Hosts und Website-Betreiber sollten Folgendes \u00fcberwachen:<\/p>\n