Cart drawer refresh swaps one section in 180ms instead of reloading the full PDP at 1.2s.
Filtered collection grids return only the product list, cutting payload from 340KB to 42KB on scroll.
Variant-aware recommendations re-render with section_id when a swatch changes, no full PDP reload.
Geo-aware shipping banners hydrate per visitor without busting the page cache or shipping a heavy script.
Inline quick-add modals fetch the variant picker section on demand, saving 280KB on collection pages.
A/B test bucket assignment renders the right section variant server-side, no flicker, no tag manager.
I rebuilt six Shopify storefronts in the past year, and the same trick keeps showing up in my notes: the Section Rendering API. It is the single fastest way to make a Liquid theme feel like a SPA without shipping a SPA. Here are the six patterns I keep coming back to, with real TTFB numbers from production stores I work on.
Pattern 1: Cart Drawer Refresh Without a Page Reload
Default Dawn cart drawers refetch /cart.js and then re-render with client-side templates. That is fine until your cart line item template grows: discount badges, subscription frequency, gift wrap toggles. I had one PDP shipping 47KB of cart-line JS just to keep the drawer in sync.
Section Rendering API kills that. After POST /cart/add.js, I fire one extra request:
const r = await fetch('/?section_id=cart-drawer');
const html = await r.text();
document.querySelector('#cart-drawer').innerHTML = html;
Shopify renders the cart-drawer.liquid section server-side and returns plain HTML. No JSON parsing, no template engine, no drift between Liquid and JS. The section sees the freshly updated cart object on the same request because Shopify renders sections after cart mutations are persisted.
Numbers from a Dawn fork I instrumented in March: cart-add round-trip dropped from 1.21s to 380ms. TTFB on the section call sat at 142ms p50, 220ms p95. The HTML payload was 8.4KB gzipped vs the 47KB of JS the drawer used to pull. I also stopped seeing the half-second flash where the price would update before the discount line did, because both render in one Liquid pass.
One gotcha: the section must be added under {% sections %} in the layout, or wrapped in a section group, otherwise /?section_id= returns 404.
Pattern 2: Filtered Collection Grids on Scroll
Collection page filters are the worst offender for full-page reloads. A shopper picks "size: M" and the entire 1.4MB page reloads, including the navigation, footer, hero, and tracking pixels. On a Berlin coffee shop client, average filter-change-to-paint was 2.8 seconds.
I swapped that for one Section Rendering API call:
const url = `/collections/all?filter.v.option.size=M§ion_id=collection-grid`;
const html = await fetch(url).then(r => r.text());
document.querySelector('#grid').innerHTML = html;
history.pushState({}, '', url.replace('§ion_id=collection-grid', ''));
The section_id param works on any URL that would normally render that section. Shopify applies the filter, sorts, and pagination logic on the server, then returns just the grid markup.
Bytes on the wire dropped from 340KB gzipped to 42KB. TTFB went from 1.1s to 280ms p50. I kept the URL in sync with history.pushState so back-button and share links still work. Pagination uses the same trick: ?page=2§ion_id=collection-grid. The section receives the paginated collection.products automatically because section rendering respects all the same query params the full page would.
For infinite scroll, I attach an IntersectionObserver to the last product card and prefetch page N+1 when it enters viewport. The observer-triggered fetch averages 220ms, which means by the time the shopper scrolls to the bottom, the next 24 products are already in the DOM.
Pattern 3: Variant-Aware Product Recommendations
Most "you might also like" blocks are static per product. Mine are not. When a shopper picks the black variant of a hoodie, I want the recommendations to show black-leaning items. Doing this client-side means shipping the entire product catalog metadata.
Server-side via Section Rendering API:
picker.addEventListener('change', async (e) => {
const variantId = e.target.value;
const r = await fetch(`/products/${handle}?variant=${variantId}§ion_id=product-recommendations`);
document.querySelector('#recs').innerHTML = await r.text();
});
The recommendations section uses Shopify's recommendations.products object, which is variant-aware when you pass ?variant=. The Liquid section can also read product.selected_variant and adjust the algorithm prompt or fallback list.
On a fashion store with 2,400 SKUs, this took the variant-change-to-recs-update path from 940ms (full PDP reload via form submit) to 310ms. Payload was 14KB. I also moved the "complete the look" block to the same call, so two recommendation rails update in a single round trip.
A subtle win: because Shopify caches section rendering responses with the same edge logic as the full page, the second variant pick on the same product is often served from cache at 60ms.
Pattern 4: Geo-Aware Shipping Banner
"Free shipping over 50 EUR to Germany" is a great conversion line, but it is wrong for half my visitors. Personalizing it client-side means a flash of the wrong banner, then a swap. Shoppers notice.
I use Shopify's localization object plus a section-rendered banner:
{% if localization.country.iso_code == 'DE' %}
Free shipping over 50 EUR
{% elsif localization.country.iso_code == 'AT' %}
Free shipping over 60 EUR
{% else %}
Calculated shipping at checkout
{% endif %}
The page itself ships with a placeholder `
. On DOMContentLoaded, I fire /?section_id=ship-banner`. Shopify's edge resolves geo from the visitor IP, picks the right Liquid branch, and returns 280 bytes of HTML.
TTFB on this call is 90ms p50 because the section is tiny and edge-cached per country. The full page stays in the shared CDN cache, which is the part that matters: I am not busting page cache for personalization. That alone moved my collection page cache hit rate from 41% to 88%.
I tried doing this with a third-party geo-IP script first. It was 38KB and added 240ms to LCP. The Section Rendering approach is 0KB of script and 90ms of network, parallel to other resources.
Pattern 5: Inline Quick-Add Modal
Quick-add buttons on collection pages either ship every variant picker for every product (bloat) or pop a modal that fetches /products/handle.js and rebuilds the picker in JS (drift). Both are bad.
Section Rendering wins again:
button.addEventListener('click', async () => {
const r = await fetch(`/products/${handle}?section_id=quick-add-modal`);
modal.innerHTML = await r.text();
modal.showModal();
});
The quick-add-modal.liquid section renders the variant picker, price, stock status, and add-to-cart form using the exact same Liquid as the PDP. No template duplication, no drift when I add a new metafield to the picker.
On a 48-product collection page, this saved 280KB of upfront HTML by removing per-card variant pickers. First quick-add click costs 240ms (network plus render), every subsequent click on the same product is 50ms from edge cache. I preload the section on mouseenter of the button, which makes the click feel instant for desktop users.
The modal also gets fresh inventory on every open, which matters during flash sales. Static pickers go stale within minutes.
Pattern 6: A/B Test Without a Tag Manager
Client-side A/B tests cause flicker, hurt LCP, and require GTM. I run mine server-side using a section per variant and a single cookie.
{% assign bucket = request.cookies['ab_hero'] | default: 'a' %}
{% if bucket == 'b' %}
{% section 'hero-variant-b' %}
{% else %}
{% section 'hero-variant-a' %}
{% endif %}
Bucket assignment happens in a tiny edge function that sets the cookie on first visit. The page itself is cached per bucket, so both variants stay fast. When I want to update only the hero (e.g., swap headline copy without invalidating the whole page), I use the Section Rendering API to refetch just the hero section after a cookie change.
For analytics, the hero section emits a data attribute (data-ab-bucket="b") that my one-line tracking script reads on load and sends to my analytics endpoint. No GTM, no Optimizely, no flicker. LCP on the hero stayed at 1.1s in both buckets vs the 1.9s I was seeing with client-side Optimize back in 2023.
Across 14 tests in the past six months, this setup gave me cleaner data than my old GTM stack because there is no exposure-event race condition. The bucket is the rendered HTML.
Bottom Line
The Section Rendering API is the most underused tool in the Shopify ecosystem. It turns Liquid into a hot-swappable component system without forcing you into Hydrogen, React, or a headless rebuild. Six patterns, six measurable wins, all shipping today on stores I maintain.
If you are a Shopify developer still doing full-page reloads for filters, variant changes, or cart updates, you are leaving 60-80% of your TTFB on the table. The pattern is always the same: keep the page cacheable, render the dynamic piece on demand, swap the HTML in.
I document every storefront experiment that beats my baseline in the RAXXO Lab. If you want the section files I use as starting points for the cart drawer and quick-add modal, they live in the lab archive. Pull them, fork them, ship faster.
Next storefront you build, try one pattern. Measure TTFB before and after. The numbers will sell the rest.
Top comments (0)