Automatic Gzip compression on responses

KrakenD Enterprise compresses with gzip all traffic returned to the client when the request contains an Accept-Encoding: gzip header.

The gzip response compression is not applied when the header is missing or when the Accept-Encoding header contains a text/event-stream value.

Gzip compression is unrelated to decompression when consuming content from your services. Decompression is also done automatically, but in all KrakenD flavors, not only Enterprise.

When the content is successfully compressed, the response contains a "Content-Encoding: gzip" header.

Gzip configuration

The gzip is always on unless you disable it in the router section. The gzip_profile field, available since v3.0, lets you choose how aggressively KrakenD compresses:

{
  "version": 4,
  "extra_config": {
    "router": {
      "disable_gzip": false,
      "gzip_profile": "balanced"
    }
  }
}

Both settings live at the service level and apply to every endpoint. You cannot use a different profile per endpoint.

Compression profiles

A compression profile picks the gzip compression level KrakenD uses when writing the response. Every profile emits standard gzip, so clients decompress all three identically and you can change the profile at any time without coordinating with API consumers. The only thing that changes is the size of the payload on the wire and the resources KrakenD spends producing it.

If you are unsure which profile suits your traffic, use balanced. It is the default because it matches most workloads, and you only need to move away from it when you have measured that bandwidth or CPU is the constraint you want to optimize for.

The gzip_profile field has no effect when disable_gzip is true, as KrakenD does not compress anything in that case.

Speed versus bandwidth trade-off

Gzip gives diminishing returns as you raise the compression level. Moving from speed to compression usually shaves only a few additional percentage points off the payload, while the CPU time spent on each response grows several times over. The gateway compresses on the hot path of every request, so that extra CPU shows up as added latency and as less headroom to absorb traffic peaks.

What you gain also depends on the payload. Large JSON responses with repetitive structures, such as the aggregation of several backends or long collections, compress well and reward a higher level. Small responses of a few hundred bytes compress poorly at any level, and the difference between profiles is negligible.

Use these criteria to decide:

• Choose speed when KrakenD is CPU-bound, when you run at high requests per second, or when latency is your primary concern and bandwidth is cheap.
• Keep balanced for general-purpose traffic. It captures most of the size reduction without paying the CPU cost of the maximum level.
• Choose compression when egress bandwidth is the expensive part of your bill, when clients sit on slow or metered networks such as mobile apps, or when you return large bodies and have CPU to spare.