Should I go headless on Shopify / Shopify Plus? Pros & Cons of Headless

Headless is no longer the new buzzword in eCommerce (and Shopify). It has been trending upwards for at least the past couple of years and isn’t going away. By this point you will no doubt have read dozens of very similar articles around what it is, and opinions on why it is good or bad, worthwhile or pointless on Shopify - and have seen the word ‘decoupling’ more times than ever before. But a buzzword is still what Headless is. The reason being, it’s not a technical innovation. It’s a well-established software architecture principle called ‘separation of concerns’ - but with a more glamorous spin.  

What is Headless

Shopify itself is built using Ruby on Rails, which is an Model-View-Controller (MVC) framework - meaning it separates the layers for Database management, business logic, and frontend rendering. A Headless architecture is essentially applying this pattern into the way the frontend is structured - so that the data handling, business logic, rendering that usually occur within the theming template files are all working in isolation, and connected via APIs. 

Data: All of the content being output onto the page. This includes rich content landing pages, blogs articles, product images & descriptions, metafields etc.

Business Logic: The functional behaviour on a page, driven by the Liquid coding within the template. An example of this would be displaying product recommendations, and using Liquid to check any Tags or user interactions before showing the appropriate product selection based on those rules. 

Rendering: The visual front-end development work - styling and layout. Everything you see at a wireframe / design / styleguide stage of planning.

The reasons for this change in architecture are the shared reasons any software design concepts are applied - efficiency and scalability. Future-proofing the codebase for what may (or may not) lie ahead on the roadmap & within the team, and minimising the chances of bugs/issues being introduced over time. That can be demonstrated by the following benefits:

• Modularity: By splitting those front-end concerns apart, you are left with a more modular approach and one which those parts are then interchangeable. For example, switching the layout for a different design inline with a marketing campaign (see the SkullCandy layout completely changed for a new release or campaign), or delivering a different experience to people using devices in-store, to an app or to an optimized storefront for China for example.   

• Distributed Workloads: Multiple people can now be working on that same homepage at the same time without any issues. The content editors can be updating what they need to update, while the layout is being changed.

• Organisation: Separating these aspects leads to a leaner, more organised codebase. From a long term perspective this means time is saved on staff onboarding into the codebase, due to the easier learning curve; and bringing in additional development resources won’t incur overheads due to building specific project knowledge. It also means that there is a reduced risk of bugs being introduced into a snippet of code or ripple effects into future development tasks, because each snippet should have a single purpose.

• Independent Releases: It was already touched on that multiple stakeholders can work on a page at the same time - eg content editor & developer working on the homepage. Building on this, multiple developers can be working on completely unrelated tasks with the knowledge that there will be no conflicts in the code they are introducing. Moreover, they can independently test & release features (even within the same page) without impacting each other. No more waiting for that one big release to see a specific new feature in action.   

Debunking some common arguments

Headless is a step forward in terms of the overall architecture of your digital business. Especially in the midst of this multichannel boom. There should be no argument for if being good or bad - just whether it is best fit for your business at a specific point in time. However, it is vital to understand the term itself doesn’t guarantee any sort of end result. By ‘being Headless’ it’s not a guarantee that your online store will be any more effective than it would have been, it just unlocks the potential for that to happen. It’s planning permission, and the execution as always is the critical part.  

There are a list of common factors which are generally used in the argument for/against going down the Headless route. But when applying context, most of these points can be countered so aren’t always relevant. For this reason, it’s important to have confirmed your project’s functional requirements before weighing up whether it is a good fit - rather than working backwards from the solution to make it fit. The common points you will have seen, should be considered as follows:

FOR HEADLESS

URL Structures

To start with the critical one, this one is absolutely black & white. As things stand, Shopify natively has a fixed URL structure. While that structure is pretty strong in terms of SEO, being completely restricted to it may have a huge impact for you if you are migrating a site that is heavily reliant on existing organic ranking. If this is absolutely the case, then Headless is the only way to avoid that potential upheaval.

Amazing Performance

This is typically a strong argument for Headless - and rightly so. By harnessing some of the latest technologies such as Gatsby.js to generate static pages and leveraging caching you can achieve page speeds of fractions of seconds, and that all green Lighthouse score. Although there are a few strong native Shopify examples that come close [Such as BluBlot one] (by being aggressively limited in 3rd party code), Shopify even straight out of the box can’t come close - as things stand. 

On the other hand, Headless alone doesn’t guarantee an incredible performance; it still needs the right SI, using the right tools in the right way - and I’ve seen Headless builds that are about as strong from a performance standpoint as they could have been natively. On top of this, Shopify is really pushing the native performance of it’s stores and is improving all the time. 

Unrestricted UX

This point is often raised as a reason to go Headless, but without too much foundation about exactly what restrictions are faced working natively. The URL structure being fixed, does have a knock-on effect here. But while flexibility to introduce any sort of UX is made easier, that isn’t to say a specific UX isn’t achievable within Shopify themes. Integrating an App or javascript technology like VueJS/React into the theme provides the ability to achieve whatever experience is desired without committing to being fully Headless. It may well prove to be more effort, and less flexible to future change - but not impossible. 

Content Management

I think separating content management completely from theme management is a very good thing, plus the ability to streamline the workflow for adding/editing content across multiple storefronts can only be positive. So overall, it is a strong reason for a Headless approach. However, this point is often presented as Headless being the only way to implement additional rich content across a store.

Shopify Sections are very flexible to meet different requirements, and with the imminent (hopefully) release of Sections Everywhere - allowing them to be used sitewide & managed more efficiently - they will become a much more viable solution to the need for large amounts of rich content. The use of Sections, plus apps like Shogun and Syncio means that with a considered strategy around content management up-front, it doesn’t have to be such a major headache, and at the very least, shouldn’t be quickly ruled out as being a viable option.   

PWA

Introduction of a PWA does come much more hand-in-hand with Headless solutions, but is by no means ruled out by having a standard Shopify build. Again it may be more effort in terms of development time, but there are some apps & platforms that are very much worth looking at to help achieve this if required, such as [Nacelle] or even [Tapcart] as an alternative. However, if this began as an important requirement within the scoping of the project, it may well be a cleaner approach as part of a Headless build. 

AGAINST HEADLESS

SI lock-in

For many, one of the major selling points of Shopify is that as a hosted platform there isn’t as much of a concept of being locked in with an agency - you have full control and access to the theme and if the worst happens it can be picked up and worked on by someone else. Going Headless is certainly moving away from this concept. Your storefront(s) and CMS will be away from Shopify, and different agencies will have different preferences when it comes to their development stack and what hosting/content management solutions they would put in place together within the architecture. But again this isn’t a black & white argument, that situation can be avoided with the following:

1. Due Diligence. Initial SI selection is important, understanding the track record of Headless builds they have delivered and their development process. Do your due diligence on the platforms they propose to use and the reasons for them, ensure these are widely used and regarded options should you need other people to work on them in the future. 

2. Own your architecture. There is a good chance these solutions may include services like AWS, Netlify, DigitalOcean, Contentful, Prismic etc. Ensure these accounts are created with your details, paid for directly through your account, with the main admin account tied to your email. This won’t cause any issues with work being done but will keep you in control of everything should any issues ever arise.  

The other element to this, is that by implementing this architecture (rather than it being a SI lock-in issue), it will result in you not having the ability to log into Shopify and dabble within the theme code yourself. Again, this goes back to where you are at as a company. If you are already working with an established SI, the likelihood is that the codebase is version controlled and you can’t/shouldn’t be doing that anyway. This same principle will of course apply - except you would actually lose the ability to reach the production code (without being an agreed part of the development process). Having restricted access to production code should be seen as a positive, it just requires trust in the SI.   

Loss of App Functionality & Shopify Updates

It is true that taking the Headless route means you lose the functionality to go into the app store and install anything. Not every app will be out of use, many of the more well established apps such as Klevu/Nosto will require development work via API to integrate. The majority will not have APIs though.

Again this comes down to where your business is. Shopify have the large base of startups & entrepreneurs who depend on the ability to do this. Doing some research on apps, installing and extending functionality without the need of developers is key. But at a certain point this is not the best approach for scaling while maintaining efficiency and consistency of the codebase - it is better for these to be installed through the SI’s version-controlled process. So at the point of Headless being a consideration, this loss shouldn’t have a major impact.

In terms of Shopify updates, checkout updates would still apply which is crucial. Backend Admin updates would still apply too. Shopify constantly work on improving the server-side performance, which get rolled out frequently to benefit the load speeds of all stores. This would no longer benefit, but the idea is this would be irrelevant because performance should already be much greater.

Complexity

There are more moving parts, and there are more touch-points to understand the job of - that part can’t be denied. However, those moving parts are responsible for the same amount of actual complexity - the complexity lies in the nature of the project itself. In context a project could be a standard Shopify build and be hugely complex, or a really clean and straightforward Headless build. As an analogy, it’s the difference between building a new house and having a plumber, electrician and gas engineer each doing their relevant job - or a (very talented) individual doing them all. There are more moving parts at the same time, but it does not make the job any more complex. 

Agility

Agility is an interesting point, because it is one of the key arguments for selecting Shopify as a platform in the first place over Magento for example. This new architecture will lead to more planning and coordination being done before developing new functionality on the store, and this also covers the issue of any given app no longer being simply dropped in at any point. Small changes are likely to take a bit longer. So all of this combined does mean there is a loss of agility to a point.

The ability to review and make quick decisions within sprints is not lost. And because of the architecture decisions, bigger pieces of development should be quicker to get in place & test - and that more development can take place at the same time. Over time, and given the modular approach, more and more elements will be available to reuse. Agility on a larger scale should therefore be better. 

TCO

Total Cost of Ownership is a point raised to avoid Headless in many articles I’ve seen. Often arbitrary ballpark figures are used as a minimum turnover before considering the switch, which have no context or relevance. There is no single figure that makes the approach become a viable return on investment because so much depends on context, although if cheapest initial build is the key criteria then it’s probably fair to say a Shopify Theme would be better fit.

Total is the critical part of the point. The cost of the initial development of a new store will (likely) be higher with a Headless architecture. But 3-5 years of consistent retained development could easily result in the Total cost being much less for a Headless build - because of the savings in efficiency, code reuse and reduced risk of code degradation.

Alternative options

The longer time goes on, and the more popular the Headless approach becomes to Shopify projects - more options do become available to help bridge that gap between a standard theme build and committing to a fully Headless architecture. 

First, and as touched on in some of the above, there are very good examples of a bit of a hybrid approach to a build. This means the store would still be running from a theme, along with the benefits that come along with that - but utilises a technology such as VueJS or React within the theme, to access the Shopify APIs and extend functionality. This requires a different development skill-set to general Shopify template development, so the risk is introducing a technology that not everyone will be well versed in. But in a lot of cases, especially to build out something like a custom Product Builder, changing the whole architecture isn’t necessary to product complex functionality.

On top of this, there are some really strong third party technologies that are focused on making this Headless approach more accessible to the wider Shopify merchant community. Two technologies in particular that are achieving this, having approached it from different angles are Nacelle & Shogun. 

Shogun is a well known and well established content management platform, that is used alongside Shopify as a pagebuilder - to build up rich content pages and blogs. Particularly useful before Shopify Sections were around, Shogun have recently pivoted slightly with ShogunFrontend to be much more than a page builder - and become a platform to build out the pages in a Headless way. 

Nacelle has been around the Shopify ecosystem for several years, initially focused on being an easy way to introduce PWA technology into the storefront of their own clients who were struggling with poor site performance & mobile experience. This has evolved over time, to the point of being established as the best method of achieving these results away from a major custom development project. 

These are both very strong options that are worth putting time into exploring further when considering the benefits of Headless & PWA. They may not be the ultimate answer, certainly not for every project, but could well be cost-effective & low effort ways to achieve a desired outcome. 

Key Takeaways

In summary, there is a lot to consider around this topic and especially in how best to implement it into a given project. These are my key points to takeaway:

• Headless approach is a positive long term step if it’s feasible in your context. It is essentially a well-established software design pattern, and a positive thing if in a position of delivering a custom build. It will likely mean extra cost up front for the immediate build, to be more streamlined & flexible and reduce cost into the future.

• The only absolute reason to go Headless with Shopify is the freedom of URL structure, this is a hard block if required. But everything else could be achieved in different ways. Strong project execution is more important than simply executing a Headless project. 

• It is not a black/white decision that needs to be made upfront, unlike making the initial platform selection. If there are doubts or compromises, moving to a Headless architecture can be brought in as a later phase or gradually implemented.

If you have any experience or opinions on this topic, I’d love to hear them - feel free to email Liam@vervaunt.com to discuss anything further.