Explaining headless commerce in layman's terms

There are plenty of articles on the internet, explaining the meaning of headless technologies and headless commerce. And nearly all of them are focused on explaining the core technical terms.

However, the majority of the merchants are not from an engineering background and hence I am writing this article to explain headless commerce in a way that everybody would understand. More with real-life examples.

If you are reading this article, then chances are you have already heard the term headless commerce and also somehow know about some of the benefits attached to it. The most commonly known benefit is, headless is fast; which is the biggest reason behind the popularity of headless commerce. Let’s see how this Fast thing is working.

When does it become fast

Have you noticed what happens when you dine in a restaurant? You go inside, the waiter comes, you place the order. After that, it takes a while to prepare the food and bring it to your table.
If you compare this with Mcdonald’s, you will find that you go there, you place the order and you get your food almost instantly.

Now let’s try to understand these real-life examples a little deeper.

Both the restaurant and Mcdonald’s prepares your order with different kinds of ingredients, but the first has a very low layer of abstraction or prepared ingredients and the other one has everything near ready components.

In a traditional commerce website (eg: normal Shopify theme) when a user requests a webpage via his browser, it works like the restaurant. It compiles everything in the theme and then gives you results. There could be multiple apps injecting multiple logic, multiple HTML creation operations, and many other things.

However just like Mcdonald’s burger component creating machines, headless also creates a layer of abstraction, which is why it doesn't do the same operations again and again, but does only the very necessary ones; and that’s the reason it can serve the user faster.

In short, headless is a layer between the user and the backend (Shopify, Bigcommerce, Magento, etc.) The website user’s browser sends a request to the headless storefront. If the headless storefront already knows what should be the output, it just immediately responds; and if not, then it makes the required API called to get some data, then compiles it with its own template, and serve the request. This approach is what makes headless tremendously fast.

Fast browsing

Imagine two scenarios. In the first one, you went to a store and bought a good amount of groceries and with quite a few big fat bags you are walking back towards home.
In the second scenario imagine yourself walking towards home with just a purse in your hand.
In which case do you think you will be able to walk faster?
Of course the second. And that’s because you have lighter weights in your hand.

Browsing through a headless website is faster because of similar reasons. Moreover, if it is headless with PWA, it literally gives the user a native app-like feeling.

In the case of traditional e-commerce websites, if a user navigates from one page to another, the browser again requests for the second page and downloads the entire page; even though there are many components like header, footer, sidebar that didn’t change at all.
But in headless, when the user navigates, it only fetches the required information. For example, if a user is viewing a PDP of a certain product and then he wants to navigate to another product details page, the headless will just fetch the information of the new product. The rest of the things remains as is; i.e. the header, footer, and any other common components, they are not even re-rendered.
This is how the communication between the browser and the server is reduced and the time taken for each page render is extremely lower.
And with the proper page caching (if a page is already visited then the same info will not be fetched again) with PWA; the site can even work offline (without mutation).

Back in technicals

Now that you know that headless is all about how to keep few things ready-made and how to fetch only the required data instead of a whole page, now let’s talk a bit more on the technical side.

Communication in a traditional store

In a traditional store (say Shopify store with a simple theme), when the user requests a page from the browser, the request directly hits the core system. Be it the 1st page request or 5th, it works the same way; i.e. hit the (Shopify) backend, get the whole HTML, render it in the browser.

Communication in headless store

In a headless store, there is a thin master layer for the frontend in between the browser and any other backend system. Any request from the browser is going to hit the frontend layer and the frontend will decide what to do.
The best thing is, after requesting the 1st page, a frontend application lives in the browser itself and cal reduces communication and volume even further.