Verify WordPress compression from the response delivered to a client, not from a plugin switch. Request an appropriate encoding, inspect the returned Content-Encoding and compare the decoded content with an uncompressed response. Record the URL and delivery path, because an origin server and a public cache can produce different results.
Compression is a delivery concern. Begin with the server or hosting team’s description of the route from WordPress to the visitor, including any reverse proxy or cache. Do not assume an instruction intended for Apache applies to a different server, or edit a shared configuration before understanding which sites it affects.
The HTTP behaviour below is grounded in MDN’s compression and Content-Encoding documentation. The original comparison worksheet is a proposed diagnostic. It is not a report of a speed improvement on Spout’s site and does not prescribe a production server change.
Where should you look before enabling another plugin?
Identify which component currently delivers the response. A WordPress page can pass through hosting software and intermediary services before reaching the browser. Record the public URL, the person responsible for the hosting configuration and any separately managed delivery service. That prevents a plugin setting from being mistaken for authority over the entire response path.
MDN’s compression guide explains the implementation boundary. HTTP compression is implemented by browsers and servers. The server still needs suitable compression configuration. Ask the responsible operator what is already enabled before introducing another mechanism that may overlap with it.
HTTP compression algorithms are negotiated between browser and server. The browser advertises supported encodings through Accept-Encoding. Your diagnostic must therefore record the request as well as the response. An uncompressed result from a request that did not offer the desired encoding is not the same observation as a server refusing an offered method.
Keep a particular resource in view. A successful test of the homepage says nothing conclusive about a separate script, stylesheet or cached article. Select representative text resources relevant to the reported issue and identify them individually. Do not turn a sample observation into a claim that every public response has been inspected.
Which response headers provide useful evidence?
MDN’s Content-Encoding reference gives the key distinction. Content-Encoding identifies the encodings applied to a resource and their order. Content-Encoding allows the recipient to decode the resource to its original format. Record the actual returned value rather than the algorithm you hoped the server would select.
A negotiated encoding requires a Vary response header containing Accept-Encoding. Inspect that relationship alongside the chosen encoding. A public cache needs to distinguish appropriate response representations; an operator should investigate a missing or unexpected Vary value in the context of the real delivery configuration rather than applying an unrelated recipe.
Content-Length ordinarily describes the encoded representation when Content-Encoding is present. Do not compare that value with a decoded browser view as if both describe the same bytes. Write down which measurement you are recording: transferred representation, decoded body or another tool’s interpretation.
Whether the server uses a requested compression method depends on its configuration and capabilities. If the requested method is absent, retain the request and response details and ask the responsible operator to explain the result. A missing header alone does not identify which component needs changing.
| Diagnostic sample | Request evidence | Response evidence | Question to resolve |
|---|---|---|---|
| Public HTML page | Offered encodings and exact URL | Encoding, Vary and decoded body | Was a suitable representation delivered? |
| Stylesheet | Same resource requested deliberately | Returned encoding and content type | Does the delivery rule cover this text resource? |
| Already compressed image | Actual image URL and format | Transferred representation | Is another compression layer useful here? |
| Cached page | Public route and cache context | Observed headers and body | Does the public result differ from the expected route? |
| Identity comparison | Encoding request recorded explicitly | Decoded content and status | Are the compared responses genuinely equivalent? |
These are proposed samples, not a universal coverage threshold. Choose resources that answer the observed problem and document why they were selected. An error page returned for a mistyped stylesheet URL should not be counted as successful compression of the intended asset.
Should you compress every kind of file again?
Compressing already compressed media can increase file size. Separate text delivery checks from image optimisation. A missing gzip response for an image is not automatically evidence of a defect. Ask what representation is being delivered and whether the proposed action addresses that representation’s actual problem.
Also separate compression from other performance questions. A compressed response may still contain unnecessary content or depend on a slow application path. This diagnostic does not establish a complete performance assessment. Describe the verified result precisely, such as the returned encoding for a particular HTML response, without promising a ranking or loading-time improvement.
Avoid making several infrastructure changes at once. If a configuration change is later authorised, retain the previous configuration and a scoped recovery plan. The acceptance exercise below reads responses; it does not authorise an edit to a production host or a restart of a shared service.
Original response-pair diagnostic worksheet
Choose a fictional support case: an article appears to be delivered without compression after a hosting change. The proposed exercise uses the affected page URL and an agreed representative stylesheet. It introduces no invented measurements. Fill in the observations only after the requests have actually been made.
For each resource, retain a request that explicitly offers the encoding under investigation and a comparison request whose encoding preference is also recorded. Save the response status and headers. Keep any automatically decoded tool output distinguishable from raw transferred bytes so the reviewer knows what was inspected.
Compare the decoded content and the resource identity. If the responses differ because the page changed, a redirect occurred or an error response was returned, explain that difference before interpreting their sizes. A smaller response is not useful evidence when it contains the wrong document.
Record the returned Content-Encoding, Vary and relevant length information with the date and delivery context. Mark each finding as observed, unexplained or unsuitable for comparison. Ask the hosting owner to identify the responsible configuration when the public result does not match the intended behaviour.
If a later change is approved, repeat the same resource checks against the agreed route and retain both results. Report what changed and what the exercise cannot establish. Do not state a percentage improvement or a site-wide success until the measurements and coverage actually support it.
For broader maintenance decisions, see WordPress and hosting. Get started with the affected URLs and recorded response headers so the issue can be scoped accurately.
By Spout Team. AI-assisted drafting by Codex using linked MDN documentation. No production server edit, performance measurement or completed site test is claimed.