Headless Shopify rendering methods

Headless Shopify storefronts can be rendered using different approaches, or combine several rendering techniques to deliver a best-fit experience that leaves users satisfied.

Each method of rendering brings its own benefits and potential drawbacks.

Determining the most appropriate rendering method for your Headless Shopify website or application depends on what your build aims to achieve.

If your goal is speed:

Static rendering is the go-to when site speed is one of your organisation’s key concerns. Since static builds don’t require a server in order to render a page, simply serving them (and all their resources) from a CDN will result in snappier page speeds when compared to server-side rendering. With server-side rendering, you’d need a response from both Shopify and the build’s own server (usually Node.js-based) before a meaningful response can be returned to the client, for any given page. In a static build however, all of the site’s assets and data are hosted on the CDN—so there’s no waiting around for any queries.

However, if freshness of data is also a concern, you can achieve the best of both worlds with incremental rehydration of the cache through mechanisms such as NextJS's incremental static regeneration. This kind of passive cache rehydration aims to re-fetch page data and assemble an updated version of the page after a user visits it, rather than before. While it may seem backwards, this approach means that subsequent users to the page see a more recent version, without sacrificing the time it takes for the initial/current user to download the page. Think of it like passing a baton—the next person in the chain sees a fresher version of the page thanks to the previous user’s earlier request.

With this approach, page speed doesn’t have to be sacrificed.

If your goal is to limit resource usage:

There will be a fine line to tread if the aim of your build is to minimize resource usage, because what this means for one store isn’t necessarily going to apply for another.

There isn’t much to worry about in respect to Shopify API resource usage, due to Shopify’s generosity of query resources. However, many headless stacks — and particularly if implemented using a highly composable approach — utilize a variety of technologies which may not be so generous in terms of resource usage.

For instance, a Headless CMS will require its own set of resources, and the same for any other microservices besides. Build minutes can add up particularly for static builds which are rebuilt on a very frequent basis, especially if the build process isn’t optimized. These additional considerations mean that it will be key for your team to first identify what the goals are in terms of limiting resource usage and then architecting the stack and determining a best fit rendering method in response.

We're the experts in Headless Shopify.

Your search for answers ends here. Discover our services.

Explore Headless Shopify Services

If your goal is consistently fresh content:

There’s no better way to ensure that the headless storefront is delivering consistently fresh, current content than through server-side rendering. With SSR, users will always see the freshest version of the store’s content, because pages will be re-rendered on each page request.

Headless Shopify builds that use SSR might be perceived as slower to end-users, because their browser needs to receive a full response from the server before it renders any given page. For example, if a Collection page sources data from both a Headless CMS and also from Shopify via GraphQL, both the CMS and Shopify need to respond before the page can be rendered server-side and downloaded by the client. There are some techniques that can be used to improve this, such as selective streaming of certain portions of the page, or through a hybrid rendering approach that uses static rendering for infrequently changed content, with server-side rendering  employed primarily to ensure freshness of other types of time-sensitive content.

Suspenseful loading (or lazy loading) of certain page components can help to improve performance for pages with large amounts of data or intensive queries, where only parts of the page are rendered server-side, with others rendering on the client-side; as individual parts of the page are requested by the client. A common way to do this is to lazy-load on scroll events, such as when the user reaches certain waypoints throughout the page.

If you value fresh content but not at the expense of site performance, consider deferred cache rehydration, by implementing techniques such as Next’s Incremental Static Regeneration. 

If your goal is SEO performance:

Headless shopify builds have a wealth of technical tooling at the disposal to deliver storefronts that are technically better-positioned for optional SEO performance, such as highly-relevant URL structures, faster load times, and greater accessibility to programmatic techniques.

Avoid client-side rendering if your headless Shopify storefront aims to perform well at SEO.

While popular search engines claim that content rendered on the client-side can still be indexed, there are plenty of case studies which show differences in how CSR content is crawled and indexed.

As of today, we’re potentially still a few years away from equal indexation of CSR content.  

If SEO performance is one of your KPIs, opt for a headless implementation that uses either static site generation, server side rendering, or incremental cache rehydration. Going static is a sure-fire way to ensure that all site pages are available ahead of time, reducing the potential for latency while busting the risk of an unavailable server upon a search engine’s next crawl. 

If your goal is to ensure optimal security:

There really isn't much to worry about in the way of security for a Headless Shopify build that has been implemented conscientiously. However, vulnerabilities can and do happen (it's just the nature of software) – the potential grows with each additional element/microservice/application/database that has been introduced into the stack. The potential issues here could range from JS & frontend-framework vulnerabilities to an exploit that affects your Headless CMS or the database where it's hosted. With headless builds, the risk is substantially reduced the further you lean into static rendering, coupled with strict secrecy of API keys and tokens.

If your goal is interactivity:

Users cherish experiences that respond dynamically to their interactions in realtime. For certain verticals, deep interactivity is not only expected, but necessary.

Your main rendering method doesn’t have to impact storefront interactivity, but client-side augmentation of the experience will of course be necessary on order to deliver interactivity such as state-based logic and contextual component rendering. In these scenarios, a hybrid model whereby pages are generated either statically at build time, or indeed as a user requests them (server-side), coupled with client-side interactivity, can achieve both performant pages that are capable of adapting to user interaction or behavior.

It’s worth mentioning that no matter which primary rendering method you use, most headless Shopify stores will require a server to make secure, live requests to Shopify at certain points during the user journey. Even a static storefront will need to exchange data with Shopify in realtime for actions such as checkout initiation, customer authentication, or general authenticated requests that may form part of a user’s post-checkout experience, such as retrieving order history, account settings, and billing address pages. 

If your goal is user experience:

Positioning yourself to deliver peak user experience is tricky, because you first have to identify what your users value more: freshness or site speed. These are the two primary factors within the scope of rendering methods that can impact user experience.

Informal chat? Works for us. 🤘

Contact Cocoon for a no-cost, no-obligation consultation.

Let's talk Shopify

Beyond this, user experience won’t be affected so much by your chosen rendering mode. Some real-time queries & mutations are always going to be necessary, as discussed above, in order to create a checkout or retrieve user-specific (authenticated) data. For UX-related implementations beyond this, client-side state/context management coupled with conditional rendering will go a long way – when layered atop of the primary rendering method, whatever that is.

A note on employee experience (EX):

However, employee experience (EX) definitely can be affected by the chosen rendering method for your Headless Shopify build.

Many content editors and marketers prefer the ability to visualize the content they’re creating, whether that’s a new collection, landing page, or updates to the homepage. 

If your headless Shopify implementation doesn’t use a visual editing interface or provide a pre-publication preview, this can create a level of perceived disconnect between the data source(s) (Shopify, Headless CMS, etc) and the storefront for those responsible for adding and updating content.

If pages are quick to update, this isn’t a big deal.

But if you also rely heavily on static rendering, it could mean that your content team has to wait around before they’re able to see how the new content looks, and whether they approve.

This can create a back and forth that could potentially feel frustrating. 

However — builds that render on the server, or hybrid builds such as provided by deferred or incremental static rehydration, are far easier for content teams to gel with in this respect. 

In our experience, the ability to edit and preview content updates visually is a huge motivator for editorial & marketing teams, and this is something that should probably be factored into your tech and implementation approach. When planning out your headless implementation & its rendering methods, consider ensuring ease-of-use, a minimal learning curve, and intuitiveness of content management for internal teams. This will ensure maximum ongoing impact for on-site product and content-related efforts, providing them with a strong sense of control.