If you are in ecommerce, you’ve heard of ‘headless commerce,’ ‘Jamstack,’ or ‘microservices architecture.’ They all more or less refer to the same thing: a modern approach to website development that results in blazingly-fast storefronts. In this post, I try to make sense of it all and provide a detailed explanation of headless commerce: what it is, how it works, how it drives growth across the funnel and how to avoid potential risks as you go headless.
Tip: We suggest reading this updated article about Jamstack CMS.
- What is headless ecommerce?
- Benefits of headless ecommerce
- The cost of headless ecommerce
- How headless ecommerce drive growth across the funnel
- What does headless ecommerce look like?
- How to go headless
- Conclusion
What is headless ecommerce?
Headless ecommerce refers to a modern approach to website development in which your storefront is decoupled from your backend and they communicate via APIs. In this analogy, your storefront (what your visitors see) is the head, your product catalog, payment processor, cart, etc. make up the body, and APIs function as the neck.
By decoupling what visitors see on the site (the frontend presentation layer) from the backend logic, headless ecommerce websites see far better performance, flexibility and control than traditional ecommerce sites. Here are the main reasons why:
- Headless frontends, such as single-page applications and progressive web apps, have instant browsing speeds. They can also support other app-like capabilities, like offline browsing and installability.
- Headless sites are free of backend code dependencies, which can add seconds to page loads (especially on mobile). This alone can really boost performance.
- Headless architecture lets you use best of breed solutions for your frontend independently of your backend. This allows you to use the best performing technology as well as tailor your stack to your specific use cases.
- Headless sites are more agile. Microservices architecture helps teams move faster, as they are focused on distinct services and avoid interdependencies.
Headless ecommerce vs. monolithic architecture
Traditional ecommerce sites tend to use monolithic ecommerce platforms, which provide all-in-one solutions (e.g. Shopify, Magento, Salesforce Commerce Cloud, SAP-Hybris, etc.). Monoliths offer almost everything you need to run your storefront, including proprietary frontends, backend inventory and product catalogs, hosting, a CDN and more. They are a great way to hit the ground running, however, their storefronts are inherently slow, especially on mobile.
On a monolith, slow backend processes and unoptimized third-party code need to finish running before your site can load. This is simply due to the fact that your storefront shares a codebase with your backend. There are other benefits to going headless, which I will go into later on in this post, but performance is by far the leading factor driving ecommerce sites to go headless. After all, speed is money.
Traditional ecommerce websites
Websites built on a monolithic ecommerce platform, using the platform’s frontend tooling.
Traditional ecommerce sites are typically slow and riddled with code dependencies and inefficiencies.
Limited control over design and functionality, based on the frontend tooling provided by the ecommerce platform.
Monoliths offer proprietary frontends that will only work on their platform. This is true even if the vendor offers API-first frontends (e.g. Magento PWA Studio or SAP Spartacus).
Adding a new endpoint or device requires a custom build (e.g. you’ll need to write a custom app for IoT display devices, you can’t just use your storefront code).
Developers only have limited control over the site (the monolithic platform itself is a ‘black box’ to some extent).
Headless ecommerce websites
The frontend is decoupled from the backend and is faster and more agile. The decoupling also allows the adoption of best of breed solutions across the stack.
Headless ecommerce single-page applications and progressive web apps have instant browsing speeds.
Fully customizable design and functionality, though dependent on developers.
Headless frontends are portable, so you can invest in your site for the long haul knowing that it will still work when you replatform.
Easily support additional channels (e.g. social selling) or endpoints (new device 'heads' and even platform 'bodies').
Full control over every aspect of your headless ecommerce website.
Benefits of headless ecommerce
There are three main benefits to going headless: speed, flexibility and control.
Headless commerce is faster
Site speed has a huge impact over the user experience and, as a result, your conversion rate. This is especially true for mobile websites for the following reasons:
- Mobile shopping has surpassed desktop shopping years ago.
- Consumers expect the instant experiences they have become accustomed to from native apps, on the mobile web.
- Network connectivity, demand, health, and device speeds impact load times.
Site speed impacts the bottom line of every ecommerce business, even that of the so called giants. In fact, Amazon calculated that a mere one second slowdown in page loads would cost the ecommerce powerhouse $1.6B a year in lost sales. Now that’s a lot of money!
Slow sites have also been found to create the same amount of stress as watching a horror movie alone, or standing in line. The latter is especially telling as most people tend to shop online to avoid doing just that.
We are here to help! Schedule a free consultation to learn more about going headless and how Builder can help.
Years ago, Google drew a line in the sand for load times at the 3 second mark. Since, modern web technology, including a modern breed of websites, faster-than-ever devices, 5G network speeds and shortened attention spans have raised the bar significantly. Fast is no longer good enough. The future of ecommerce is instant shopping experiences. Thankfully, headless sites are capable of amazing speeds that were previously unattainable.
Headless websites are app-like sites with instant browsing speeds. This new breed of modern sites, also known as ecommerce single-page applications (SPA) or progressive web apps (PWA), fast, reliable and installable by definition.
Ecommerce single-page applications
Ecommerce single-page applications and progressive web apps are API-first websites that provide app-like experiences (instant page transitions, offline browsing and installability). Examples of single page applications you know include Gmail, Twitter and Tinder. Examples of headless ecommerce sites include known names such as Walmart, Target and Airbnb.
The reasons for the speed advantage that SPAs and PWAs see over legacy websites are varied, but generally it goes back to optimized code. A headless site has a single page with a header and footer, and the body of the page is determined by the data you send over (it can be a content page, collection page, or product description page, the only difference is in the body of the page). This in itself results in far less code that needs to render before the page can load. Add to that optimized code that comes from the separation of the frontend and backend and you can see why these sites are so much faster than legacy ecommerce sites.
Performance might be the main reason that the future of ecommerce is headless, but it is not the only one. Headless sites are far more adaptable than legacy sites, allowing you to future proof your website against new channels, devices and even backends.
One of the main benefits of headless ecommerce is the freedom to use best of breed solutions across the stack. You can use the fastest framework for your storefront regardless of your backend platform, but that’s not all. A microservices-based, headless architecture makes it much easier for you to tailor your stack to your needs and use the best solutions available. All you need to do to add or replace a microservice (like a headless CMS) is disconnect from the old service’s APIs and connect to the new one’s. I might have oversimplified that one a bit, but that's the gist of it.
Headless architecture is composable, meaning that microservices are easily added and changed. This creates a ripple effect that impacts simple applications as well as popular ecommerce platforms. Even replatforming is less daunting when you have a headless site, which is portable and will work on any backend.
When you go headless you future proof your storefront
Just as headless commerce means you can easily connect and switch microservices or even platforms, it also means you can easily support new endpoints, such as new channels (e.g. social selling) and devices (e.g. IoT display devices). Simply connect the relevant services (storefront, cart, payment processor, etc.) to that new ‘head’ via APIs and you’re mostly done. You might need to make a few adjustments, but you won’t need to custom code a new app from scratch to support a new endpoint. Essentially, when you go headless you future proof your storefront.
Headless sites are far more flexible and adaptable than legacy ecommerce sites, because they are built on top of composable architecture. As a result, headless sites are fully customizable, providing developers with far more control than traditional ecommerce sites which are bound to and limited by the frontend tooling provided by the monolithic platform.
Headless commerce gives developers more control
As opposed to legacy ecommerce sites which can only be customized to an extent, and that too is based on the individual ecommerce platform’s frontend tooling, you have complete control over your headless website.
This is a point very near and dear to us. At Builder, our goal is to empower non-technical people to build rich digital shopping experiences in a way that is fully customizable and controllable by developers. We aren’t just talking profiles and permission sets, we’re talking full control over every aspect of the storefront.
With Builder’s headless CMS for ecommerce you can choose if and when to allow your team to create fully bespoke experiences using our visual drag and drop page builder and when to confine them to your design system or code components. You can even decide if non-technical users can edit the entire page or just one section (e.g. a section of your cart which can be used to A/B test upsell and cross-sell offers). This is also true for Builder Theme Studio for Shopify-hosted sites, as it integrates directly with your Shopify theme.
Tip: Learn how to integrate BigCommerce with Builder.io.
The cost of headless ecommerce
A lot has been written about the cost of going headless and quite a few myths have emerged. Let’s start by putting you at ease: going headless isn’t as daunting as it is sometimes framed to be. You don’t have to rewrite your entire site in one swoop and you absolutely do not need to replatform (see the recommendations on how to go headless below). With that said, there are a couple of known issues with headless sites.
The three main pitfalls of headless ecommerce and how to avoid them:
- First-page loads: While headless ecommerce sites have blazingly-fast browsing transitions their first-page loads tend to be longer than those of traditional ecommerce sites. This is because they are prefetching and pre-rendering the assets needed to make the rest of the session load instantly, during the first load. Server-side rendering (SSR) solves this issue, as it provides the browser with an HTML version of the page translated on the server, so that the browser doesn't have to translate the Javascript to HTML before it can load the page.
While SSR solves the problem, this should be something you keep in the back of your mind as you plan out and expand your storefront as it is very cumbersome to add SSR support after the fact. You’ll also need to find a place to host the server-side rendered content, so best to plan ahead!
- Investment to get up and running and support headless services: Going headless will require developer investment. But you don’t have to do it all at once, nor do you need to have large teams of frontend developers on staff. Not to oversimplify, but there are generally two paths merchants take as they go headless: cherry picking their stack or pre-packaged solutions with a frontend-as-a-service (FaaS).
Teams tend to either elect to pick and choose their frontend framework, headless CMS, CDN, hosting, middleware and backend solution, or they go with a pre-packaged solution (in the form of a FaaS) that works well with their backend. Both options have pros and cons and Builder can help you increase agility and empower designers and marketers to create converting digital shopping experiences, regardless of the path you choose. You can use Builder as a drag and drop web page builder, a headless CMS or even a packaged solution to power your ecommerce single-page application (page builder + A/B testing tool + headless CMS + hosting + CDN + data layer).
- Limited content management capabilities: This point is really a sub-bullet of the previous one, but it is so prevalent and disabling that it has earned its place here. With a headless site you have much more flexibility in choosing the apps and services you use- headless CMS, hosting, cart, etc.- but these tools limit the extent that non-developers can update the site.
With a headless CMS, you can easily make updates as long as you use predefined content models and templates. If you want a new layout, you’ll need a developer to first set it up.
With a headless CMS, you can easily update content, sections or even pages as long as you use the content models and templates your developers have set up. But, and this is a big but, if you want to test a new layout or add a new section to your site, or even a new page with new components, you will need a developer to build it for you. So, if your developer or agency does not create every possible content model you will need when they setup your headless CMS and storefront, you will be limited in the extent in which you can update your site and test new ideas.
This is a key reason Builder exists. We aim to break the reliance on developers that is so common to ecommerce, while maintaining developer control. Builder’s headless CMS comes with a powerful drag and drop page builder that allows designers, marketers and merchandisers to easily create new digital experiences, or visually edit existing pages, all within a system that is fully under developer control.
The three drawbacks above might be enough to discourage anyone from making the move to headless commerce, but they really shouldn’t as they can be avoided with the right process and tools. Not to mention that they pale in comparison to the bottom-line growth that ecommerce sites experience once they go headless.
Headless sites are faster than traditional, multi-page websites. There’s simply no way around it. This is due to the separation of the frontend from the dependencies of backend code, as well as the nature of modern headless frontends and their lightning-fast browsing speeds.
In ecommerce, speed is money. The faster the site, the lower the bounce rate and the higher the conversion rate. Every second added to page load time cuts conversions by 7%. For this reason site speed is crucial for mobile sites, which tend to be slower than their desktop counterparts. These are known facts. What is less known is the impact that speed has on search traffic and ranking. This is especially relevant to ecommerce websites, which rely heavily on organic and paid search traffic (and revenue).
Site speed and SEO
Google has been prioritizing faster sites in SERP and ad placement for a while. Faster sites tend to have higher search ranking and quality scores than their slower competitors, for equivalent keywords. A few years back, the search giant started favoring the lightning-fast page format it developed (AMP) in organic results and till this day (though this will change with the upcoming Page Experience update) the coveted Top Stories slot on mobile only displays AMP pages.
AMP and the mobile-first index are just a couple forces behind the SEO and SEM benefits faster sites have been seeing. But these are nothing in comparison to the latest and largest ranking update, the Page Experience update, scheduled to roll out in May 2021.
Based on Google, the Page Experience update will rank sites based on the experience they provide to real-users. And this is by far the most explicit the search giant has ever been about its ranking algorithm. Not only has the company shared how it is collecting data (real-user data from the CrUX database) it also shared the exact speed metrics and thresholds that will influence search ranking (collectively referred to as Core Web Vitals).
Page Experience update introduces three perceptual speed metrics to the set of signals used to determine search ranking. These metrics, referred to as Core Web Vitals, are largest contentful paint (LCP), first input delay (FID), and cumulative layout shift (CLS) and they are measured based on real-user data from Google CrUX database. Here’s what you need to know about each metric:
LCP measures load performance and is marked by the time it takes the largest element on the page to load, which for ecommerce is typically the hero image. To pass this metric, your LCP times should be under 2.5 seconds.
FID measures interactivity and essentially measures the time it takes for the page to become interactive and react to user activity (clicks, scrolls, etc.). Google’s threshold for a good experience is a FID that is under 100ms.
CLS measures visual layout stability, or page jank. You’ve seen this before, you land on a page and after a second or so it rearranges itself as all of the assets are downloaded. The threshold for a good experience is a FID that is less than 0.1.
To pass Core Web Vitals all three measurements need to be under the threshold for at least 75% of your visitors (so the devices they use, the network they are on, and other external factors impact these measurements). Unfortunately, today most ecommerce websites do not pass Core Web Vitals. This makes sense, as most are still on monolithic platforms, which are inherently slow. This also represents a massive opportunity for brands to leapfrog the competition and outrank the giants with a blazingly-fast headless ecommerce website.
To recap, headless sites are faster than traditional ecommerce sites. This faster site speed results in a superior experience and lifts across the funnel, from improved search ranking to lower bounce rates and higher conversion rates and revenue. Interested in going headless? Here’s how to go about the process to avoid the risks associated with it.
We are here to help you! Schedule a free consultation to learn more about going headless and how Builder can help!
There are some misconceptions about headless commerce. Some say that you have to rewrite your entire website at once, others will tell you that you have to replatform, or custom code your entire stack. You might have heard that headless commerce is always more expensive than sticking to the monoliths, or that Jamstack sites cannot scale. None of these statements are true.
You don’t need to replatform or rewrite your site from scratch, which could set you back about six months. You don’t need to custom code your entire stack, nor do you even need to have large teams of frontend developers on hand (you can work with an agency, or use a frontend-as-service).
Generally, headless commerce comes in two favors: a fully customized and handpicked stack or a pre-packaged solution using a FaaS. Some start venturing down one path to switch later on. There is no right or wrong, there is only what is right for you.
If you cherry pick your entire stack (frontend, headless CMS, hosting, CDN, etc.), you are fully adopting a best of breed approach and tailoring your stack to your needs. You can use the best service for each function, wowing consumers at every turn and adding to your bottom-line. This approach will require more initial effort to set up than the FaaS route and more specified technical expertise to maintain and scale, but it will result in a custom tailored stack.
If you go with a FaaS, you largely simplify your stack selection and setup time. You might also lower the level of specific knowledge your team needs in order to maintain and expand the site. However, you might also lose some control, as you are confined to the set of functions and solutions provided by your FaaS (e.g. you can’t pick your CDN, you use the CDN your FaaS supports). While these are slight limitations they are still worth stating, so you can make an informed decision.
Both options have merits and drawbacks. That’s why we built the Builder platform in such a way that it supports both approaches and helps you bridge the gap between the two! You can choose to use Builder as a drag and drop landing page builder, a visual headless CMS, or even a full blown frontend-as-a-service. You can use Builder as one layer in our stack, or even just one part of your website, or fully throughout. The choice is yours and whatever you choose you will also get powerful content optimization features, including content targeting, A/B testing and built-in heatmaps, out of the box.
Here are a few examples of the ways that known brands are using Builder to create, test and optimize rich headless shopping experiences:
- A leading lifestyle brand is customizing and targeting multiple versions of their site based on user behavior (e.g. previously purchased collection and login status).
- A well known men’s clothing brand is testing the impact of displaying a countdown timer in carts in driving urgency.
- A popular comparison shopping site is using Builder to manage display featured promotions in their mega menu.
- A leading custom goods brand is creating and updating category pages for search traffic across a dozen of international locations.
There are nearly as many ways to use Builder as there are ways to go headless. Read on for a few recommendations to make your transition to headless commerce easier.
How to go headless
Here are a few tips to help you avoid the potential pitfalls of headless commerce:
Migrate incrementally
A/B Test ROI
Share Content
1. Migrate incrementally
A full website rewrite is not a prerequisite for headless commerce. It’s not even recommended. It’s a myth. We recommend you follow Martin Fowler’s ‘strangler pattern’ and incrementally migrate over the legacy site to a headless one. Focus on your high value pages first (homepage, collection pages and product pages) and migrate the rest over when time permits.
Incremental migration to headless significantly lowers the barriers to entry, while maximizing potential impact. You’ll also go live sooner than if you had to wait for a full site migration.
2. Test and prove ROI
By incrementally migrating to headless ecommerce architecture you have the opportunity to test and prove ROI early on. You can get results quickly and on the cheap by making just one page headless at a time and testing it against its legacy counterpart.
We recommend you compare the performance of your legacy site to that of your headless storefront across a variety of KPIs (speed, bounce rates, engagement, conversions, etc.). Once the results come in with proof that your headless site outperforms the legacy site, you’ll feel even more confident about going headless. You’ll also have more internal support.
3. Create content that works on headless and legacy sites
As you incrementally migrate your site over to headless you’ll need to pull content that can be displayed on both experiences, or you’ll end up supporting two systems.
Like any other headless CMS, Builder content is stored as data and transmitted over APIs to headless storefronts. Unlike other headless CMSs, Builder also has page building functionality, which allows its content to work on traditional sites as well as headless sites. Content is still stored as data but Builder’s page building capabilities mean that it can transmit the data and generate the code required to build the page for hosted sites. Builder is truly technology agnostic, and simply works with any stack.
4. Migrate from hosted to headless seamlessly
Because Builder content works with headless and legacy sites it allows you to seamlessly migrate from hosted to headless architecture. Builder’s platform also comes with built-in A/B testing, allowing you to test and determine the ROI of your headless site early on and continue to optimize your storefront. And incremental migration is a breeze with a platform built to support varying degrees of usage. Use Builder for part of your site, or even part of a page, or use it to power your entire storefront. You have full flexibility and we will support you regardless.
Conclusion
The future of ecommerce is headless and for good reason. Consumers get a superior experience and merchants grow their bottom-line. Win-win!
Overall, headless commerce sites are faster, more adaptable and offer developers far more control compared to legacy ecommerce sites. Headless sites are portable, composable and they future proof your storefront against new channels and devices.
When ecommerce companies go headless they tend to either build out fully tailored stacks where they hand select every element, some even going so far as to custom code every service, or they go with a frontend-as-a-service. Builder works well with both approaches and can even be used to bridge the gap between the two.
Builder can be used as a drag and drop page builder, a headless CMS, a headless storefront builder, or any combination thereof! Every use case comes with a powerful and seamless way to manage content, customize and target it at different audiences, A/B test it, schedule it, analyze performance and much more.
As you venture into your headless journey, we recommend you keep the following tips in mind. We hope this will save you some time and help you avoid the known risks :-)
- Migrate incrementally. There is no rhyme or reason in rewriting your entire site at once.
- Test and prove ROI early on, this will help you gain support and confidence.
- Create content that can be displayed on both the legacy and headless sites, or you’ll need to support two systems.
Sign up for free today and start building a headless ecommerce site, visually
