JSON Data Bloat: The 11MB Payload Hidden in the DOM

Diagnosis: Excessive HTML Payload

During a performance audit of a 'Shop by [Feature]' collection page, we noticed unusually high Time to First Byte (TTFB) and parsing times. To investigate the raw document weight, we ran a curl command.

curl -sL https://site.com/collections/shop-by-feature/example-product | wc -c
# Output: 11,114,413 bytes (approx 11.1MB)

The page transfer size exceeded 11 MB of raw HTML/data. On a standard mobile 4G connection, downloading this document introduces multi-second latency before rendering can begin.

The Root Cause: The 'Variant Multiplier' Effect

The issue was not visible HTML elements, but data embedded within `data-json` attributes. The template injected full JSON objects for every product in the grid.

Critically, this included every single variant for every product. With the launch of new product series, the variant count increased, pushing the payload from an already inefficient 9.5MB to a critical 11.1MB.

The Prescribed Solution: Strict Data Scoping

We prescribed a strict data hygiene strategy for collection templates, moving from dumping full product objects to selecting only necessary keys.

1. The 'Canonical Variant' Rule

We recommended modifying the liquid template to ship only data for the canonical variant (the default displayed option). All other variant data should be excluded from the initial payload.

2. Hydration on Demand

Variant data should be fetched asynchronously only upon user interaction (e.g., 'Quick View' or size selection). This architecture reduces the initial HTML payload by over 90%, significantly improving LCP and Total Blocking Time.

{% comment %} Before: Dumping the full object {% endcomment %}
<div data-json='{{ product | json }}'></div>

{% comment %} After: Constructing a lean object {% endcomment %}
<div data-json='{ "id": {{ product.id }}, "handle": "{{ product.handle }}" }'></div>