Shopify server response time: when the problem is your Liquid

Every other performance metric is capped by this one. If Shopify takes 1.5 seconds to render your HTML, nothing you do to images or JavaScript brings LCP under 2.5.

Shopify's infrastructure is fast. When server response is slow, it's the theme.

Measuring it

DevTools → Network, click the document request, look at Waiting (TTFB). That's how long Shopify took to render the page.

• Under 400ms — fine.
• 400–800ms — worth looking at.
• Over 800ms — the theme is doing too much.

Test the pages most likely to suffer: the largest collection, a product with many variants, the homepage with all its sections. Load each a few times to rule out cold caches.

The causes, in order

1. Unbounded loops

The classic. Iterating a large collection without a limit:

``liquid {% for product in collection.products %} {# 2,000 products #} ``

Always bound it, and always paginate collection pages:

``liquid {% paginate collection.products by 24 %} ``

2. Nested loops

The expensive version. Looping variants inside a product loop turns 2,000 iterations into 20,000:

``liquid {% for product in collection.products %} {% for variant in product.variants %} {# don't #} ``

If you need variant data in a grid — a price range, a colour swatch list — get it from the product object's own properties rather than iterating, or precompute it into a metafield.

3. Repeated expensive lookups

Fetching the same collection, metafield or setting inside a loop redoes the work every iteration. Assign it once, outside:

``liquid {% assign badge = settings.badge_text %} {% for product in collection.products limit: 24 %} {{ badge }} {% endfor %} ``

4. all_products and large lookups

Reaching for the whole catalogue in a template is almost always a modelling mistake. Use an automated collection and let Shopify do the filtering.

5. Array filters on large sets

where, sort and map over a big collection do the work in the template on every render. Filter at the data level instead.

6. Too many sections

Every section rendering on every page load adds time. A homepage with fourteen sections, several looping products, is slow by construction — homepage structure.

7. App blocks

Apps render server-side too. An app block doing its own lookups adds to your TTFB, and it's invisible unless you look.

Profiling

Shopify doesn't give you a Liquid profiler in the admin, so the practical approach is bisection:

1. Duplicate the theme.
2. Comment out half the sections on the slow template. Measure.
3. Narrow down to the section that's costing you.
4. Inside it, narrow to the loop.

Crude and effective. Usually one section is responsible for most of it.

Run shopify theme check as well — it flags several of the patterns above automatically, and it belongs in CI: Theme Check.

What doesn't help

• Front-end optimisation. Deferring scripts doesn't change how long the server took.
• A CDN. Shopify already serves through one; the delay is in generating the HTML.
• A "speed optimisation" app. Most work on the front end. None make your Liquid cheaper.

When it's genuinely not the theme

Two cases:

• A very large catalogue with complex filtering. At some point you're asking a lot per request, and the answer may be simplifying the template rather than optimising it.
• You've concluded you need to own rendering. That's the headless conversation, and it's a big one — Storefront API vs Liquid.

Both are rarer than people assume. Nine times out of ten it's a nested loop in one section.

TTFB is the ceiling on every other metric. Find the loop, bound it, and everything downstream gets easier.