Summary
Measure and, if justified, offload SSAT HTML compression work from the Compute guest.
The current SSAT HTML rewrite path mirrors origin content encoding, which means gzip/deflate/brotli responses are decompressed and recompressed inside the guest. That CPU work is paid on every SSAT pageview because assembled HTML is private and not shared-cacheable.
Problem
For large publisher documents, in-guest decompression/recompression can become a major vCPU cost and may increase risk of hitting Compute CPU limits. Fastly supports delivery compression via X-Compress-Hint: on, but using it with an Accept-Encoding: identity origin fetch changes wire-size behavior and needs measurement before becoming default.
Proposed scope
- Measure current SSAT HTML compression CPU and wire sizes on representative pages.
- Test origin behavior for
Accept-Encoding: identity.
- Test Fastly delivery compression with
X-Compress-Hint: on.
- Compare current gzip/br-in + gzip/br-out behavior against identity-origin + delivery compression.
- Add a config flag or rollout guard if implementation proceeds.
Measurement plan
For representative large and normal pages:
- Fetch origin with
Accept-Encoding: identity, gzip, and br.
- Verify identity body equivalence after decompression.
- Run a flagged Fastly path using identity-origin +
X-Compress-Hint: on.
- Compare:
Content-Encoding
- transfer size
- TTFB/FCP if available
- guest CPU / vCPU-ms
- error/truncation behavior
Acceptance criteria
Out of scope
- Origin-template caching.
- Parser-safe streaming/body-close hold.
- Static asset compression policy.
Reference
See docs/superpowers/specs/2026-07-06-cache-control-header-design.md for why this is deferred from the initial cache-header PR.
Summary
Measure and, if justified, offload SSAT HTML compression work from the Compute guest.
The current SSAT HTML rewrite path mirrors origin content encoding, which means gzip/deflate/brotli responses are decompressed and recompressed inside the guest. That CPU work is paid on every SSAT pageview because assembled HTML is private and not shared-cacheable.
Problem
For large publisher documents, in-guest decompression/recompression can become a major vCPU cost and may increase risk of hitting Compute CPU limits. Fastly supports delivery compression via
X-Compress-Hint: on, but using it with anAccept-Encoding: identityorigin fetch changes wire-size behavior and needs measurement before becoming default.Proposed scope
Accept-Encoding: identity.X-Compress-Hint: on.Measurement plan
For representative large and normal pages:
Accept-Encoding: identity,gzip, andbr.X-Compress-Hint: on.Content-EncodingAcceptance criteria
Accept-Encoding: identityis confirmed or failure modes are documented.X-Compress-Hint: onbehavior is measured for representative HTML pages.private, max-age=0and no shared cacheability is introduced.Out of scope
Reference
See
docs/superpowers/specs/2026-07-06-cache-control-header-design.mdfor why this is deferred from the initial cache-header PR.