The Jamstack: pushing website performance

Over more than 20 years, we’ve been writing software and building digital platforms for clients. The technology we’ve used has changed rather a lot over that time.

There are some members of the technical team who will sigh wistfully if you mention things like ‘Classic ASP’ or ‘frameset’ – but I think everyone agrees that the tech and the tools we now use are far more capable than what’s gone before.

One approach we’re using more and more is building sites on what has become known as the Jamstack – Jam standing for Javascript, APIs and Markup.

Yes, it’s a stupid name, in the time-honoured tradition of techies naming things, but what it allows us to do as a technical team is rapidly build and deploy very, very fast websites that are simple to host and run.

What is it?

The official definition is:

Fast and secure sites and apps delivered by pre-rendering files and serving them directly from a CDN, removing the requirement to manage or run web servers.

In practice, we tend to use a combination of the following tools:

• Gatsby, a framework built on React that generates static files
• A range of headless content management systems, depending on the project
• Netlify, for hosting, depending on the project

How does that work?

React is our framework of choice for front-end applications, so Gatsby is a logical choice given the existing familiarity with React within the team.

Gatsby is highly focused on performance – not just because it generates static files, it also does a whole bunch of other very clever stuff designed to help make sure your Lighthouse scores are as green as can be.

Gatsby is capable of ingesting content from pretty much anywhere via its source and transformer plugins – any headless content management system that provides GraphQL APIs will be very straightforward to integrate with.

Our typical pattern for this is to pull most content at compile time – massively reducing load on the content management system as it is not required to serve content to end users, only to our build agent.

Once the site has been compiled by Gatsby, it can then be deployed to Netlify. When the site is loaded by the user (including the statically-generated markup) – the Gatsby Javascript bundle turns the static markup into a full React web application, capable of manipulating the DOM and doing all the other fancy things you’d expect from React, including pulling additional data in from APIs.

Any downsides?

There are a few issues with using this approach.

As much as it’s lovely to not have to worry about web servers, some of our clients aren’t able to use Netlify or similar platforms. We have sidestepped that in some instances by hosting the static files in containers running NodeJS – rather than a CDN – which still enables us to benefit from the speed advantages of Gatsby.

Another issue is that this approach is potentially complex to integrate with more traditional content management systems and the visual editing, personalisation and analytics features that they offer – although it is possible with framework like Sitecore JSS and AEM SPA Editor SDK.

There is also another potential gotcha – the JAMstack means front-end developers have greater control than ever before. That’s a good thing – front-end developers are pushing new tech forwards, which is exciting – but it also means that they are now having to deal with areas that might traditionally have once been the domain of a back-end developer.

Especially at Great State, where we have a wide range of clients who can’t always use platforms like Github or Netlify – our front-end team are having to get far more up to speed with build pipelines, containers, best practices around setting security headers, and the like. This is a good thing – but definitely something to be aware of.