Jamstack is now more popular than ever due to its promise to deliver better performance and scalability than 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 Jamstack advantage of delivering HTML from CDN outperform everything?
The Modern Jamstack Approach
A big part of the typical Jamstack site is usually made with one of the popular front-end 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 is being pushed to the CDN edge.
With these frameworks comes fantastic flexibility for the frontend developer, but also a 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 gets 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 an 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 that it no longer takes up that many 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 article is not making an argument against a frontend framework running on a device. The approach is still great for:
- Faster route transitions
- Complex client-side logic
- Development speed
I invite you to use our Next.js eCommerce storefront boilerplate and play around with the capabilities of Next.js.