‍

If you are at all close to the world of eCommerce software you’ve likely heard the term “Headless” come up in conversation. It seems to be all the rage. All the big stores are doing it. But what does ‘going headless’ mean? And is it really the panacea that some people think? We’ve put together this deep dive guide to help newbies and veterans alike think about the pros and cons of going headless. 

The best metaphor we’ve heard about headless is that it's like an extremely sharp knife. Yes, there are benefits - you will be able to cut things more easily, but there are also drawbacks - you risk cutting yourself more easily with a sharper knife. 

Let’s start with the basics.

‍

What is headless eCommerce? What does it mean to go headless?

Headless is a software architecture that separates the front end of your store (the head) from the back end of your store (the body). The front end is the piece that your customers see and interact with. The main component for eCommerce front ends is your website (product pages, landing pages, blog etc. etc.). It also includes your mobile app (if you have one), and physical touchpoints, but let's not get overly technical. The backend is all the stuff that your customers don’t see (inventory management, payment processing, discount logic etc.)

Traditional eCommerce platforms (like Shopify, our recommended eCommerce platform) tie the two elements together extremely closely. Changes to the front end will often require changes on the back end to work. By going headless, or separating the front and back ends, you allow for greater flexibility and control of the customer experience because you can make front end changes without making changes to your back end. 

This doesn’t mean you have to leave Shopify when you go headless. The out-of-the box version of Shopify is not headless, however, Shopify is designed to allow stores to go headless without leaving Shopify. In this migration, stores leave Shopify’s front end and continue to use its back end functionality (payment processing, order and inventory management etc.)

The differences between headless and non headless (sometimes referred to as monolithic) implementations are easy to understand in the abstract, but the benefits of headless are better understood with specific examples. People often throw around buzzwords like “greater composability” or “unlocking true omnichannel experiences” but fail to dive into the details. 

Let’s make this tangible with an example of how you would make a change in a typical monolithic architecture and then see how it works in a headless architecture. Let's say you run a Shopify store and want to implement real-time inventory tracking and stock management. 

In a typical monolithic architecture for a Shopify store, introducing real-time inventory tracking and stock management can be a complex and risky process. Shopify's native architecture tightly couples various components, such as product listings, order processing, and inventory management. As a result, modifying the core code to enable real-time inventory updates can be challenging and may lead to unintended consequences in other areas of your site.

However, with a headless architecture in a Shopify store, implementing real-time inventory tracking becomes more manageable and less intrusive. Headless commerce allows developers to decouple the frontend and backend, giving them the flexibility to develop specialized microservices for inventory management without affecting the rest of the Shopify platform.

Hopefully we haven’t lost you yet. Let’s dive into the benefits of headless.

‍

What are the benefits of going headless?

‍

Faster website speeds

One of the main benefits of going headless is speeding up your website. The data is pretty clear that a faster website will increase your conversion rate and decrease your bounce rates. Page load times are also factored into the Google search algorithm, so improvements in your page load speeds will improve your organic search results. 

Monolithic systems like Shopify often suffer from performance and speed problems at scale. As you install more apps on your theme and as you attempt to implement more complex things like personalization, your website performance suffers.

Headless architecture will speed up your website because content (images, video etc.) will be delivered more efficiently. With a headless approach, the content is delivered via APIs (Application Programming Interfaces) which allow developers to retrieve specific data or content elements directly from the back-end without fetching an entire webpage. This targeted content delivery eliminates unnecessary data transfers, reduces network latency, and enhances overall page loading speed.

A headless architecture will also unlock modern, lightweight frameworks or libraries like React that are optimized for front-end performance. They employ techniques like lazy loading, code splitting, and caching to ensure faster rendering. (Read our point on development frameworks below for more info)

By going headless, you should see an improvement in your website performance.

‍

More control of front end appearance and personalization

While Shopify has been pushing hard to unlock more customization ability natively within the platform, you will inevitably run into roadblocks where you would like a page to look a certain way but you settle for a different layout or figure out a hack workaround. With headless you get full control over the look and feel of your site. You will no longer be limited by Shopify pre-built components. 

Headless will also unlock the ability to better personalize your website. In the typical Shopify implementation the same website is presented to all visitors. This works well for most smaller brands, but larger brands will want the ability to change the appearance of the website based on what we know about the visitor. An easy example would be customizing the homepage hero banner image and text based on the ad that sent the user to the homepage (e.g., A user clicks on an ad focused on the fit of the clothing and the homepage hero image and copy are focused on the fit of the clothing). Headless will also improve localization efforts as localization is simply another form of personalization. 

‍

Faster development changes

Since you can make changes to the front-end without needing to make changes on the backend (and vice versa), it will speed up development. 

Let’s say you’re a Shopify store owner that wants to implement a new feature that allows customers to customize their products color and preview how different products will look with various color customizations. This feature requires dynamic rendering of product images with selected customization options. In a traditional monolithic approach, the front-end (product detail page) needs to be modified integrating new JavaScript logic for color selection and preview. This might require having to navigate through a complex codebase to make the necessary changes. Then the back-end must be altered to implement new logic to handle color selection and serve the correct product images based on the chosen color. This could involve modifying database schemas, server-side code, and potentially affecting other parts of the monolithic application. Using a headless approach, the front-end team can build a separate, standalone application using a modern framework like React or Vue.js. This application will be responsible for rendering the product detail page and handling color selection and previews. The back-end team can focus solely on providing the necessary APIs to serve product data and images based on color selection. Shopify's storefront API can be used to fetch product details and images, and the back-end developers can build custom endpoints to handle color selection.

‍

Unlocks new development frameworks - easier to find developers and faster development

If you are not headless and using Shopify, then your front-end must be developed using Liquid. Liquid is a coding language that was developed by Shopify in 2006. Liquid is a robust, open-source development framework written in Ruby, but it has its quirks, and many front-end developers prefer more modern languages like the one Facebook has developed called React.

By going headless, you can code your front end in whatever development framework you like (React, Next, Vue.js, Angular, Gatsby etc.) This will open up the pool of developers that can work on your front-end. While there are many experts in Liquid, there are more developers for React and other frameworks. By coding in React, you might also be able to speed up the development time of your front end as there are more extensive component libraries.  

We’ve just sold all of the benefits of headless, however, there are meaningful drawbacks to going headless.

‍

What are the drawbacks of going headless?

Time and cost to implement

Going headless is not a switch that you can easily turn on and off. There will be a lengthy process to get your store ready to go headless. Then there will be a transition period from non-headless to headless where you will inevitably encounter a host of bugs no matter how thoughtful you were in preparing to go headless. There is a real cost in terms of time and development resources in making the transition. Stores we spoke with spent between 5 to 12 months in preparing and transitioning to headless.

Increased Complexity

Headless eCommerce introduces additional complexity compared to traditional monolithic setups. You need to manage multiple systems, APIs, and integrations between the front-end and back-end. This complexity can require more technical expertise and increase development and maintenance efforts.

Development Effort

Building a headless eCommerce website often requires more development effort compared to a monolithic solution. You'll need to create separate front-end applications for different platforms (web, mobile, etc.) and ensure they communicate effectively with the back-end. This can result in longer development cycles and increased costs.

Lack of Out-of-the-Box Functionality

Many monolithic eCommerce platforms provide comprehensive out-of-the-box features, such as shopping carts, payment gateways, inventory management, and SEO optimization. In a headless setup, you'll need to build or integrate these features yourself, which can be time-consuming and require additional resources.

Integration Challenges

Integrating third-party services and tools with a headless eCommerce architecture can be more complex. As there are no pre-built modules or plugins specifically designed for your headless setup, you may need to customize and integrate these services manually, which can add development overhead.

Content Management

In a headless architecture, content management may require a separate CMS or content repository. This means you'll need to invest in selecting and setting up a suitable CMS, ensuring it integrates well with your front-end applications, and managing content across multiple systems.

Learning Curve

Adopting a headless approach may require your development team to learn new technologies, frameworks, and best practices. This learning curve can slow down development initially and may require additional training or hiring of specialized personnel.

‍

Is it worth it to go headless?

Unfortunately, the answer is it depends. Companies must weigh the real benefits with the real costs. We see too many companies that jump into headless without giving enough consideration to the downsides. Companies like Glossier have actually transitioned from headless back to non-headless because of the challenges headless presents. Yes, lots of large brands are headless, but that doesn’t mean that once your brand reaches a certain size that it should go headless.

We see too many brands going headless that are probably better off not being headless. There is a lot of headless FOMO.

The narrative around headless and its benefits is often pushed by companies that either have tools that enable headless or by those that will make money consulting on the headless implementation (and beyond as bugs inevitably crop up).

We go back to our original metaphor of headless being a sharper knife. Yes, there are benefits - you will be able to cut things more easily, but there are also drawbacks - you risk cutting yourself more easily with a sharper knife. We see too many companies that only focus on the benefits.

Companies that we have spoken with and have had the most success with headless have some similarities. They have a strong in-house development team, they have a team that can unlock personalization benefits, they have a slow website to begin with.  

When should an eCommerce store consider going headless?

We don’t think a brand that is doing less than $100M in annual revenues should consider going headless. And that doesn’t mean that all brands above $100M should be headless. Below $100M brands wont have the budget for an in-house team to support the implementation of headless and to maximize the value post headless (with things like a dedicated personalization team).

Above $100M in sales we think the leadership team should begin considering going headless.

‍

What are the components of a headless architecture?

The primary components of a headless architecture include:

Content Management System (CMS): The CMS serves as the content repository, where content creators can create and manage content independent of its presentation or delivery. In a headless CMS, content is stored in a structured format (often as JSON) and can be accessed through APIs.

Application Programming Interface (API): APIs are the connectors that allow communication between different components of the headless architecture. The headless CMS provides APIs to deliver content to various front-end applications, and other services may also provide APIs to interact with the system.

Front-end Presentation Layer: This component is responsible for rendering the user interface and displaying the content obtained from the headless CMS. Developers can use any front-end technology, such as React, Angular, Vue.js, or others, to build the user interface and deliver a seamless user experience.

Backend Services: While the CMS can handle some dynamic content and logic, there might be certain dynamic functionalities, server-side processing, or integrations that require backend services. These services can be developed and deployed independently, and they communicate with the front-end and other components via APIs.

Database (optional): In some cases, headless architectures may include a database, especially when there's a need to store and retrieve data not managed by the CMS. This database can be separate from the CMS's content storage.

Third-party Services: Headless architectures often make use of various third-party services for specialized functionalities, such as analytics, search, payment processing, authentication, and more. These services can be integrated through APIs to extend the capabilities of the application.

Content Delivery Network (CDN): A CDN can be utilized to efficiently deliver the front-end assets (HTML, CSS, JavaScript) and other media content (images, videos) to users, reducing load times and enhancing performance.

‍

What are examples of headless ecommerce stores?

Shopify headless stores

Cuts clothing

Allbirds

Kotn

Boll & Branch

Parachute

Recess

Rothy’s

Blume

Clare