WPGraphQL hosting for a site with one URL and no pages.
Headless WordPress collapses the whole site into a single endpoint. Every technique built around caching pages stops applying, because there are no longer any pages.
One endpoint, every request.
All the traffic arrives at the same address asking different questions, which is the opposite of what a page cache is designed for.
Responses that can actually be cached
A GraphQL query is a POST body by default, and nothing caches POSTs. Queries are handled so identical requests can be served from cache instead of re-resolved every time.
A ceiling on what one query can ask for
A deeply nested query is a single request that can walk your entire dataset. Depth and complexity limits are set, so one client cannot ask a question the server should not answer.
Resolvers that do not fan out per field
Naive resolution turns one list of fifty posts into fifty author lookups and fifty term lookups. Those are batched, which is the difference between a fast endpoint and a slow one.
The build that fetches everything
A static front end regenerates by querying every node on the site at once. That run is treated as a known workload rather than as a traffic anomaly to be throttled.
WordPress is still the data
Headless changes the front end, not the responsibility. The database and uploads are backed up daily exactly as they would be for a rendered site.
The cache has nothing to hold.
Take away templates and you take away page caching, full-page caching and edge HTML. What is left is one endpoint doing real work on every call.
- Identical queries served from cache
- Query depth and complexity bounded
- Resolver lookups batched rather than per field
- Build-time fetches treated as expected load
The cost is in the fan-out.
A GraphQL response looks like one request and behaves like dozens of queries. What decides speed is how many of those are avoided.
What we change for WPGraphQL
Headless removes the tools everyone reaches for first, so the tuning moves entirely to the endpoint.
| Setting | What we do | Why |
|---|---|---|
| Endpoint caching | Repeated queries served without re-resolving | GraphQL requests arrive as POST bodies, which nothing caches by default, so an identical query costs full price every single time it is asked. |
| Query limits | Depth and complexity ceilings enforced | One nested query can traverse an entire dataset in a single request, which makes the endpoint trivially expensive to abuse by accident or otherwise. |
| Resolver batching | Related lookups grouped instead of per field | Resolving fifty posts naively means fifty author queries and fifty term queries, and that fan-out is the whole difference in headless performance. |
| Build-time traffic | Treated as a known workload, not throttled as abuse | A static regeneration fetches every node at once, which looks exactly like scraping to any rate limiter that was not told about it. |
| Introspection | Restricted in production | A public schema dump tells anyone precisely what to ask for, and the endpoint is the only surface a headless site has. |
Simple, transparent pricing.
Every plan includes free migration, daily backups, SSL and 24/7 support.
- 1 WordPress site
- 10 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Support tickets
- 5 WordPress sites
- 50 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Priority support tickets
- 20 WordPress sites
- 200 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Dedicated support
Questions, answered.
Can a GraphQL endpoint be cached at all?
Why is my headless site slower than the rendered one was?
Will a static build get rate limited?
Do I still need backups if the front end is separate?
Make the endpoint the fast part.
Move the backend across. Migration is free, schema untouched.