GraphQL performance, from first request to peak load

Query plan warming, operation hashing, cache header management, and per-phase traces. Five capabilities, built into the Cosmo Router.

No third-party performance layers required.

Performance tools, built into Cosmo

The Cosmo Router ships with five performance capabilities. Each addresses a distinct bottleneck in federated GraphQL: query plan cold starts, redundant payload bytes, cache header coordination across subgraphs, and slow-phase visibility.

Persisted Operations and APQ reduce the data on the wire. Cache Control and Cache Warmer handle what gets cached and when. Performance Debugging tells you exactly which phase is slow. All five work together and require no external performance layer.

Four problems generic tools cannot solve

Federated GraphQL has performance characteristics that HTTP proxies, generic CDNs, and APM tools were not designed to address. These problems surface at scale and require graph-aware tooling.

Query planning adds latency on every cold start.

When a router starts or restarts, the query plan cache is empty. The first execution of each operation pays the full planning cost before responding to users.

Full operation bodies repeat on every request.

GraphQL clients send the complete query text with each request. For complex operations, this adds kilobytes of redundant payload on every call.

Cache headers are hard to coordinate across subgraphs.

In a federated graph, responses aggregate data with different caching requirements. Misconfiguration risks caching sensitive data or missing caching opportunities for static content.

Slow requests have no per-phase breakdown.

Generic APM tools see HTTP latency. They cannot tell you whether delay comes from query planning, a specific subgraph fetch, or authentication. Diagnosing the root cause takes guesswork.

Cosmo Performance handles all four. No additional infrastructure, no custom wiring.

Cosmo Performance capabilities

01 Operation efficiency

02 Response caching

03 Debugging

Persisted Operations

Pre-register operations in CI/CD. Clients send a SHA-256 hash instead of the full operation body. Routers fetch registered operations from the CDN and reject anything not on the list. Three enforcement modes: log-only, safelist, or full blocking.

Automatic Persisted Queries (APQ)

Zero-registration query caching. The first request sends the full query body alongside its hash; the router stores the mapping. Every subsequent request sends only the hash, enabling GET-based CDN caching. In-memory or Redis-backed storage.

Performance use cases

Real patterns where Cosmo Performance capabilities deliver measurable improvement.

Peak traffic preparation

Pre-warm query plans before a flash sale starts

Scenario: An e-commerce platform expects 10x normal traffic for a limited-time sale. Router restarts during the preceding deployment clear the query plan cache.

How Cosmo handles it: Enable the Cache Warmer at the namespace level. At router startup, it fetches a manifest of slow operations from the CDN—identified by P90 latency—and precomputes their plans. Add critical queries manually with wgc router cache push.

Outcome: Every query executes at cached speed from the first request. Cold-start latency does not appear during the sale.

Mobile bandwidth

Cut GraphQL payload size on cellular networks

Scenario: A mobile application sends complex queries that consume significant bandwidth, especially on slow connections.

How Cosmo handles it: Enable Persisted Operations or APQ. After the first execution, clients send only a short hash instead of the full query body. APQ requires no changes to CI/CD; operations are registered on first use.

Outcome: After initial registration, each request carries only a short hash instead of the full query body, cutting payload size from kilobytes to a fraction of that.

Bottleneck investigation

Identify which subgraph is adding latency

Scenario: A query spanning several subgraphs has inconsistent response times. The team needs to know whether the delay is in planning or in a specific subgraph fetch.

How Cosmo handles it: Open Cosmo Studio trace view and filter for slow operations. Compare the Operation - Planning span against the Operation - Execution span. Check the enginePlanCacheHit attribute to rule out cache misses as the cause.

Outcome: The slow subgraph is identified from the trace. The team fixes the resolver rather than guessing.

Which performance capability do you need?

How Cosmo Performance compares

Why teams use Cosmo Performance

• No cold-start latency. The Cache Warmer precomputes query plans from telemetry-identified slow operations before traffic arrives. Router restarts do not expose users to planning overhead.
• Less data on the wire. Persisted Operations and APQ send a short hash instead of the full query body on every request. CDN edge caching becomes possible via standard GET requests.
• Cache headers correct by default. Cache Control evaluates every subgraph response and applies the strictest policy. Mutations get no-cache automatically. Error responses get no-store, no-cache, must-revalidate.
• Bottlenecks visible in minutes. OpenTelemetry spans for authentication, parsing, planning, and execution are generated automatically. The enginePlanCacheHit attribute shows whether a plan came from cache.

Fast GraphQL from day one

SOC 2 Type II

HIPAA

ISO 27001