How do cache and compression work together?

Short answer

Both a Cache and a Compression profile can be assigned to the same HTTP vService. Content is written to the cache uncompressed; each response served from the cache is compressed in TR7 according to the client's compression support. This way, a single copy is served both to clients that support compression and to those that do not. If the Backend Service compresses the responses itself, Offloading is turned on in the Compression profile. The cache reduces the load on the Backend Service; the processor load of compression, however, remains on TR7 (using them together).

How Does It Work?

1. If the request is in the cache, the response is taken from the cache; otherwise it goes to the Backend Service and the response is written to the cache.
2. If the type of the response is in the File Types list of the Compression profile and the client supports compression with the Accept-Encoding header, the response is sent compressed; if it does not, the same copy is sent uncompressed.

Using Them Together in TR7

• The two lists are independent: Caching Rules look at the request path (e.g. the .css extension), File Types at the content type of the response (e.g. text/css). If .css is cached but text/css is not in the File types list, it is sent uncompressed; the Default profile compresses only text/plain (How is compression (GZIP / DEFLATE) enabled; which content types should be compressed?).
• Offloading: While it is on, the Backend Service always responds uncompressed; a single, consistent copy is created in the cache (What does the Offloading option in the Compression profile do?).
• Modify response content: If this action is on the same vService, responses are sent uncompressed; the cache continues to work (Can I modify the response body (e.g. inject a script into HTML, mask national ID / card numbers)?).
• Conditions: With the If the response comes from cache and If the response is compressed predefined conditions, actions can be applied separately to these responses.
• Monitoring: On the HTTP Frontend tab of the vService dashboard, the Frontend Cache and Compression graphs are monitored together; the Load Balancer Management tab shows the names of the two profiles.
• Verification: The same address is requested with curl -s -o /dev/null -D - -H "Accept-Encoding: gzip" https://www.example.com/app.css and without Accept-Encoding; both get TRCACHE: HIT, and only the first has Content-Encoding: gzip.

Common Misconceptions

• "The cache stores the compressed copy, so no processor is spent at all." Compression is done on every response; the cache only prevents going to the Backend Service.
• "A client that does not support compression gets a broken response from the cache." If the client does not support compression, the response is sent uncompressed.

How it is done in the documentation

• Compression · Operational Best Practices
• Compression · Static Content Services
• Cache · What Is the Cache Profile?

Related questions

• Can I do caching on TR7; what are the default settings?
• How is compression (GZIP / DEFLATE) enabled; which content types should be compressed?
• What does the Offloading option in the Compression profile do?