Splash About

For most Commerce sites this is a simple check - a full rebuild or replatform is likely to be measured in tens of thousands of pounds, climbing rapidly in line with complexity. In contrast, even where significant version upgrades are needed, maintenance with a view of only staying current and PCI compliant, is likely measured in hundreds per month. Cursory sums will show that most builds can enjoy a comfortable lifespan of at least 3-5 years.

The context of a return on investment for the client is a key factor that we consider when conducting Magento audits for inbound support clients - for more information, click here.

• Poor SEO performance due to no server-side rendering of content
  
• Poor Lighthouse performance scores (including, ironically, for ‘PWA’)
  
• Inability to easily access Adobe Commerce ecosystem for modules and new features
  
• Basic features such as Google Analytics were poorly implemented
  
• Client frustration due to work taking longer compared to a ‘conventional’ M2 site
  
• Major hurdles for significant features such as payment gateways - the working gateways were hardcoded!
  
• Lack of agency portability - good agencies will ironically make it technically easy to change supplier by adhering to industry standards
  
• Missing features - some standard Magento elements simply hadn’t been re-implemented in the headless frontend
  
• Bugs and UX issues - there were clear issues with usability

• Uncertainty over upgrade path and costs - the app wasn’t built using an off-the-shelf solution such as Hyva, so instead all future updates would have needed bespoke work
  
• Server load was unusually high because the frontend made a lot of individual calls to GraphQL - ironically again decreasing performance compared to a traditional site
  
• Deploying changes to the site used a huge toolchain consisting of thousands of lines of code, to a complex structure on the server - in itself a non-trivial system to maintain
  

That’s quite a list! Offsetting all this were only a few positives: theoretically better customer-perceived site speed, theoretically easier to replicate the frontend for a different purpose, quicker and simpler to make basic frontend styling changes. None of those were worth the downsides, so the only major decision point was whether replacing the app with a traditional frontend would be good ROI.

Identifying features and customisations

We started by identifying all the features that had been implemented on the website. This helped us understand the different areas that needed attention during the migration process. We also created a detailed checklist of the tasks that needed to be completed. The website had been through two previous iterations (the Headless and a prior, non-headless version with some legacy functionality being involved), with a large amount of code being kept in multiple places and across multiple repositories, so we had to bear this in mind when creating the rebuild to make sure there were no surprises.

Remove the headless architecture

We converted the NextJS headless frontend to a new, standard Magento frontend theme. We also removed all the custom code that had been implemented for the headless architecture. We thoroughly tested the website after removing the headless architecture to ensure that there were no issues. We also made sure that all the customizations were working as expected.

Bundle Products

Bundle products were one area where the site was heavily customised so we had to migrate this workflow into a more standard setup, which relies as little as possible on third party modules. This reduces complexity and is intended to make the upgrade path smoother.

Multiple Storefronts

The site has multiple storefronts (EU, UK, USA) in addition to trade websites. This added a further level of complexity as we had to test all storefronts and ensure debug some issues with product collections not showing in certain areas.

Frontend Improvements

We had to ensure the new version would be as close as possible in layout and design to the previous version, so that repeat customers would continue to enjoy a consistent shopping experience. For this reason, custom frontend features like the minicart were developed. While carrying out the rebuild, we took the opportunity to rectify some usability difficulties that users were having on the website, for example gallery image arrows staying visible even when there are no more images in that direction, improving mobile breadcrumbs and users making “dead clicks” on sizes that were out of stock but still showing on the frontend. Optimising a website’s usability is not a “one size fits all” process and is something that should be continually monitored and optimised; the new build allows improvements to be deployed more rapidly in response to user feedback and behavioural analytics.

Integrations

The team worked to move a number of platforms away from complicated, bespoke setups, to standard Magento 2 integrations. Setting up third party payment integrations such as Google Pay and Apple Pay had been one area where the headless integration proved to be particularly problematic. While adding Google Pay and Apple Pay options was a simple and standard request from the client, each payment method was hard coded in the headless system and adding a new one was no simple task. It involves creating Logic Layers in XState Machines, adding a Data Layer, and then building the custom UI that the customer would interact with, all of which would require extensive testing at every step. Compared to a tried and trusted module that just needed configuring, this was a huge undertaking.

Optimisation

One benefit headless sites have is the ability to deliver a very fast navigation experience from page to page. Although moving to a traditional theme means there is not a seamless transition from page to page as with a PWA, we went through a period of optimisation using Google’s Lighthouse speed testing suite to identify bottlenecks and how to rectify them. We are continuing to work with Splash About to ensure content added in future is uploaded in a well-optimised way. In order to ensure pages were fast loading, the new theme was stripped back to include no extraneous features, “boilerplate” code or unnecessary third-party libraries.

The website now scores highly on Lighthouse, from a performance score of <10 when ‘headless’ to scores in the 90’s with the Magento theme. The website also now offers users more ways to pay, facilitating a smother checkout experience. Headless architectures often require ongoing support and maintenance from external developers, which can be expensive. If the client does not have the budget for this ongoing support, a headless approach may not be ideal.

In such cases, it may be more cost-effective and efficient to use a traditional, monolithic approach with a standard frontend. This approach is often easier to maintain and update, and may not require as much external support. The lighthouse screen grabs below show a near identical performance between the traditional frontend and the headless version - clearly showing that vendors can utilise a more cost effective solution without the integration and maintenance issues of a headless site. Perhaps headless isn’t quite ready?

Largest Contentful Paint (LCP)

A 60% drop in users experiencing poor LCP, along with a 14% improvement in users experiencing a good LCP. Over 9 in 10 users are experiencing good LCP.

Cumulative Layout Shift (CLS)

20% increase in good GLS, 43% decline in users experiencing poor CLS. Nearly 7 in 10 users are experiencing good CLS - so there is still room for improvement but a massive leap forward from previous scores.

Interaction to Next Paint (INP)

Massive 30% increase in good INP, 66% decline in users experiencing poor INP.