Headless Hosting, bei dem WordPress Daten und nicht Seiten bedient.
In einem Headless-Build ist es die Aufgabe des Origins, API-Aufrufe zu beantworten und dem Frontend zu sagen, wenn sich etwas verändert hat. Fast alles, was ein normaler WordPress-Host optimiert, ist hier irrelevant.
Alles, was ein kopfloser Build von einem Gastgeber verlangt.
Es kommt darauf an, wie lange die API-Response-Zeit ist und ob Ihr Frontend von einer Bearbeitung hört.
Publiziert, die das Frontend erreichen
Das Speichern eines Posts feuert einen Webhook ab, der die betroffenen Pfade trägt, so dass Ihre Next.js- oder Astro-Bereitstellung diese Routen erneut validiert, anstatt auf einen geplanten Umbau oder einen vollständigen Neueinsatz zu warten.
API-Antworten aus dem Speicher
REST- und GraphQL-Antworten stützen sich vollständig auf den Objekt-Cache, denn wenn die Antwort JSON ist, gibt es keinen Seiten-Cache davor, um eine langsame Abfrage dahinter zu verbergen.
Previews ohne öffentlichen Entwurf
Preview-Anfragen werden mit kurzlebigen Token authentifiziert, sodass Ihr Frontend unveröffentlichte Inhalte darstellen kann, ohne dass diese Inhalte von jedem erreichbar sind, der die URL erraten hat.
CORS und Origins konfiguriert, nicht erraten
Zulässige Ursprünge werden am Rand Ihres Produktionsfrontends festgelegt und seine Vorschau-Bereitstellungen, die die Einstellung sind, die die meisten Headless-Builds am Starttag entdecken, sind falsch.
Medien unabhängig vom Frontend
Uploads dienen weiterhin vom WordPress-Ursprung bis zum Edge, so dass das Ändern des Frontend-Frameworks niemals das erneute Hosten der Medienbibliothek bedeutet.
Ein Backend, mehrere Frontends.
Headless-Setups enden mit einem Produktionsfrontend, einer Vorschau-Bereitstellung und einer Build-Pipeline, die alle dasselbe WordPress lesen. Das Dashboard ist dafür und nicht für eine Site konzipiert.
- Webhook-Lieferprotokoll pro Publizieren
- API Response Timing nach Endpunkt
- Ein-Klick-Admin-Login für Editoren
- Jedes tägliche Backup vom Dashboard wiederherstellen
Eine GraphQL-Abfrage während eines statischen Builds.
Ein Build trifft die API hunderte Male in wenigen Sekunden. Dieser Burst, anstatt das Laden einer Besucherseite, ist die Arbeitslast, die der Ursprung tatsächlich überleben muss.
Was wir für einen Headless Build ändern
Dies sind die Einstellungen, die sich von einer Standard-WordPress-Site auf dem gleichen Plan unterscheiden. Jede folgt aus dem Ursprung Anrufbeantworter und nicht Browser.
| Einstellung | So konfigurieren wir es | Warum |
|---|---|---|
| Ganzseitiger Cache | Deaktiviert am Ursprung; Caching gehört zum Frontend | Nichts hier macht HTML, so dass ein Seiten-Cache vor einem API-Endpunkt nur eine Ebene hinzufügt, die dann korrekt ungültig gemacht werden muss. |
| Haken veröffentlichen | Webhook feuerte auf Save trägt die betroffenen Pfade | Ohne einen baut das Frontend entweder alles auf einem Timer neu oder serviert veraltete Inhalte, bis jemand bemerkt und einen Einsatz auslöst. |
| Objektcache | Redis, Größe für wiederholte API-Lesevorgänge während Builds | Ein statischer Build fragt die gleichen Taxonomien hunderte Male innerhalb weniger Sekunden ab, und jede ungespeicherte davon ist eine Datenbank-Runde. |
| Vorschauanforderungen | Authentifizierung mit kurzlebigen Token statt einem gemeinsamen Geheimnis | Ein langlebiger Vorschauschlüssel wird einem Frontend-Repository zugewiesen, und an diesem Punkt sind die Entwürfe effektiv öffentlich. |
| CORS-Politik | Zulässige Ursprünge, konfiguriert für Produktions- und Vorschaudomänen | Preview-Bereitstellungen erhalten einen neuen Hostnamen für jeden Zweig und eine Richtlinie, die einmal für alle Produktionsblöcke geschrieben wurde. |
Einfache, transparente Preise.
Jeder Tarif umfasst eine kostenlose Migration, tägliche Backups, SSL und Support rund um die Uhr.
- 1 WordPress-Website
- 10 GB NVMe-Speicher
- Kostenloses SSL
- Tägliche Backups
- Bereitstellung mit einem Klick
- Support per Ticket
- 5 WordPress-Websites
- 50 GB NVMe-Speicher
- Kostenloses SSL
- Tägliche Backups
- Bereitstellung mit einem Klick
- Priorisierter Support per Ticket
- 20 WordPress-Websites
- 200 GB NVMe-Speicher
- Kostenloses SSL
- Tägliche Backups
- Bereitstellung mit einem Klick
- Persönlicher Support
Häufige Fragen.
Unterstützen Sie WPGraphQL und die REST API?
Woher weiß mein Frontend, dass sich etwas verändert hat?
Wo läuft das Frontend selbst?
Können Redakteure noch eine Vorschau auf Entwürfe erstellen?
Ist der Admin noch schnell?
Bewegen Sie Ihr Headless Backend zu einem Host, der weiß, dass es einer ist.
Kostenlose Migration, Ungültigerklärung auf Veröffentlichung geschoben, und Vorschauen, die nie einen Entwurf aussetzen.