Headless Shopify: Lessons Learned Building with Gatsby, Part 1

note: you can now read part 2 of our technical learning lessons here

Watch our webinar replay with Gatsby where we go through the entire stack and process of the headless build

—-

That side by side comparison is pretty amazing, isn’t it?

By now you may have heard the term “Headless” or “Headless Shopify” when it comes to the next wave of bleeding edge eCommerce builds. Most modern platforms like BigCommerce, WorkArea, Shopify, and Magento, have their marketing departments pushing this pretty hard as “the next big thing”.

If you’re not fully up to speed on the definition of headless websites, in short it separates your frontend (i.e. the pixels) from the backend (i.e. the machine that does the thing like orders etc) where everything is connected via APIs/SDKs.

It’s definitely a more technical term than those of us that think websites just magically work by themselves :).

It can help you achieve Google performance scores like this (note: I walk through exactly how we dropped from 90+ performance to 70 in our third party scripts overview later!)

If you’ve been reading our blog for long enough you may have previously read our lessons learned migrating from Magento to Shopify post after living in Magento land for so many years. The transition from Magento to Shopify, to me, was a holy s@!# Shopify has really nailed it moment. The headless movement is close to this same feeling of “wow this is going to change things in a big way”.

Our own headless experience actually dates back to late 2017 before Elevar was what Elevar is today. Thomas, our VP of Engineering, and I collaborated on a custom eCommerce project that was probably a bit ahead of its time.

The requirements for us to figure out were basically:

• Connecting to an internal PIM with potential combination of 1 million SKUs
• Having an easy-to-use CMS for the marketing team to manage without having to learn HTML (and yes this includes not having to navigate CMS blocks in Magento 🙂 )
• Connecting to a custom backend for B2B order management

The architecture?

• Prismic
• Vue.js
• Custom API connecting to the PIM to manage real time cached data calls
• Custom backend

It was headless before headless was a buzzword.

Fast forward to July 24th, 2019 and we’ve launched our own Headless Shopify Plus site using Gatsbyjs, Prismic, and Google Cloud – StriVectin – who we migrated from Magento Enterprise.

It’s fast (and could be faster*)!

In the rest of this headless lessons learned, part 1,  I share more on the business and marketing aspects of our experience:

1. Why did Elevar Build a Headless Shopify Site
2. What Are the Benefits of Headless
3. Is Headless the Same as Progressive Web App (“PWA”)
4. Our Headless Project: StriVectin
5. The Discovery & Design Process
6. Third Party Scripts: The Performance Killer (you will LOVE these before/after Google performance score reports!)
7. Third Party Partners / API Management

Be sure to sign up for part 2 where Thomas goes deep into our top 10 technical learning lessons and architecture challenges that you can apply to your own builds.

“Why did Elevar Build a Headless Shopify Site?”

We’re most well known for our Google Tag Manager Shopify app and onsite analytics tool.

So this was a common (and legit) question I got while at Shopify Unite.

The answer for me was simple:

1. Just like we had to build a Shopify site after living on Magento for so many years to understand the inner workings, we believe the industry is going headless which makes analytics that much more difficult to implement, manage, triage, and report on. We need the hands-on expertise.
2. We wanted to build what we consider a best-in-class performance website for an amazing long time customer of ours.
3. How many times can one hear “for every second your page load time increases your conversion rate goes down by 10%” 🙂 ? We consider ourselves experts in onsite performance analytics and site speed performance is a huge part of onsite performance optimization.

And as of today you can’t get any faster than Gatsby.

Thus understanding how to improve site speed is key to our company mission and is part of where we want our expertise and products to fit in to:

When you nail all three of these elements in the illustration above then your onsite foundation is ready to scale.

If you don’t then you’ll be flying blind.  Or worse – missing revenue goals.

We’ve been lucky to work with great partners like Anatta who I believe are one of (if not the) pioneer of Headless/PWA on Shopify (apologies to others that I might not be aware of!). They built Rothy’s, Foursigmatic, among others back in early 2018.

We’ve also been privileged to have other headless customers on our analytics solutions like Inkbox, Kinsley Armelle, Clare, among others.

Each site has their own intricacies. And for me – the data guy – going headless means analytics and tag management becomes much more difficult to implement and manage.

There is no such thing as copying and pasting marketing snippets into the theme.liquid file on headless sites.

And thus: the gap that just recently closed between engineers and marketers, where marketers could get their hands into liquid files to install what they needed, has widened again because this is not possible with headless builds.

We’re going to help with that as part of the future of our product offerings.

What Are the Benefits of Headless

The benefits can be wide and far, but here are a few of my callouts:

• When done right, it’s super fast
• When you go Gatsby, it’s serverless. Which means infinitely scalable and impossible to hack. Remember using Akamai, Fastly, or Cloudflare as a CDN for images and onsite assets? With a serverless infrastructure, these CDNs host your entire site. Plus for non-Shopify stores – the cost savings can be enormous! The $5K/month server costs don’t exist. You only pay dollars/day when utilizing the right headless architecture
• You’re forced to use content management platforms (like Prismic, Contentful, etc) that are more user-friendly for content management
• Your single backend (i.e. Shopify) can serve data to multiple frontends (think website, mobile app, etc) without having to build completely separate
• Organic SEO improvement. If there’s one consistent data point we’ve seen on headless sites it’s that Google seems to really like headless sites with progressive web app (PWA) standards in place. So for stores that rely on non-brand organic traffic and/or have a large amount of SKUs that can rank then this might be your biggest benefit
• Android accepts PWA to Google Play Store as an app (without being a native app)
• More flexibility for the engineering team to innovate features that fall outside of the typical “box” that comes with Shopify themes

Notice how I did not call out conversion rate as a stated benefit. I am squarely in the camp that going headless, alone, is not going to solve conversion rate issues. This is the story that the data tells me.

Now if you are upgrading from a very old, outdated, unusable site to a headless version then yes you will likely see a major lift!

But if you are on a design/theme that performs fairly well for you, and you have ambitions to boost conversion rate by 40% by going headless then I recommend really analyzing your ROI on such a project. What happens if mobile conversion rate only increases 5-10% – or worse it drops which we’ve seen happen as well?  The user experience is just as if not more important.

Is Headless the Same as Progressive Web App (“PWA”)

Many buzzwords have been used to describe sites that feel like native applications, but there is some confusion around the vocabulary.

You install native apps on your phone, typically because the website browser UX is subpar (for example, Slack). Native applications expose many more features and APIs that are unavailable on the web, but browser vendors (like Google) are helping to change that for the better.

Definition: Headless

Headless refers to decoupling the content from the backend service for content management systems (or an ecommerce platform in our case). The content usually consists of html, images, and video. This content is usually provided via an API so that various applications can digest, translate and render that content.

Headless platforms allows for consumers to completely decouple the rendering of the content from the backend service. How many times have simple frontend changes, once deployed caused site outages from an unknown side effect? Or how many Magento sites have been hacked by attackers using the CMS to inject credit card scrapers? This decoupling enables frontend engineers to choose technologies independent from their backend.

In our case, the headless CMS that we chose is Prismic.io. We could have solely used Shopify, but the content management capabilities were lacking given the requirements of the project.

Definition: PWA

PWA are apps that feel like native applications.

They are typically:

• Fast: No whitescreens between clicking links
• Reliable: Allow for viewing the site even when the network is unreliable (think being in the subway)
• Engaging: Push notifications, Installable and more to come as browser vendors push the envelope

A PWA does not necessarily need a Headless platform in order to display content although it is a popular choice these days. It is also worth noting that it doesn’t make sense for every site to be a PWA. For example, we chose not to provide offline support.

Our Headless Project: StriVectin

StriVectin has been a client of ours since December 2017 that started with a Google Analytics audit to clean up broken reporting across multiple channels.

Fast forward to entering 2019 and the thought of having to endure another BFCM on their Magento instance worrying about site performance and checkout stability was not an option.

The Discovery & Design Process

This process is a bit unique from historical eCommerce builds we’ve been a part of before Elevar. Generally speaking the design process would go something like this:

1. Perform UX research
2. Have an in-house UX workshop
3. Parallel path functional discovery (aka what features do we need)
4. Design page by page to present to client
5. Approve pages, build pages (aka templates)

In our case we now have the ability to build components (think sections of mini-blocks of content) that can be plugged into the site in different places we or the StriVectin team would like.

You’ll notice aspects of the site like our product cards look exactly the same everywhere: category pages, recommended products, upsells, blog etc.

Thomas will cover more of these technical details in the part 2 of our headless series (so be sure to sign up to be notified!) but this required a very diligent process going through a granular feature by feature discovery to determine where components may need to live on each page.

The goal is to prevent orphan features or design components that are for one specific use case only and instead design components that can work across multiple page types.

*Third Party Scripts: The Performance Killer?

Scripts, tags, pixels, oh my!

The neverending competition of adding third party scripts that add additional load to the site vs keeping the site pristine and trying to rank > 80 in Google’s site speed scores.

The reality is – you can’t have both.

The more scripts you add the slower your site will be and the lower your score goes.

Does this list of third parties sound familiar:

1. GTM
2. GA
3. AdWords
4. Facebook
5. Floodlight
6. Yotpo
7. Afterpay
8. Dynamic Yield
9. Swell
10. Zendesk
11. Listrak/Klaviyo
12. Shoprunner
13. Rakuten
14. Hotjar
15. etc…(there are hundreds of these important services!)

And most all ask for their script to fire “as high as possible in <head>”.

Below is a screenshot of our custom Lighthouse audit (aka Google Page Speed Test) we built to monitor our development site during the entire project.

Why? So we knew exactly when a deployment or third party caused a spike in pagespeed and thus a decrease in our Google performance score so we could address before launch.

For even more before/after data, this is a before and after Google Performance score after adding one single third party global Javascript (!!):

Before:

Note the score of 94 and speed index of 1.8s:

After:

Note the 16 point drop to 78 and addition of 1.7 seconds.

1 script, 16 points. Crazy right?

Our team made a point to run a before and after lighthouse test on EVERY SINGLE THIRD PARTY that we had to add to the site.

I’m still bleeding from the battles trying to convince how important third party scripts are for marketing and feature sets (e.g. we can’t rebuild a Yotpo, Dynamic Yield, etc). Sites don’t convert themselves!

To articulate this pre-launch performance analysis point even further take a look at this breakdown across pages where we ran speed tests pre-launch including/excluding various third party scripts. We wanted to understand what the site looked like without any third party script along with the impact of each individual & total additions:

What does all of this mean?

There are a few things during a build and evaluating third parties that you will want to consider for yourselves:

1. What third party scripts are truly needed? Can it be built cheaper?
2. Do they have to run on every page?
3. Do the third parties have API integrations vs using their global javascript tags?
4. How heavy is their global javascript tag? Are we only using 5% of the JS functionality in the entire script?
5. Do they need to fire on page load or can they be delayed?
6. Can they fire last on page?

One real example of putting this process into place is the global Zendesk live chat tag.

This single (live chat!) script brought our score down by 15 points.

What did we do? GTM to the rescue of course.

We set this to fire on a timer after 3 seconds on each page:

We saw Google respect this change in their scores and will likely be adding more in this manner.

Third Party Partners

We worked with some great partners during this build that we’ll be digging into more about their unique implementations in our part 2 article.

In general – be prepared to educate your third party partners on the type of build you are executing. Without this then you risk the assumption of the’re thinking a standard Shopify theme vs the reality of it not working this way. This means more time, budget, delays etc.

A few callouts that I thought were really awesome:

1. Recharge: they immediately got us into their new checkout API and theme engine that allowed us to create checkouts on the fly based on the contents of our cart on Gatsby. This allowed us to keep our complex samples feature in the cart and split off Shopify or Recharge checkouts based on the condition if a user had a subscription product in their cart.
2. Dynamic Yield: after showing Charles (everyone knows Charles, right??) the staging site at Unite and explaining the headless architecture he immediately directed me towards their new API based implementation method (vs global JS tag). This is what every software provider should be building towards to risk not being left behind in the headless world.
3. Yotpo: they already had a fairly robust API based solution that helped expedite the implementation process in many ways. We did not end up going with the implementation of pulling reviews via API and including in our build process for a few requirements-based reasons but we did it pre-launch and it worked great.
4. Swell: this was and still is one of the trickier setups since the loyalty rewards relies so much on the Shopify cart for product redemption. We’ll share more on how product redemption was moved into the checkout which I hadn’t seen done before (I could be out of date here..).
5. Listrak: their global script was the least-heavy in the integration process (no change in performance scores) and allowed us to implement all ecommerce events fully through GTM.

Wrap Up

We have A LOT more to share on these implementations and the technical hurdles in part 2.

If you haven’t checked out the site yet – please do so here: https://www.strivectin.com/.

And don’t forget to sign up for part 2!

• Shopify