Are headless Shopify stores static? Can it be non-static?

You might have heard the term "static site generation" when discussing or reading about Shopify Headless.

First, it's important to understand the concept of rendering approaches. With modern Javascript frameworks, there are a number of ways in which a page can be rendered, and thus served to the end-user. Static Site Generation (commonly abbreviated to SSG amongst JS developers) is one popular rendering method used for headless Shopify stores, and comes with significant performance advantages and resource optimization benefits.

What are the different rendering methods for Headless Shopify?

First, you should be aware that static site generation is not the only rendering approach. Any of the following rendering approaches can be used with Headless Shopify:

• Static Site Generation (SSG)
• Server side rendering (SSR)
• Client side rendering (CSR)
• Hybrid rendering 
• Incremental static regeneration (ISR) / Deferred static generation (DSG)

Static Site Generation

Static Site Generation is where pages of the headless storefront are "prerendered", i.e. created and assembled before a user requests them. With SSG, a "build process" will occur for the headless Shopify storefront, where all relevant pages are pre-rendered (AKA created and assembled ahead-of-time), and then pushed (we refer to this as "deployment") to a content delivery network (CDN).

This approach is fast. Users are essentially requesting a static page from an edge point that is relatively close to them, resulting in what should be blazing-fast response times. The user's browser essentially requests a static HTML page, which may or may not be augmented and hydrated with interactive functionality powered by Javascript, rather than querying a backend (Shopify). So, SSG tends to be the de facto approach where performance is a key consideration, if not the primary goal. 

What are the benefits of SSG for Headless Shopify stores?

1. Performance: Static site generation can provide significant performance gains in contrast with other rendering approaches. With a static Shopify storefront, the website won’t need to query the Shopify APIs every time a user loads a page: instead, the pages are prebuilt ahead of time and cached on an edge server. An edge node is basically a server that is close in proximity to the user who’s requesting the page, which acts as an additional point of potential performance improvement. 
2. Security: Because static Shopify sites make API requests at build time (as opposed to runtime), your headless storefront won’t be making copious API calls while customers browse around the site. This means that your server (where you’ll be sending requests to Shopify’s APIs, or querying your headless cms) will be less exposed to prying eyes. The fewer API requests you make from the frontend, the more secure the implementation.
3. SEO friendliness: Search engines love static sites, because they’re generally more performant, contain fewer frills, and return everything there is to see up-front. Static Shopify sites are therefore, inherently easier for search engines to crawl.
4. Ability to selectively augment with dynamic content: Static Shopify sites can be selectively augmented to provide dynamic content only where required.
5. Lower cost: Shopify sites built with SSG are cheaper to run as they can be hosted on a CDN with infrequent backend requests or extensive runtime querying. This is especially true for high traffic Shopify stores. 
6. Limited resource usage: Sourcing data at build time restricts heavy querying to the build environment and therefore (heavily) reduces or eliminates runtime and client side querying unless selectively augmented.

Hybrid Rendering

With modern JS frameworks, it's also possible to mix multiple rendering modes, selecting the most appropriate based on the content type. With this in mind, the storefront might simultaneously serve pre-rendered pages amongst pages which are assembled in "real-time", otherwise known as server-side rendering. A common approach is to statically-generate (or pre-render) front-facing pages, and opt for server-side generation for account-based pages, for authenticated users, or where dynamic content or real-time updates are necessary.

We're the experts in Headless Shopify.

Your search for answers ends here. Discover our services.

Explore Headless Shopify Services

Our headless shopify builds mostly use a hybrid rendering approach, because while there’s a lot of content that can benefit from static site generation, there is equally a lot of content that you’ll want to remain fresh and essentially “live”. For stores which track inventory, dynamic stock checks are critically important to prevent poor user experience or over-selling of out-of-stock product.

Depending on your desired storefront experience you may also want to display dynamic stock levels or low stock indicators, which should again utilize dynamic data which is fetched on a moment-in-time basis as the user interacts with the page. Statically building this data into an SSG frontend would be a big user experience mistake, as users would see stale information.

Still, you can’t fault static site generation for its performance benefit, user experience improvement (due to site speed), and low cost of maintenance (minimal dynamic querying). That’s why we tend to prefer a hybrid approach with our headless shopify stores, as this way you have the best of both worlds.

Incremental static regeneration (ISR) / Deferred static generation (DSG) / Cache Rehydration

Incremental static generation (as Next calls it, also known as deferred static generation in some circles, or more broadly just "cache rehydration") is a really good option to alleviate some of the challenges with static site generation. It allows your storefront to be statically generated whilst allowing the build to be incrementally updated as content changes in Shopify or you’re headless CMS. 

Think of your static site as a cached version of the store. When a user requests a particular page, the cached version is served to them to reduce latency and ensure good experience. 

However, after the page has loaded, the build refetches the data that’s used to build the page, to check whether there have been any updates to its content. This happens via an API request. If there has been an update, the static version of the page is rebuilt, and pushed to the CDN or host that serves the deployment. This way, the next user who requests this page will see the updated version, rather than the previously cached version. Now, the updated page is cached and served instead.

This approach works well to alleviate the necessity of rebuilding the site on each change to content. However, it’s more expensive as it’ll require the invocation of a serverless function on every page route for which it applies. This can be mitigated by setting up the headless frontend to observe a max rate of regeneration, usually set on a time basis. 

For example you might enforce a limit of 10 minutes, or even 24 hours. This ensures that no matter how many times an individual page is requested, it’ll only be rebuilt if at least that amount of time has elapsed since the page was last rebuilt. This approach lowers costs due to reduced function invocation and fewer API calls , while simultaneously ensuring that pages are fresh “enough”, as determined by what makes most sense for your storefront and user expectations.

Client-side rendering

Pure client-side rendering of a headless Shopify storefront is not the correct approach if the storefront intends to serve as a website. Websites need to be crawlable to search engines and pages need to be linkable for sharing purposes. Client side rendering infringes on this to a certain degree, possibly less now than in the past, but enough that we wouldn’t recommend it. Client side rendering with headless Shopify can, however, work fine for apps or other app-like experiences, where priority is placed on user experience rather than organic discovery.

Informal chat? Works for us. 🤘

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

Let's talk Shopify

Server-side rendering

Server side rendering is more resource intensive on a consistent basis, and deploying this approach for all pages of your storefront can potentially reduce page speed slightly, depending on the complexity of queries or data transformation and any mapping that is occurring on the server side layer during  requests but prior to render. 

However, this approach should be used where users expect real-time data on most pages throughout the site. If the storefront features heavily on user generated content, time sensitive deals and promotions, uses highly dynamic pricing or things like tired account based pricing, server side is quite possibly the way to go. 

A specific use case is an authentication-only application, featuring different user groups or segments, whereby access and pricing of products is dependent on the logged in user. In this kind of scenario, statically built pages aren’t going to allow you to securely offer the right experience to the given customer. You could, though, turn this into a hybrid approach by rendering your blog posts or informational pages statically within in your headless shopify setup. 

Takeaway: Headless Shopify stores can indeed be static, where this adds value to the user experience. For pages where this is not ideal, an augmented or hybrid-rendering approach might work best. Of course, it's entirely possible to forgo static site generation entirely, with everything being requested and assembled in real-time, where static site generation doesn't make sense. Contact us to discuss whether static is the way to go, or see more of our headless Shopify development services here.