Ignorer et passer au contenu
Shopify Liquid is a server-side templating language that runs before your page reaches the browser. Slow Liquid code adds directly to your Time to First Byte - the delay before a visitor receives even one byte of your page. Nested loops, redundant metafield lookups, and unfiltered large collections are the main culprits. Fixing them cuts TTFB, speeds up page delivery, and improves every downstream metric from LCP to bounce rate.
Why Liquid Performance Matters for Shopify Speed
Most Shopify speed guides focus entirely on the frontend: images, JavaScript, CSS. These matter. But there is a layer above all of that which determines how fast your HTML is even generated in the first place.
Liquid code runs on Shopify's servers every time a page is requested. The server reads your template files, executes the Liquid logic, queries your store data, renders the HTML, and sends it to the browser. The time this process takes is your Time to First Byte (TTFB).
A well-written Liquid template renders in 50 to 150ms. A poorly written one with deep loops, redundant queries, and complex conditional logic can take 600ms or more. That 450ms difference is paid on every single page load, by every single visitor, before the browser has received anything to show.
Google's threshold for good TTFB is under 800ms total (server time plus connection time). Shopify's own infrastructure handles the network portion efficiently. The Liquid rendering time is the variable you control.
Beyond TTFB, complex Liquid templates create larger HTML documents. A template that renders thousands of unnecessary DOM nodes slows down JavaScript execution, layout calculations, and memory usage on the client side - problems that show up in your INP score and real device performance.
Understanding How Shopify Liquid Executes
Liquid is a synchronous templating language. It executes top to bottom through your template files, rendering each tag and output in sequence. When it encounters a loop or a data lookup, it resolves that operation before moving forward.
Shopify imposes a maximum of 500 operations in a single template render. Five nested loops take roughly five times longer than one loop accessing the same data. Fetching the same metafield in a loop twelve times executes twelve separate lookups.
There is a maximum collection size for iteration. Paginating large collections is mandatory for performance. Iterating an unpaginated 500-product collection processes all 500 products, all their image lookups, and all their variant checks on every page render.
Shopify enforces timeout limits that return an error page if rendering takes too long. Understanding these limits helps you write Liquid that stays well within them rather than approaching them under high traffic conditions.
How to Reduce Loops in Shopify Liquid
Loops are the most common source of Liquid performance problems. Used correctly, they are essential. Used carelessly, they create exponential rendering overhead.
Every time you iterate over a collection, products array, or variant list, you are making multiple data accesses. A loop over 50 products costs 50 operations. A loop over 50 products with 5 operations per iteration costs 250 operations. Accomplish what you need in a single pass through the data rather than multiple passes.
Replacing multiple loops with a single loop:
<!-- Slow: two separate loops over the same collection -->
{% for product in collection.products %}
<div class="product-title">{{ product.title }}</div>
{% endfor %}
{% for product in collection.products %}
<div class="product-price">{{ product.price | money }}</div>
{% endfor %}
<!-- Fast: one loop, same result -->
{% for product in collection.products %}
<div class="product-title">{{ product.title }}</div>
<div class="product-price">{{ product.price | money }}</div>
{% endfor %}limit to constrain loop sizeWhen you only need a subset of items, use the
limit parameter instead of looping over the full collection and breaking early. A 200-product collection with an early-break condition still iterates all 200 products. Adding limit: 4 iterates exactly 4.<!-- Slow: loops all products, uses only first 4 -->
{% for product in collection.products %}
{% if forloop.index <= 4 %}{{ product.title }}{% endif %}
{% endfor %}
<!-- Fast: only loops 4 products -->
{% for product in collection.products limit: 4 %}
{{ product.title }}
{% endfor %}offset for paginated loopsFor templates showing a specific range of items, combine
limit and offset. This is more efficient than iterating the full collection and filtering by index.{% for product in collection.products limit: 8 offset: continue %}
{{ product.title }}
{% endfor %}How to Avoid Nested Logic in Liquid
Nested conditions and loops multiply rendering complexity. Each level of nesting applies to every iteration of the outer level, creating multiplication effects on rendering time.
Flatten conditional logic with early returns:
<!-- Deeply nested: hard to read, expensive to render -->
{% for product in collection.products %}
{% if product.available %}
{% if product.price < 5000 %}
{% if product.tags contains 'sale' %}
<div class="sale-product">{{ product.title }}</div>
{% endif %}
{% endif %}
{% endif %}
{% endfor %}
<!-- Flattened: same result, cleaner execution -->
{% for product in collection.products %}
{% unless product.available %}{% continue %}{% endunless %}
{% unless product.price < 5000 %}{% continue %}{% endunless %}
{% unless product.tags contains 'sale' %}{% continue %}{% endunless %}
<div class="sale-product">{{ product.title }}</div>
{% endfor %}Precompute complex conditions outside loops:
<!-- Slow: evaluates the same settings check on every iteration -->
{% for product in collection.products %}
{% if settings.show_vendor and product.vendor != blank %}
<span>{{ product.vendor }}</span>
{% endif %}
{% endfor %}
<!-- Fast: evaluate once, reference result in loop -->
{% assign show_vendor = false %}
{% if settings.show_vendor %}{% assign show_vendor = true %}{% endif %}
{% for product in collection.products %}
{% if show_vendor and product.vendor != blank %}
<span>{{ product.vendor }}</span>
{% endif %}
{% endfor %}Using Efficient Shopify Liquid Filters
When you apply the same filter chain to the same value multiple times, Liquid executes the filter each time. Cache the result in an assign variable and reference it wherever needed. This is especially impactful for image_url filters used in srcsets.
where Instead of Loop Conditions
The where filter returns a subset of an array matching a condition without writing a loop. It is optimized at the Shopify engine level and is faster than implementing the equivalent logic with loop conditions.
map to Extract Properties
When you need only one property from each item in an array, map is more efficient than looping. It accesses only the specified property rather than loading the full product object for each iteration.
<!-- Cache image_url filter results -->
{% assign img_400 = product.featured_image | image_url: width: 400, format: 'webp' %}
{% assign img_800 = product.featured_image | image_url: width: 800, format: 'webp' %}
<img src="{{ img_800 }}" srcset="{{ img_400 }} 400w, {{ img_800 }} 800w">
<!-- Use where filter instead of loop with condition -->
{% assign available_variants = product.variants | where: 'available', true %}
{% for variant in available_variants %}
<option>{{ variant.title }}</option>
{% endfor %}
<!-- Use map to extract a single property -->
{% assign product_titles = collection.products | map: 'title' %}contains on large arrays in tight loops. The contains operator searches through an array sequentially. Using it inside a loop on large arrays creates O(n2) complexity - every item in the outer loop searches the entire inner array. If you need to check membership frequently, restructure the logic to avoid repeated contains calls.Pagination vs Full Loading in Shopify
Pagination is not just a UX choice. It is a performance requirement for large collections. When a template iterates over an unpaginated collection, Liquid processes every product in that collection. A collection with 500 products means 500 iterations, 500 sets of image lookups, 500 sets of variant checks, and 500 elements rendered into the DOM.
{% paginate collection.products by 24 %}
{% for product in collection.products %}
<!-- Only processes 24 products per page -->
<div class="product-card">
<img src="{{ product.featured_image | image_url: width: 400, format: 'webp' }}"
loading="{{ forloop.index > 4 | ternary: 'lazy', 'eager' }}"
width="{{ product.featured_image.width }}"
height="{{ product.featured_image.height }}"
alt="{{ product.featured_image.alt | escape }}">
<h3>{{ product.title }}</h3>
<p>{{ product.price | money }}</p>
</div>
{% endfor %}
{{ paginate | default_pagination }}
{% endpaginate %}Good performance, reasonable browsing experience. The recommended default for most Shopify stores. Renders fast on mobile and desktop without requiring excessive navigation.
Acceptable for smaller collections. Performance cost is noticeable on mobile. Use only when the browsing experience benefit outweighs the render time cost.
Avoid unless you have specific business reasons and have measured the performance impact. The render time cost at this scale is significant and directly affects TTFB.
Optimizing Metafields in Liquid
Metafields let you attach custom data to products, collections, and other Shopify objects. They are powerful and frequently misused from a performance perspective.
product.metafields.custom.material for a single product is one lookup. Accessing it inside a loop for 24 products is 24 lookups. Accessing three metafields per product in a 24-product loop is 72 lookups in a single page render.Cache metafield values before loops:
<!-- Slow: looks up the same product metafield repeatedly -->
{% if product.metafields.custom.badge != blank %}
<span class="badge">{{ product.metafields.custom.badge }}</span>
{% endif %}
{% if product.metafields.custom.badge == 'sale' %}
<span class="sale-tag">Sale</span>
{% endif %}
<!-- Fast: one lookup, referenced twice -->
{% assign product_badge = product.metafields.custom.badge %}
{% if product_badge != blank %}
<span class="badge">{{ product_badge }}</span>
{% endif %}
{% if product_badge == 'sale' %}
<span class="sale-tag">Sale</span>
{% endif %}Avoid metafield lookups inside collection loops:
{% for product in collection.products %}
{% assign badge = product.metafields.custom.badge %}
{% assign material = product.metafields.custom.material %}
<!-- Use badge and material variables, not metafield lookups -->
{% if badge != blank %}
<span class="badge">{{ badge }}</span>
{% endif %}
{% endfor %}Reducing Server Load in Liquid Templates
A mega menu with 8 top-level items and 12 children each iterates 96 items per page render. If the menu is identical on every page, this is 96 data accesses that produce the same HTML every time. For large navigation menus, consider rendering the menu HTML once and caching it, or moving the menu rendering to a section that Shopify caches more aggressively.
Shopify renders every section included in a page template, even sections that are hidden or empty. A homepage template with 12 sections renders all 12, including sections with no content configured. Remove sections from templates when they are not in use rather than leaving them as invisible placeholders.
all_products
The all_products array provides access to any product by handle but requires a lookup across your entire product catalog. Using it once is fine. Using it inside a loop or multiple times per template creates redundant catalog queries. If you need multiple products, fetch them through a collection or explicitly through section settings.
How to Debug Liquid Code Performance
The Shopify Theme Inspector is a Chrome extension that adds a Liquid profiler to DevTools. It shows render time for every Liquid template, section, and snippet on the page, measured in milliseconds. Look for snippets taking more than 50ms to render, sections with unexpectedly high render times, and the same snippet appearing multiple times with cumulative high times. This tool directly identifies which template files contain your slowest Liquid code.
In the Network tab, click on the HTML document request for your page. In the Timing section, look at "Waiting (TTFB)." If it is above 400ms, your Liquid rendering is a primary target for optimization. Compare TTFB across different page types to identify which templates are the bottleneck.
During development on a development store, add timing markers to identify slow sections manually. Check the raw HTML source of the rendered page and correlate large HTML sections with the Liquid that generated them. Sections that produce disproportionately large HTML relative to their visible output often contain inefficient loops.
Best Practices for Liquid Code in Shopify
Write for Data Access
- Before writing a loop, ask what data you actually need
- Use
mapto extract only needed properties instead of loading full objects - Cache filter results in
assignvariables when used more than once - Precompute conditions outside loops when they do not change per iteration
Test Realistically
- Liquid performance scales with data size
- A template fast on a 10-product dev store may be slow on a 500-product live store
- Test Liquid changes with a realistic product count
- Use Shopify Theme Inspector before and after every optimization
Use the Right Tool
- Use Liquid for template rendering and data access
- Use JavaScript for dynamic behavior
- Use CSS for layout
- Avoid complex string parsing and data transformation in Liquid
- Keep snippets focused on a single rendering task
Testing Liquid Optimization Results
Use WebPageTest.org to measure TTFB precisely. Run 3 tests before any Liquid changes, record the average. Make your changes, wait for Shopify's cache to clear (15 to 30 minutes), run 3 tests again. A meaningful Liquid optimization produces a TTFB reduction of 50 to 200ms on pages with complex templates.
PageSpeed Insights flags TTFB above 600ms in its "Reduce initial server response time" diagnostic. After optimizing heavy Liquid templates, this diagnostic should show improvement or disappear from the Opportunities section.
Run the Theme Inspector before and after optimizations. The per-template and per-snippet timing numbers should decrease for the files you modified. A snippet that took 85ms to render should drop to 20 to 30ms after removing inefficient loops and metafield lookups.
LCP improvements from TTFB reduction show up in Google Search Console's Core Web Vitals report after 28 days of new data collection. Lower TTFB means the browser starts downloading the LCP image sooner, which reduces total LCP time even if the image itself has not changed.
Summary
Liquid performance is the foundation that every other Shopify optimization builds on. A slow Liquid template adds TTFB that no amount of image compression or JavaScript deferral can remove - it is paid before the browser receives anything.
continue for early exits; use where and map filters instead of loop-based filtering; paginate large collections to cap rendering work per page; cache metafield lookups in variables, especially inside loops; use the Shopify Theme Inspector to identify exactly which templates are slow before optimizing anything.For stores with well-optimized images, JavaScript, and CSS already in place, Liquid optimization is often the remaining lever for meaningful TTFB improvement. Tools like Ecom: Page Speed Expert address the frontend optimization layer - but server-side Liquid performance is the foundation that makes every frontend improvement more effective. Get the server fast first. The browser does the rest faster.
