Choose the right performance question
A slow page is not automatically a compression problem. For a Hong Kong small business, the useful question is whether the server sends compressible text resources efficiently to the browsers its customers use, while preserving correct content and cache behaviour. HTML, CSS, JavaScript and many text-based API responses often contain repeated strings that compression can reduce. JPEG images, video and ZIP archives already use their own encoding and may gain little or even grow if compressed again. Before changing settings, inventory the real routes that matter: a home page, a product or service page, a checkout step, and the scripts or styles they load. Record response type, uncompressed size where available, transferred size and current content encoding. These are baseline observations from your own site, not benchmark promises from a guide.
HTTP compression applies to the representation sent across the network. It does not remove unused JavaScript, reduce an oversized photograph, repair a slow database query or guarantee a faster user interaction after the page loads. It may still be a worthwhile transfer improvement, especially for first visits on constrained connections. Separate the decision from other performance work so an improved transfer-size figure is not misreported as an improvement in every user experience measure. A practical owner can compare the same pages before and after under the same network conditions, but should also open the page and complete a real task. The final decision is whether the smaller transfer is correct, reliably negotiated and worth the server effort, not whether a compression badge appears in a dashboard.
Understand the browser-server agreement
The browser advertises supported codings in its Accept-Encoding request header. The server may choose a supported coding such as gzip or br and names the one actually applied in the Content-Encoding response header. If it sends an uncompressed representation, it should not pretend that the body is gzip. The HTTP specification defines these fields; MDN's compression guide explains the common negotiation flow. A browser capable of Brotli does not require every response to use Brotli: resource type, server configuration and CPU cost can affect the choice. Treat the browser header as a capability statement, not a command to compress every byte. Test a client that accepts gzip, another that accepts br and gzip, and a request that needs an uncompressed response where supported.
Caches need enough information to keep those variants apart. When the response representation can vary by Accept-Encoding, include an appropriate Vary: Accept-Encoding response field. Otherwise an intermediary may reuse a compressed body for a client that cannot decode it, or serve the wrong variant. The response's Content-Length, when present, describes the encoded body, so comparing it with a source file's disk size without context can mislead. The browser's developer tools usually show transferred size separately from decoded resource size; label both when reporting the result. A content encoding is different from Transfer-Encoding, which concerns HTTP message transfer at a hop. Keeping these concepts separate avoids trying to fix a missing compression setting by changing unrelated chunking behaviour.
Configure by resource and risk
Start with text responses that are large enough to benefit and are already sent over HTTPS. HTML, CSS, JavaScript, JSON and SVG are candidates when their actual payloads contain compressible text. Check the server's content-type rules because a correctly configured static asset can still leave dynamic HTML uncompressed, or the reverse. Avoid blindly compressing already-compressed media. For tiny responses, compression headers and processing can outweigh a small gain; measure the real result instead of enforcing one level everywhere. If a CDN or reverse proxy also compresses, establish which layer is responsible and inspect the final response at the public edge. Double compression or a header that describes only one of two applied layers can break decoding. Configuration belongs to the deployed path a customer actually reaches.
Be careful with responses that mix attacker-controlled and secret material. Compression can expose information in some designs when an observer can repeatedly influence part of a response and measure encoded sizes. Do not solve this by turning off compression for every public stylesheet; identify sensitive pages and review their threat model separately. Also check whether a proxy modifies ETags or other validators when it transforms a representation, and whether range requests are relevant for large assets. These are reasons to test the full delivery chain rather than copy a generic server snippet. Keep a rollback switch for the compression rule and record which routes and content types it covers. The business should be able to revert one problematic class without discarding a working improvement elsewhere.
Work through a small site test
Imagine a service business with an information page, a booking page and a downloadable brochure. The team suspects that HTML and CSS are being sent without compression. First it saves the response headers and transfer sizes for those two page types and their main CSS file from the public domain. It does the same for a brochure PDF, but does not assume that the PDF will benefit. It then enables compression for eligible text at the chosen edge and repeats the requests with controlled Accept-Encoding values. For each text response, it checks that the body can be decoded, the right Content-Type remains, Content-Encoding matches the bytes and Vary includes Accept-Encoding where representations differ. These are hypothetical acceptance steps, not measurements of a real Astera client.
Next the team opens the pages in an ordinary browser and completes a booking test. It checks that scripts execute, style sheets apply, text remains readable and the request does not show a decoding error. It repeats through the CDN's public hostname, because a local origin test cannot prove the public result. For a fair comparison, it separates transferred bytes from decoded bytes and records the same route, browser and cache state before and after. If the booking page is still slow despite smaller HTML, it inspects other causes rather than claiming compression solved the whole journey. If a response has the wrong encoding header, rollback that route immediately and correct the edge rule. The test is complete only when both transport and user task pass.
Maintain the result as the site changes
A release can quietly change compression coverage. A new frontend build may introduce a content type the rule misses; a new CDN route may bypass the old setting; a vendor may replace a text endpoint with a precompressed file. Put a small check in the release routine that samples representative public resources, inspects Accept-Encoding, Content-Encoding and Vary, and confirms that the browser decodes each body. This is more meaningful than asserting that a configuration flag is on. When collecting metrics, report the exact tested resources and period, and separate their transfer-size change from page-level or user-level outcomes. Do not turn one sample into a general performance claim for all customers, networks and devices.
Give the website owner a concise record of which layer applies compression, which content types qualify, what exclusions exist and how to reverse the change. If a customer reports a blank page after release, support needs a route to identify whether the browser received an undecodable body, a broken script, or an unrelated application fault. Compare the failed response headers and bytes with a known-good resource before changing broad settings. Review configuration whenever hosting, CDN or framework behaviour changes. The worthwhile end state is modest and precise: eligible text transfers use a coding the client accepts, caches keep variants separate, already compressed files are handled sensibly, and customers can still complete the task they came to do.
Before you proceed
- Are representative HTML, CSS, JavaScript and API responses tested at the public edge?
- Does each response use a client-supported Content-Encoding and appropriate Vary?
- Can customers still open pages and complete the relevant task after the change?
