How to build ecommerce websites in 2019 — Hint: static.
More than a decade ago, Greg Linden - who used to work at Amazon - reported a test that is still relevant today. In A/B tests, they tried delaying the page in increments of 100 milliseconds and found that even very small delays would result in substantial and costly drops in revenue.
A more in-depth analysis stated a 1% loss in net sales at each step. Which is more than half a billion dollars (yes, billion) according to the latest stats.
Apart from Amazon's shocking figures, the takeaway is that being fast matters in ecommerce. Users really respond to speed. A better customer experience means higher conversions, especially during seasonal spikes. Think of Black Friday, Cyber Monday, or Christmas sales. For that reason, companies invest large budgets to make their ecommerce websites fast.
From a technical standpoint, speed is all about query optimization and caching. The latter being as powerful as hard to manage in the right way.
There are only two hard things in Computer Science: cache invalidation and naming things.
The point is that ecommerce websites are not that dynamic. Think of a product page, for example. The only data that need to be continuously updated is product availability. Price can change daily, at worst. Title and description may change monthly, if not yearly. Images never change.
At the end of the day, pages become stale only when developers release new code or editors publish new content. So why should we spend our CPU and database resources to serve data that we know to be (almost) always fresh? What if ecommerce websites were just a large cache with easy, instant invalidation?
Enter static sites.
Static sites are the future of ecommerce. By reading this article, you will learn how to leverage the static site approach to build better, faster ecommerce websites. You will see how to mix the best tools to make the perfect stack and workflow. In a way, we are going back to raw web building, as we did in the ’90s. With the difference that table layouts, frames, and rollover gifs are no more allowed — sorry.
What is a static site?
A static website consists of a series of plain old HTML pages deployed to an HTTP server. No database. No server-side rendering. Only files and folders. And since HTTP servers are very good at sending files, making your site static brings many benefits:
Speed
The most noteworthy characteristic of a static site is how fast it is. This is especially true when you host the site on a CDN, serving pages from whichever node is closest to your users.
Scalability
Serving one page or one million pages per day is a matter of paying for more bandwidth, keeping the same speed. More requests mean more pages served, but no extra work in building those pages.
Security
With no queries to run, you can safely forget SQL injection attacks. With no server-side code, you are no more vulnerable to XSS. Static sites are rock solid by design.
Versioning
Keeping more versions of a static site is quite simple. Versioning lets you preview content before going live or rollback changes when things go wrong. All things that your editors will love.
Sounds great, right?
The good news is that you don't have to resume your Dreamweaver or FrontPage CD-ROM (remember that?) to add all those great features to your next ecommerce website.
The rise of static site generators
Static site generators (SSGs) solve the pain of building and maintaining static websites. The list of available SSGs is getting quite long, covering all the most popular languages. So there is a good chance that your favorite one is already included in the list.
Regardless of the language, all SSGs work by taking text files (e.g., Markdown), wrapping them around a template, and creating static pages from that. This process is called the website build. All pages are pre-rendered and copied to specific folders, determining their paths.
CSS pre-processors like SASS or LESS are generally supported. The same goes for JavaScript pre-processors like CoffeeScript or TypeScript. The build produces a site folder with plain HTML, CSS, and JS files, ready to be deployed to the HTTP server.
What about dynamic content?
Dynamic features can be added to static sites through JavaScript and APIs. These can be custom-built or leverage third-party services. This kind of architecture is referred to as Jamstack, where JAM stands for Javascript, APIs, and Markup.
How dynamic?
Whether to import content at deploy time or make AJAX calls from the live site depends on two factors:
- The type of content
- The frequency with which it changes
As a rule of thumb:
- Content that is relevant to SEO or changes with low frequency should be imported during the site build. For an ecommerce website, good candidates are product descriptions, images, and videos.
- When the change frequency is higher or even real-time, content should be fetched on the client-side. This is the case of full-text search, personalized content, inventory levels, and the shopping cart.
Sometimes the choice is not that clear and depends more on your domain and goals. Product prices, for example, can be either imported at build time or fetched in real-time. The former option lets you reduce the API server load, further improving your page load speed. The latter can be a better choice when you have many price lists or want to provide some adaptive pricing mechanism.
Building your Jamstack Ecommerce
Now that you got a quite compelling overview of the benefits of going static let's move from theory to practice. Building the perfect stack for your ecommerce requires you to select some tools and put them together to create a well-orchestrated environment for your team.
Step 1 — Select an SSG
Choosing the right SSG depends on your project's needs and your taste as a developer. First, you can filter the list of available SSGs by language. So if you like Ruby, you may prefer Jekyll or Middleman. Gatsby or Next.js might be the right choice if you love React.js. Nuxt.js or VuePress if you are a Vue.js fan.
The second feature that you should consider is the SSG build performance. If your product catalog is made of thousands of pages, then Hugo is the place to go — pardon the wordplay. Hugo is capable of building 1000 pages in less than a second. Doing the math, rebuilding an entire catalog of 10.000 products, published in 5 languages will take less than a minute.
Step 2 — Select a headless CMS
SSGs manage content data through JSON or YML files. There's no doubt that content editors can't work with text files. They need a CMS with a friendly admin area. What you — the developer — need is a headless one.
As with the static site generators, the list of headless CMSs is getting quite impressive. You can choose by license (open vs. closed source) or popularity (Github stars or Twitter followers). Some of the most popular options include Contentful, Prismic, and Forestry. Scrolling down, DatoCMS and ButterCMS are definitely worth a try.
Step 3 — Add Commerce Layer to the mix
Commerce Layer makes it easy to transform your static site into a static ecommerce site. Prices and stock levels can be either imported at deploy time or fetched on the client-side. All the shopping cart functionalities can be integrated through the API. Whether to link the hosted checkout from your shopping cart page or create a fully branded experience depends on your project's time-to-market requirements and budget.
Step 4 — Build and deploy
Static websites can be deployed in a large number of ways due to the static nature of the generated output. Netlify, Github Pages, or AWS are all great alternatives that you can explore.
Apart from their pricing, you should take into consideration all the additional features that you may need. By using Netlify's deploy hooks, for example, it's easy to set up a continuous delivery pipeline. Publishing content from the CMS or pushing new code to the repo can automatically trigger a new site build, keeping your site updated in near-real-time.
Putting it together
This is how our ecommerce Jamstack could look like:
In the diagram above, merchants, content editors, and developers manage different stages of the pipeline, creating an automated workflow:
Merchants work on Commerce Layer, managing SKUs, prices, stock levels, and promotions. In an enterprise environment, most of that data would flow from an ERP. In any case, merchants don't manage any product-related content, as the platform is agnostic with respect to how products are presented. Product descriptions, imagery, articles, or categories are all managed by content editors through the CMS.
SKUs are automatically imported into the CMS for content enrichment. This flow can be either scheduled (e.g. daily sync) or triggered by Commerce Layer's webhooks (i.e. as they change).
Content editors work on the headless CMS. They get the list of available SKUs and work on the product catalog as they do with any other site content. The CMS can define any content model. The SKU codes link content to the products that are being sold.
Developers work on the SSG, implementing the site layout and navigation as designed by creatives and UX experts. By using the programming languages and tools they like more, they get a better developer experience and can implement any business requirement with no friction — can you do that with Magento? :)
Code changes are pushed to the Git repo. Each push triggers a new site build on the CDN, feeding the continuous deployment cycle.
Content publishing triggers a pre-configured deploy hook on the CDN, rebuilding the site and keeping it fresh.
Prices and stock levels are fetched from the static site Javascript functions. New orders are sent to Commerce Layer OMS to be fulfilled by merchants.
What's next?
We could further improve the workflow by adding more services to our stack. A great tool like Algolia, for example, would bring full-text search and personalization capabilities to our static website. In fact, if it's true that speed is one of the most effective drivers for conversion rate optimization, search is definitely the next in line.