What is the JAMstack?
So instead of PHP, .NET or NodeJS that runs on the server, the server just sends HTML files and CSS/JS/IMG assets.
In 2008 I worked at Kurier, a big news site in Austria. Back then,
processors were not as fast as today, and RAM was still expensive and far from the RAM
sizes we find today on servers.
We still managed to process a large number of page visitors though. This was mostly done through pre-rendering nearly all pages as static HTML files on the server´s hard disk.
Whenever an editor added or changed an article, it was not only stored in the database but the HTML files were generated too.
It was a very efficient system which could handle very high visitor rates without overloading the server.
The JAMstack is similar to that and it enables you to do a lot of cool stuff that makes
operation and programming easier. The biggest advantage compared to the past is that we
With that we can do things that weren't possible in the past, like manipulate the navigation history, store states and even install our website as an app on the customer´s device.
Benefits over a "classic" website
Websites built with the JAMstack can be much faster and speed is the among most important thing for a website. A nice looking page is worth nothing if it doesn't reach the user.
At a JAMstack website the server doesn't need to compile the HTML for each request, it just loads a
file from the hard disk. This has a positive effect on the TTFB (Time To First Byte) time and
the browser knows early on what additional assets will be needed to render the page.
RAM consumption on the server side should also be much lower because we don't need a script interpreter on the server side and the connection requests are completed faster.
On a classic website we can use a proxy cache to achieve speeds that are close to those of static HTML files, but only from the second visitor of the page on. The first visitor will not hit the cache and has to wait until the page is compiled.
Additionally it can be possible to completely build a page without knowledge of PHP, .Net or any
other server side scripting language.
Hosting "just" HTML files makes things simpler. We don't need a server with a lot of power, so the costs are significantly lower and hosting small websites can even be completely free.
A classic website would look something like this:
PHP gets processed, often there are multiple PHP files and database queries on the server side.
With the JAMstack things are different, the pages are generated at the time the website is deployed.
We get something like this:
Dynamic content and Content Management Systems
Elements that are dynamic (e.g. weather data, prices, stock statuses,…) are fetched using
These APIs can either come from an third party provider or from our own servers.
Editorial content with Headless Content Management Systems.
There are websites which you deploy only once and then they hardly change at all, and there
are websites which are intensively maintained by editors.
These editors need a user interface where they can write and manage the content.
This is where headless Content Management Systems come into play.
In principle, they are like normal CMS with the difference that they don't output HTML. All you get from them it is the data served over a REST or GraphQL API.
So with a headless CMS we may have an architecture like this.
Static files from one source and another source for the content data.
This gives us a tremendous flexibility. We get a modular system where the data is
separated from the system that displays it.
Which framework? VueJS, Angular, React, Vanilla JS? DIV, SECTION or SPAN elements? It doesn't matter, do what ever best suits your needs and not what a CMS dictates you.
You can even connect several different frontend systems to it. Browsers, iOS apps, Android apps,
the new fancy device on the market…
Everything can use the same data source.
As I worked at Restplatzbörse we were using Typo3 v7.6 LTS
and we wanted to add a "defer" attribute to a script tag. Unfortunately this is only
possible starting with version 9.0.
An update to this version would have been too much effort at that time.
With the JAMstack it´s a no-brainer, within 2 minutes it could have been done.
Headless Content Management Systems
There are already a lot of headless CMS systems. Directus, Strapi, Prismic, Storyblok just to name a few.
Depending on your needs you could also write your own backend system. In this case you should also separate the API from the backend userinterface.
This is the maximum of flexibility. The backend for content editors is just another "frontend" to the API and offers all the features that we also have at the vistor frontend system.