If any page on your site takes more than 3 seconds to load, 53% of mobile visitors will leave.
That’s over half of your (increasingly expensive) traffic.
Gone before they see a single pixel.
Having the fastest possible site speed is no longer a nice-to-have. Nowadays, it’s a basic consumer expectation.
Amazon calculated that a one second slowdown in page load would cost them $1.6 billion annually. Your numbers will be different, of course, but their calculation makes a point that applies to us all:
A slow website leaves money on the table.
Initial load and page-to-page load times influence several key outcomes like bounce rate, engagement, click through, time on site, conversion, and more.
This isn’t breaking news, though. You’ve heard this before, so maybe you’ve already invested in incremental adjustments here and there. But is your site as fast as this?
Four Sigmatic: slowed down for emphasis
Initial page load: 0.95 milliseconds
If you aren’t achieving a load time of less than 2 seconds on every page, odds are good that you’ve made speed hacks, not speed improvements.
And while we all love a good performance-enhancing workaround just as much as the next guy, band-aids won’t ever produce the results you (and your customers) need.
A blazing fast site (aka: remarkable customer experience) begins and ends with how you architect that site.
We’ll prove it.
Click around and you’ll easily find 1000+ articles telling you how to improve the performance of your website. The best articles will tell you to do four things:
- Decrease the size of each http request
- Decrease the number of http requests
- Prioritize the http requests you do make
- Serve requests from the fastest servers, closest to the end user.
And the articles are 100% right.
If you do those four things, you’ll undoubtedly get a faster website. For basic websites, implementing this four-step process is the most straightforward way to improve site speed.
If you’re an eCommerce brand living in the world of Shopify Plus, Magento, or BigCommerce, you don’t have a basic website. You have an eCommerce platform. For you, checking off these four steps is easier said than done.
Conventional eCommerce platforms are built on a frontend architecture that makes tackling those four steps very difficult, and sometimes impossible.
So what can you do to get the site speed that keeps customers on your site longer, and converting better?
With a few more clicks, you’ll find even more articles detailing how to improve site speed on your specific eCommerce platform. The list of suggestions will include things like:
- Use pop-ups sparingly
- Beware of liquid/php loops
- Decrease thumbnail image sizes
- Use less apps so that they include less JS
- Compress and reduce images in size and number
- Minimize your code
- Reduce broken links and redirects
- Use Google Tag Manager for snippets
- Try adding Lazy Load
- Add Google AMP through an app
Back in the early days here at Anatta, we followed those instructions. We implemented all of these things but time and time again, the impact to performance was negligible.
Load times went from 8 seconds to 4 seconds, and maybe that sounds remarkable, but in today’s market, a 4 second load time is far from impressive.
Less than 2 seconds. That’s how fast initial and page-to-page load time needs to be.
Less than 2 seconds is the bare minimum. The ideal number is less than 1 second, because Amazon has made this the gold standard customers have come to expect.
But if you’re plugged into Shopify, Magento, and the like, you won’t be able to bring your load times to > 2 seconds with the typical suggestions mentioned above.
eCommerce speed problems can only truly be solved by reshaping the architecture your site is built on.
So once you’re clear that your theme architecture needs an upgrade, where do you go from there? There are two possible paths:
Scenario 1: Performance Architecture for Shopify
Scenario 2: Headless PWA
Scenario 1: Performance Architecture for Shopify
If your site is hosted on Shopify Plus, Shopify’s servers process all your eCommerce and marketing data, and then present that to visitors using the Shopify theme engine.
The theme engine has to accommodate stores making $100 per month and ones making $50 million per month. In order to operate well across that wide range of use cases, the engine is inherently extensible and robust. That’s the upside.
But there’s a downside.
The best software architectures are robust, maintainable, useful, scalable, agile, extensible, and perform to a high standard. But no software architecture is 10 out of 10 in every category – when you increase one attribute, you generally reduce another. This is why benefits like being maintainable and useful inevitably come with disadvantages like performance reductions.
Shopify’s theme engine has many perks, but nothing is extensible, robust, and fast all at the same time – something has to be sacrificed.
At least, that’s how it used to be.
Until we developed Performance Architecture for Shopify.
Kosas: slowed down for emphasis
Initial page load: 1.65 seconds
Anatta’s Performance Architecture for Shopify is different from the traditional Shopify theme because it:
- Fetches eCommerce data using Shopify storefront API
- Relies on a separate content management system and fetches data using Shopify node API
- Leverages Webpack to compile dynamic components into static files.
Technical Details on How Performance Architecture Works:
- Retrieving data stored about the catalog using Shopify Storefront API is a faster action than leveraging Liquid. In addition, that data can be used with JS Frameworks like VueJS and ReactJS.
- Retrieving data stored about a Page using Node API from a CMS in the form of JSON makes the data load faster. In addition, that data can be used with JS Frameworks like VueJS and ReactJS.
- Webpack helps to create optimized static assets (IMAGES, CSS, and JS) and also helps to generate assets to split JS and CSS based on pages.
Allbirds: slowed down for emphasis
Initial page load: 1.16 seconds
However, Performance Architecture does limit the features you can develop, and how third party integrations can be implemented within this ecosystem. For those reasons, Scenario 2 might be a better fit for you.
Scenario 2: Headless PWA
Shopify, Magento, Salesforce Commerce Cloud, and other eCommerce platforms, load uncached content, which makes data retrieval inevitably slow.
Relying on uncached content is like playing poker with a dealer who has to slowly hand out all 52 cards in the deck before the game can start. And as that 53% stat above tells us, users are simply unwilling to wait around for all that.
When you migrate to a headless architecture, your eCommerce system continues gathering data on your products, orders, etc, but it’s not handling (and restricting) the frontend anymore. Most of the page content, including dynamic elements, is coming from cache.
On top of that, headless can be run as a single page application (SPA), so once the first page loads, all other site pages are immediately available. There’s absolutely no load time as the user moves from page to page, creating the seamless experience of a native app – but in a web browser.
Molekule: slowed down for emphasis
Initial page load: 1.68 seconds
In a headless architecture, we’re leveraging:
- Vue.js and Nuxt.js
- Node for caching layer
- Shopify Storefront and Admin APIs
- Prismic (Content Management System)
Technical Details on How Headless Works:
- Hosting applications on the EC2 servers provides a huge boost in Time To First Byte (TTFB). In Shopify, this is usually 1-2 seconds. On EC2 servers, it drops to 200-300 milliseconds.
- Adding a cache layer for presentation and data drastically reduces response time.
What Do You Need To Design & Build This Architecture?
A team that understands the underlying architecture of your eCommerce platform(s), and most definitely, a team that has a track record of performing this work with consistently positive results.
Performance Architecture design and implementation requires a high skillset. This is the next level of eCommerce development, which means you need highly skilled engineers.
We can objectively say that this is the team at Anatta.
Here’s What We Teach Our Dev Team:
- Don’t engage in a large refactoring project unless you can guarantee above-average results.
- Create a plan that results in 1-2 second load time.
- Ensure all stakeholders are clear on the benefits and responsibilities of going headless (mainly, owning your hosting).
- Leverage the best and most current technologies that offer significant support and adoptions (for example, VueJS in 2020).
- Be prepared for healthy scrutiny from your team members. Every keystroke in an architecture change must be based on clear, well-developed reasonings.
In today’s eCommerce landscape, 1-2 second site speed is not a luxury – it’s a necessity. But temporary speed hacks are a misuse of time, talent, and money. The most effective way to permanently improve site performance is either by designing a Performance Architecture for Shopify, or migrating to a Headless PWA.