What ecommerce performance reviews often miss is the difference between what a resource contains and what the shopper actually downloads. A 300 KB JSON response may cross the network as a much smaller compressed payload—or it may arrive almost uncompressed because an API route, edge rule, MIME type, or cache variant is wrong.
Text compression is not glamorous, but it affects product HTML, theme CSS, JavaScript, search suggestions, filter responses, cart data, localization dictionaries, and SVG icons. The correct ecommerce performance analysis measures transfer size, compression coverage, origin CPU, cache behavior, and the user-visible work after decompression.
Table of contents
- Why compression needs an ecommerce operating model
- Inventory the payloads that matter
- Measure coverage and useful savings
- Choose Brotli, gzip, and compression levels deliberately
- Protect caching, APIs, and peak capacity
- A composite operator scenario
- EcomToolkit’s point of view
Why compression needs an ecommerce operating model
Browsers advertise supported encodings through Accept-Encoding; servers or CDNs can return a compressed representation and identify it with Content-Encoding. MDN’s Content-Encoding reference documents encodings such as br for Brotli and gzip.
The operational problem is coverage. Static theme assets may be compressed correctly while dynamically rendered HTML, GraphQL responses, app proxies, search APIs, or regional edge paths are not. A homepage audit can therefore pass while mobile product discovery still transfers avoidable text.
| Payload | Why it grows | Compression concern |
|---|---|---|
| HTML | personalization, app markup, product options | dynamic response may bypass edge compression |
| CSS | theme history, page builders, app styles | large shared file may hide route waste |
| JavaScript | apps, analytics, recommendations | smaller transfer does not reduce parse cost |
| JSON | variants, search, filters, localization | missing MIME coverage or oversized fields |
| SVG | icon sets and inline artwork | repetitive markup compresses well but may be duplicated |
| feeds/XML | product and integration exports | batch size and origin CPU can dominate |
Compression reduces network bytes; it does not remove unused code, database latency, JSON parsing, JavaScript execution, or oversized DOM work. Use it as one layer in the RUM-to-revenue scorecard, not as a substitute for payload reduction.
Inventory the payloads that matter
Capture a cold-cache journey across landing, collection, search, PDP, cart, and checkout entry. Repeat it for a returning visit, priority locales, logged-in state, and representative mobile networks. Export response headers and both resource size and transfer size.
For every response, record:
- URL pattern, route type, status, method, and content type.
- Uncompressed resource size and compressed transfer size.
Content-Encoding,Vary, cache status, and cache-control policy.- Origin versus edge response, region, and personalization state.
- Server timing, compression time where observable, and total response time.
- Whether the payload blocks render or a purchase-critical interaction.
Do not test only JavaScript bundles. Commerce-specific APIs can be frequent and latency-sensitive: autocomplete results, collection filters, variant availability, delivery estimates, cart mutations, and market configuration.
| Journey step | Critical text response | Failure signal |
|---|---|---|
| Landing | HTML and critical CSS/JS | large transfer before LCP |
| Search | suggestion JSON | latency rises with query breadth |
| Collection | filter and sort response | mobile data grows per interaction |
| PDP | variant and inventory JSON | selection waits on oversized state |
| Cart | cart and delivery response | repeated full-state payloads |
| Market switch | translations and price data | full locale dictionaries load globally |
Measure coverage and useful savings
Build a route-level compression scorecard. Site-wide averages hide the routes with the highest traffic or commercial value.
- Compression coverage: eligible text bytes served compressed / all eligible text bytes.
- Transfer reduction: 1 − compressed bytes / uncompressed bytes.
- Critical-path compressed bytes: text bytes transferred before the primary content or action is ready.
- API bytes per action: total response bytes for one search, filter, variant, or cart action.
- Cache variant hit rate: compressed responses served from edge cache / eligible compressed requests.
- Origin compression CPU: compute time used to encode dynamic responses.
Classify findings by action:
| Pattern | Likely cause | Correct response |
|---|---|---|
| no encoding on large JSON | MIME type or API bypass | enable at the correct proxy/edge layer |
| Brotli on static, gzip on dynamic | platform policy or CPU tradeoff | benchmark rather than forcing one rule |
| strong transfer reduction, slow interaction | parse or execution work remains | reduce fields and client work |
| cache misses by encoding | incorrect variant handling | review Vary: Accept-Encoding and CDN keys |
| tiny responses compressed dynamically | overhead exceeds benefit | set an evidence-based minimum size |
| already compressed media reprocessed | broad content-type rule | exclude unsuitable formats |
Use percentiles by region and device. A small byte saving can matter on a high-latency mobile path, while aggressive dynamic compression may cost more CPU than it saves on a fast internal API.
Choose Brotli, gzip, and compression levels deliberately
Brotli often produces smaller text representations than gzip, especially when static assets can be compressed ahead of time. Gzip remains a practical fallback and may be cheaper for dynamic responses at some settings. The choice is not simply “Brotli on.” It includes content type, response size, cacheability, compression level, CPU budget, and latency target.
For static versioned assets:
- Minify first and remove unused content.
- Generate compressed variants during build or at the CDN.
- Use content-hashed URLs and long-lived caching.
- Serve the encoding the client supports.
- Verify that deploy tooling actually uploads the compressed representation.
For dynamic HTML and JSON:
- Benchmark encoding time under realistic concurrency.
- Avoid high compression levels that increase time-to-first-byte during peaks.
- Skip very small responses where headers and CPU erase the benefit.
- Cache safe representations at the edge where personalization rules allow.
- Reduce response shape before relying on compression.
Never compress sensitive responses indiscriminately without a security review. Compression can interact with secrets and attacker-controlled input in ways that create side-channel risk. Keep secrets out of reflected responses and follow platform security guidance.
Protect caching, APIs, and peak capacity
Encoding negotiation creates variants. Caches need to understand that a Brotli response and an uncompressed response are not interchangeable. Check Vary: Accept-Encoding, CDN cache keys, origin behavior, and whether intermediate proxies normalize headers correctly.
Test these conditions:
- Browser requests
br, gzip, gzip only, and no supported compression. - Edge hit and edge miss in each priority region.
- Anonymous and personalized HTML.
- Successful, validation-error, and server-error API responses.
- Peak concurrent search or filter traffic.
- Deployment immediately after asset invalidation.
| Guardrail | Owner | Release check |
|---|---|---|
| no wrong-encoding cache responses | Platform | variant matrix passes |
| dynamic TTFB stays within budget | Backend | peak load test passes |
| search/cart APIs remain complete | Commerce engineering | schema and action tests pass |
| parsing and main-thread work do not grow | Frontend | RUM and lab checks pass |
| origin bandwidth and CPU remain stable | Infrastructure | capacity dashboard reviewed |
Compression is especially valuable during traffic peaks, but only if it reduces bandwidth without turning origin CPU into the new bottleneck. Pair the change with the CDN and origin-load resilience framework.
A composite operator scenario
Consider a composite retailer whose static storefront assets receive Brotli correctly. The team assumes compression is complete. A mobile journey audit reveals that collection filters call an app-proxy endpoint returning a large uncompressed JSON document containing unused product fields. Each filter action repeats the transfer, and the endpoint misses edge cache because responses are user-agnostic but not marked safely cacheable.
The team first reduces the response schema, then enables suitable compression at the proxy layer and tests cache behavior by encoding. It compares transfer size, TTFB, parsing time, filter response latency, origin CPU, and mobile completion. This sequence matters: compressing an unnecessarily large response would save bandwidth while preserving waste.
The finding also changes governance. New API routes must declare response schema, content type, compression owner, cache policy, expected size, and a performance budget before release.
EcomToolkit’s point of view
Text compression is infrastructure hygiene, not a one-time checkbox. The valuable question is whether every important route sends only the necessary data, with an appropriate encoding, from the right cache layer, without moving delay into CPU or parsing.
Use the network and device performance segmentation guide to find the users who benefit most. If static assets pass audits but dynamic commerce journeys remain heavy, Contact EcomToolkit for an HTML, API, cache-variant, and transfer-budget review.
