Shopify speeds up Liquid storefronts: pages now start loading up to 29% faster

The speed of an online store does not depend solely on the amount of code, images or apps it uses. It also depends on how quickly the server can start delivering a page to the browser. In September 2026, Shopify announced an important infrastructure change for Liquid storefronts: HTML can now start reaching the browser before the entire template has finished rendering.

According to data published by Shopify, this change reduced Time to First Byte (TTFB) by approximately 29% at p75 for the median store, while the improvement at p90 was around 21%. Shopify also reported improvements of between 2% and 6% for First Contentful Paint (FCP) and Largest Contentful Paint (LCP).

For Shopify merchants, there is another particularly important advantage: the improvement has been introduced at platform level and, for eligible pages, requires no changes from merchants to start benefiting from the new mechanism. However, the structure of each theme still plays a significant role in determining how much faster the storefront actually feels to shoppers.

What has changed in the way Shopify storefronts load?

Traditionally, when a Liquid page was requested, Shopify had to render the document before the browser could begin working with important elements of the response. This meant that resources required to display the page, such as stylesheets or fonts, could remain undiscovered by the browser while the server was still processing the template.

With the new approach, Shopify renders the layout content up to {{ content_for_header }} and flushes that first part to the browser as soon as possible. The remaining HTML then follows through the same response stream once the template has finished rendering.

In practical terms, the server and browser can now work more effectively in parallel. While Shopify continues processing the template, the browser can already parse the first part of the document, establish connections and start downloading resources it has discovered.

Importantly, this does not mean that the final HTML document is different. When the streamed sections are combined, the resulting document is the same as before. What changes is when the browser starts receiving and processing useful information.

Why can streaming improve the customer experience?

In e-commerce, every period of waiting can influence the perceived quality of the experience. When the browser receives references to CSS, fonts and other first-paint resources earlier, it can begin processing them before the server has completed the rest of the page.

This is why improvements to TTFB should be considered alongside visual performance metrics. FCP indicates when the visitor starts seeing content, while LCP measures when one of the largest visible content elements is rendered.

Shopify reported more modest improvements for these two metrics, between 2% and 6%, but these are precisely the changes that can influence what shoppers actually experience. A faster server response is useful, but what ultimately matters to a customer is how quickly they can see and interact with the storefront.

Not every Shopify page is eligible yet

The implementation does not yet cover every page or theme configuration. According to Shopify's technical documentation, a page can use streamed HTML when it is rendered from a JSON template and when {{ content_for_header }} appears as a plain output tag inside the head.

There are therefore several situations where streaming does not currently apply:

• Pages rendered from .liquid templates rather than JSON templates.

• Implementations where {{ content_for_header }} uses filters or is placed inside conditional or capture blocks.

• Cases where {{ content_for_header }} is located inside a snippet or assigned to a variable first.

• Theme previews, the preview bar and the theme editor.

This also means that developers who want to evaluate the real impact of the change should test the live storefront theme rather than relying exclusively on the theme editor or preview environment.

Theme architecture still makes a difference

One of the most interesting aspects of this change is that two eligible Shopify stores can achieve different improvements in visual performance even if both experience a similar reduction in TTFB.

The reason lies in the position of critical resources relative to {{ content_for_header }}. The browser can only download resources it already knows about. If the main stylesheet is declared after this tag, its reference will arrive with the second part of the streamed response.

If, on the other hand, resources required for the first paint are correctly declared before {{ content_for_header }}, the browser can begin downloading them while Shopify is still rendering the rest of the template.

Shopify demonstrated this difference using its Dawn and Horizon themes. During the rollout, both achieved broadly similar TTFB improvements, but Horizon converted the infrastructure improvement into greater gains for FCP and LCP because more of its render-blocking resources were already available to the browser while the template was still being processed.

Should developers simply move everything above content_for_header?

No. Performance optimisation needs to account for dependencies within the theme. Moving resources indiscriminately can introduce unexpected problems.

For example, inline scripts placed before certain Shopify variables become available may fail. Changing the position of a stylesheet can also affect CSS specificity when its rules compete with styles injected by Shopify.

The appropriate approach is to identify which resources are genuinely critical to the first paint, understand their dependencies and then optimise their position within the document.

This is a good example of how Shopify performance is created through a combination of platform-level improvements and theme-level engineering decisions. For businesses with more sophisticated requirements, a well-planned Shopify Plus development strategy should consider these performance decisions from the architecture stage onwards.

Streaming does not remove the need to optimise Liquid

There is another important distinction to understand: the new mechanism changes when HTML starts reaching the browser, but it does not eliminate the processing work that the server needs to perform.

A template containing expensive Liquid operations still requires processing time. Complex loops, unnecessary render calls and inefficient structures do not disappear simply because the first part of the document can be delivered earlier.

Liquid performance best practices therefore remain highly relevant. The objective should be to work on two fronts: enable the browser to start useful work as early as possible while also reducing the total amount of time required to generate the complete response.

The same principle applies when above-the-fold content depends on an external API requested through JavaScript. Starting critical requests earlier can allow them to overlap with template rendering instead of creating another sequential period of waiting.

TTFB now requires more careful interpretation

The introduction of streamed HTML also creates an interesting measurement challenge. For many years, TTFB has been used as an approximate indicator of how long a server takes to begin responding. Technologies such as Early Hints and now streamed responses make that interpretation less straightforward.

With streaming, the first byte can arrive significantly earlier while the server continues processing the rest of the document. Consequently, a 29% reduction in TTFB does not necessarily mean that the complete server-side rendering process has become 29% faster.

For analysing Liquid processing, Shopify recommends tools such as Theme Inspector for Chrome. Another possible measurement is the interval between finalResponseHeadersStart and responseEnd, although this remains influenced by network conditions and the user's device.

The change reinforces an important principle of web performance analysis: no single metric should be interpreted in isolation. TTFB, FCP, LCP and total rendering time each answer different questions about the loading process.

What should you analyse on a Shopify store?

Automatic infrastructure improvements provide an excellent foundation, but they are not a replacement for technical analysis. To understand whether a Shopify project is taking full advantage of the platform's current capabilities, it is worth checking:

1. Whether important storefront pages use JSON templates that are eligible for streaming.

2. Where {{ content_for_header }} is positioned within the layout.

3. Which stylesheets, fonts and other critical resources are declared before and after it.

4. Whether scripts depend on Shopify objects or variables that are only available later.

5. How much processing time is still being consumed by Liquid.

6. Whether above-the-fold content depends on external requests that begin too late.

7. How FCP and LCP perform under realistic user conditions rather than in a single isolated test.

A broader technical SEO analysis can also help identify performance, architecture and implementation issues that may affect user experience as well as a store's ability to compete in organic search.

Performance remains a shared responsibility

This update demonstrates one of the advantages of building on an e-commerce platform capable of deploying infrastructure improvements at scale. A change introduced by Shopify can generate performance gains across a large number of stores without requiring every merchant to modify their code individually.

At the same time, it demonstrates the limits of that advantage. Shopify can deliver the first part of the HTML sooner, but it cannot automatically turn a poorly structured theme into a high-performance storefront.

Resource ordering, Liquid quality, installed apps, JavaScript, third-party integrations, images and overall theme architecture all continue to influence the final experience.

For stores with substantial traffic or more complex e-commerce operations, small improvements can accumulate into meaningful performance gains. Performance should therefore be treated as a continuous process of measurement, development and optimisation rather than as a one-off task completed when a website is launched.

A faster Shopify store starts before the first byte

Shopify's streamed HTML architecture allows the browser to begin useful work while the server is still processing other parts of the page. It is an infrastructure change that may be largely invisible to merchants and shoppers, but it can reduce periods in which the browser would otherwise simply be waiting.

The next step is ensuring that the theme can make effective use of that advantage. Positioning critical resources correctly, reducing unnecessary Liquid processing and measuring metrics that reflect the real customer experience are now even more important.

For businesses using Shopify as a strategic sales channel, an effective digital transformation strategy should consider performance, technology, user experience, SEO and conversion as interconnected parts of the same system. Faster infrastructure creates an opportunity - the quality of the theme and its implementation determines how much of that opportunity becomes a genuinely faster shopping experience.