X-Compress-Hint
Direct Fastly to compress a response before emitting it.
Fastly reads this header from responses and writes it into responses. It is proprietary to Fastly.
This non-standard header is used by Fastly to trigger compression of outbound client responses. It can be set in a service configuration by writing VCL or Compute@Edge code:
- Fastly VCL
- Rust
- JavaScript
- Go
response.set_header("x-compress-hint", "on");IMPORTANT: Use of the X-Compress-Hint header for services created after 25 April 2023 requires participation in the Dynamic Content Compression beta program. For more information, contact our sales team.
If present in a response at the time it is served to a client, Fastly will inspect the Accept-Encoding value on the matching request, and if the client accepts compressed responses, will apply streaming compression to the response body and add a Content-Encoding header. Regardless of whether compression is triggered, the X-Compress-Hint header will be removed.
Valid values are "on", "gzip" and "br". "on" will select a compression algorithm automatically, preferring brotli if both are supported by the client. In either case, the compression level applied is level 1.
In VCL services, it can be more efficient to compress responses before caching them, rather than compressing the content each time it is served. See the VCL variables beresp.gzip and beresp.brotli or our guide to compression on Fastly for more details.
In services that use shielding or service chaining, the client may be Fastly. If you intend to apply the compress hint only when a response is to be finally served to the end user, use the Fastly-FF header in Compute@Edge services or, in VCL, the fastly.ff.visits_this_service variable.
Any Content-Length header present on the response is removed when the response is compressed, since Fastly is unable to determine what the content length is at the time the header block is transmitted. Any ETag header is preserved.