Insights performance
Shopify Section Rendering API: Update Page Sections Without Full Reloads
The Shopify Section Rendering API lets a theme fetch a freshly rendered piece of a page, like the cart drawer or a filtered product grid, and swap it in without reloading the whole page, which turns a slow full navigation into a fast, targeted update.
Key takeaways
- A full page reload re-downloads assets, re-runs scripts, and repaints everything, even when only one section changed. The Section Rendering API updates just the part that changed.
- It powers the interactions shoppers use most: cart drawers, collection filtering, quick add, and predictive search results.
- Targeted updates improve Interaction to Next Paint (INP), the Core Web Vitals metric that measures how responsive your store feels.
- The win is real but not automatic. An app or theme can still fetch oversized sections or pile on client-side work that cancels out the benefit.
- Confirm the improvement the same way you confirm any speed change: measure INP before and after against your Core Web Vitals benchmarks.
What the Section Rendering API actually does
When a shopper adds an item to the cart or applies a filter, the page needs to show new content. The old way to do that was a full page reload: the browser throws away the current page and rebuilds a new one from scratch. That means downloading the HTML again, re-parsing CSS, re-running JavaScript, and repainting the entire screen, even though only the cart count or the product grid actually changed.
The Section Rendering API offers a better path. Your theme asks Shopify to render just one or more specific sections, and Shopify returns the finished HTML for those sections only. The theme then swaps that HTML into the page. Nothing else reloads. The header stays put, the scripts keep running, and the shopper sees the update almost instantly.
Mechanically, the theme makes a request to the storefront and names the sections it wants. Shopify renders those sections with fresh data (the updated cart, the filtered results) and returns them. Because the rendering happens on Shopify’s side using the same Liquid your theme already uses, the swapped-in HTML matches the rest of the page perfectly. There is no separate template to maintain.
The result is an interaction that feels like an app rather than a website. Add to cart updates the drawer in place. A filter refreshes the grid without a jarring full reload. The page feels quick because it is doing far less work.
Where it delivers the biggest wins
Not every interaction needs partial rendering, but a handful of common ones benefit enormously.
The cart drawer is the classic case. A shopper adds an item and expects the cart to update immediately. With the Section Rendering API, the theme fetches the updated cart section and slides it in. No reload, no losing your place on the page, no re-downloading the whole storefront just to show one more line item.
Collection filtering is the second big win. On a large collection, applying a filter used to reload the entire page, including the header, footer, and every script. With section rendering, only the product grid and the filter counts refresh. The shopper browses faster, and you avoid re-running heavy page scripts on every filter click.
Predictive search and quick-add interactions benefit too. Search results can update as the shopper types, and a quick-add can refresh the cart, both without a full navigation. Each of these is an interaction, and interactions are exactly what Interaction to Next Paint measures.
That connection matters. INP grades how quickly your store responds when a shopper taps or clicks. Full reloads are slow and heavy, which hurts INP. Targeted section updates are light and fast, which helps it. On mobile especially, where the rest of your speed work lives, this is one of the mobile speed fixes that shoppers actually feel.
Where it can go wrong
The Section Rendering API is a tool, not a guarantee. Used well, it is a clear win. Used carelessly, it can add its own cost.
The first pitfall is fetching too much. If a theme asks for a large, complex section on every interaction, or requests several sections when it only needs one, the response gets heavy and the update slows down. The point is to fetch the smallest section that contains what changed, not to re-render half the page over the network.
The second pitfall is stacking client-side work on top. Some apps intercept these interactions and layer their own scripts, animations, and re-processing over the swapped-in HTML. The partial render is fast, but the app then spends hundreds of milliseconds reworking it, and the shopper is back to a laggy feel. The API did its job; the app undid it.
The third is over-fetching on input. Predictive search that fires a section request on every single keystroke, without debouncing, can flood the storefront with requests. The feature feels responsive in a demo and sluggish under real typing.
The lesson is the same one that applies to every performance feature: the technique is only as good as its implementation. A theme or app that uses the Section Rendering API thoughtfully is fast. One that abuses it is not. When you scan your store with Store Auditor, you can see which apps are adding heavy interaction work, so you know whether a slow cart or filter is the theme, an app, or the section fetch itself.
How to tell if your store is using it well
You do not need to read code to judge whether partial rendering is working for you. You need to feel the interactions and then measure them.
Start with the cart. Add an item on a mobile connection. Does the drawer update in place, quickly, or does the whole page reload and jump? A smooth in-place update is the Section Rendering API doing its job. A full reload means your theme is not using it, or an app is forcing a navigation.
Do the same with filtering. Apply a filter on a large collection. A fast grid refresh is good. A slow full reload, or a fast refresh followed by a visible lag while something reprocesses, points to either an old theme pattern or a heavy app layered on top.
Then measure INP on those interactions with a real mobile profile, not just your fast desktop. If the interactions feel slow and INP is poor, work out whether the cause is the theme (not using partial rendering), an app (adding work on top), or over-fetching. For teams that want the cart, filtering, and search interactions tuned properly, Defyn builds and audits themes with the Section Rendering API used the way it is meant to be used.
Common questions
What is the Shopify Section Rendering API used for?
It is used to update part of a page without reloading the whole thing. The theme asks Shopify to render specific sections, like the cart or a filtered product grid, and Shopify returns just that HTML to swap in. The most common uses are cart drawers, collection filtering, quick add to cart, and predictive search. The benefit is speed and responsiveness: the shopper sees the change almost instantly, and the browser avoids re-downloading and re-running the entire page for a small update.
Does the Section Rendering API improve Core Web Vitals?
It can, especially Interaction to Next Paint (INP), which measures how quickly your store responds to taps and clicks. Full page reloads are heavy and slow, which hurts INP. Targeted section updates are light and fast, which helps it. The caveat is that the benefit depends on implementation. If an app layers heavy scripts on top of the fast partial render, or the theme fetches oversized sections, the responsiveness gain shrinks. Measure INP before and after to confirm the real effect on your store.
Why does my cart or filter still feel slow if my theme uses AJAX?
Because AJAX section rendering is only fast if what it fetches and what runs afterward are both light. Common causes of a slow cart or filter include fetching a large, complex section on every interaction, an app intercepting the update and reprocessing it with its own scripts, or search requests firing on every keystroke without debouncing. The network swap can be quick while the client-side work around it is slow. Isolate the cause by measuring the interaction and checking which apps are active on that part of the page.
Wrap-up
The Shopify Section Rendering API is one of the clearest performance ideas on the platform: do not rebuild the whole page when only one part changed. Used well, it makes carts, filters, and search feel instant, and it directly helps the Interaction to Next Paint score that reflects how responsive your store feels. Used carelessly, with oversized fetches or heavy app scripts layered on top, it gives back the win. The test is simple: add to cart and apply a filter on mobile, feel whether they update in place or reload, then measure INP against your Core Web Vitals benchmarks. Fast, targeted updates are within reach, as long as the apps on your store are not quietly undoing them.