JAMStack is now more popular than ever due to its promise to deliver better performance and scalability than the traditional server rendered websites. Still, when comparing performance to a traditional server-rendered site, many JAMStack sites lose, leaving the end-users worse off. Why is this happening? Shouldn’t the JAMStacks advantage of delivering HTML from CDN outbeat everything?
The modern JAMStack approach
A big part of the typical JAMStack site is usually made with one of the popular frontend frameworks, like Next, Gatsby or Nuxt. As all of these frameworks enable developers to create rich, interactive websites with pre-rendering of pages, the HTML being pushed to the CDN edge.
With these frameworks comes fantastic flexibility for the frontend developer, but also great responsibility. It’s important to know that the framework is doing two completely different things:
- Prerendering. Creating pre-rendered HTML pages, with CSS and JS, ready to be pushed to a CDN
The modern JAMstack approach looks like the best of both worlds, and in many cases this is true.
There is however a hidden problem lurking beneath the surface.
A bunch of websites get a big performance penalty in step 2, interactivity. It is often overlooked when developing a website since it typically affects mid-range devices on mobile networks, not what the typical developer is testing on.
How big is the problem? Let's use Pagespeed Insights as the tool to measure performance and the blog you are reading right now as the example. Here’s how it performs with framework enabled interactivity:
A score of 63 is not terrible, but when looking at the lab results, it’s clear that we can do better.
The Single Page Application (SPA)
This takes up CPU resources on the device, as well as additional download costs as the framework files and application files need to be acquired. This process can take several seconds to complete and is especially prominent when the visiting user is on a mid-range mobile phone and on a mobile network.
Look what happens if we turn off step 2, and deliver just HTML and CSS:
Now that's a massive difference. The reason it’s scoring so much better is because it no longer take up that much resources on the device:
This is what gives the best performance and user experience for our visitors.
In an ecommerce store, users want to find and buy things. At a blog, users want to read.
This is not an article making an argument against a frontend framework running on a device, it is great for:
- Faster route transitions
- Complex client side logic
- Development speed