JAM Stack: What is it (exactly)?

We are often asked: "What is the JAM stack? This is reason enough to write a blog post about it and answer the most frequently asked questions. In a nutshell: The JAM stack is the modern way to programme websites and web apps, which have a much better performance than conventional methods.

Samuel Rhyner - 16. July 2021



JAM-Stack (or Jamstack) or "Stack" in technical language is a combination of several technologies (JavaScript, Apis & Markdown). In other words, it is technically incorrect to compare "JAM-Stack" with "WordPress", for example. WordPress, however, runs on the "LAMP stack" and thus one can compare "JAM" with "LAMP". WordPress is simply one of many CMSs that run on the LAMP stack. There are also many different CMSs on the market for the JAM stack.

What is the JAM stack?

JAM stack is an architecture specifically designed to make the web faster, safer and easier to scale - and historically this is "back to the roots". Basically, the load that would normally be handled by a server is transferred to the client computer, or done in advance for all of them. In doing so, the server regenerates the entire page every time the content is changed (virtually visits all possible pages and saves what is seen) and thus takes a lot of traffic away from e.g. the CMS.

But step by step.

There are three basic principles, which we will look at in more detail here: Prerendering, decoupling and CDN.


One of the biggest changes for the site owner(s) is probably prerendering. You can think of it as follows: If there are changes in the content (e.g. a new product page or a spelling mistake in a blog post), the server regenerates the entire website. In other words, a virtual user visits every visible page of the website. During the visit, the user saves the HTML code, the images, the texts, etc. These files are stored in a folder structure. These files are stored in a folder structure where they can be found again. After a few (3-5) minutes, the page is then "deployed", i.e. live on the internet.


This principle is a paradigm shift. After the prerendering approach, some may ask: "What about dynamic content"? Good question! When you visit websites, there are always parts that are tailored exactly for you (e.g. your username at the top right or suggestions based on your shopping cart). This information is retrieved from a special API and then inserted into the page. This creates a complete decoupling of the server and the user (front and back end).

APIs are becoming increasingly popular and there are more and more services that make their data available via an API. Most CMSs that are used in connection with a JAM stack website are so-called "headless CMSs". This means that their content can (only) be accessed via API.


The CDN (abbreviation for Content Delivery Network) is a system of servers that have only one job: As soon as a request comes in, a predefined file is delivered. With the conventional LAMP stack, the file had to be calculated first. However, the CDN cannot do that at all. That is why the website was "prerendered". And it goes even further: because the file does not have to be calculated, the server is lightning-fast. Again: FLASH-FAST!!! And that all over the world, because it doesn't matter whether the file comes from the server in the USA, Holland or Switzerland. This means that the page is still surfable to some extent even with crappy mobile connections.

What are the advantages of a website built on the JAM stack?

The new approach is all well and good, but what are the benefits of a website built on the JAM stack? There are many advantages that speak for the JAM stack. There are also a few disadvantages, which we of course also want to bring up. But first to the convincing arguments.


Websites on the JAM stack are fast. Very fast! And if they are hosted on a CDN, they are "blazing fast"! :) With the JAM-Stack websites, we achieve a Google Light House average of more than 85/100 points without much optimisation. And with a little optimisation, we easily achieve 95/100 points, which is far above the average.

The speed is very noticeable, especially for mobile users. Websites that load quickly are statistically visited much longer. Google also ranks websites that load quickly much better.


The JAM stack has banished many vulnerable parts. The infrastructure of a page is kept to a minimum. Since the website is delivered by another server instead of the CMS server, attacks cannot be launched at all. It is therefore only a big challenge for attackers to recognise which CMS is used for the site. And since most CMS are "rented" as SaaS (Software as a Service) they have a high interest in protecting the data.


JAM-Stack websites are very resilient and robust. Due to the decoupling of front-end and back-end, operation is possible even if parts of the website are under maintenance or have errors. In addition, the request is not only directed to a server, but also to a load balancer.

The immediate invalidation of the cache also ensures consistent operation when content changes. This ensures that the latest version is displayed on all end devices! No more cache problems when testing a website.


You might think: Why should my site be able to scale well? Swiss companies in particular do not usually have major scaling problems. However, there are always cases where websites are not accessible because too many users want to access them (classic: unbeatable offers / tickets / etc.). And here comes the trick to scaling with the JAM stack: watch! The CDN is designed to let the site scale. As an operator:in, the most you have to do is buy a few data volume packages and check the APIs for functionality if a lot of traffic is generated. The rest is done by the system "by design".

With conventional websites, scaling was not so easy to achieve. Providing several servers with a load balancer and then ensuring data sovereignty were challenges for entire IT departments.


A running JAM-Stack website requires virtually no maintenance. Once the website is up and running, there is no need for developers to constantly maintain the site. It certainly makes sense to update the code base to the latest updates every now and then. However, this is not half as urgent as with a WordPress website, which may have major security vulnerabilities.

Rein in

Dissatisfied with your hosting? Slow CDN? Company goes bankrupt? These are cases that can happen. But it has never been easier to rein in a website than one built on the JAM stack. If it is prerendered, then you take the files and place them where you want them. Done. Copy - Paste.

Does an API fail because, for example, the mail service provider stops operating? There too, it has never been so easy to choose a new service provider and adapt the requests.


The frameworks and programming languages for the JAM stack are very programmer-friendly. You may not be interested in this as a customer. However, this has its advantages:

  • We can deliver bug-free code if we enjoy the development.

  • We are faster which results in lower costs.

  • We benefit from the community, which also enjoys simple development.

  • We are effective and efficient.

Are there any disadvantages?

As already mentioned, there are also a few disadvantages when we talk about the JAM stack. It should be noted, however, that we as developers do not see these as a "red flag" because it gives us more options.


Precisely because everything is decoupled, certain things become slightly more elaborate. For example, sending emails is exactly one line of code on a PHP server - simple. With the JAM stack, we either have to develop our own solutions or access service providers like SendGrid. The same applies if we need to store data or authenticate users, for example.

However, this approach is very forward-looking: If one is no longer happy with a service, it is easy to change it. If a component in a complete solution no longer fits, a lot of rebuilding is needed.

Presets & Plugins

The JAM stack world is relatively young. There are not yet as many presets and plugins as is the case with other website solutions. However, the longer the better.

It is also relatively difficult to "just install a plugin" and immediately have new functions on the website. But this is also evolving and we will see what the future looks like.

Real-time & user data

The JAM stack approach is not very well suited when it comes to handling a lot of user data. Facebook, for example, is not built on the (classic) JAM stack because too much data changes at the same time. It helps to turn a website into a web app and thus activate these possibilities.

Does the future belong to the JAM stack?

Although the JAMstack architecture is an integral part of modern web app development, it is not a one-size-fits-all solution. There are definitely cases where this approach is not appropriate. we do not use the JAM stack for every project. But these dynamic websites cannot compete with their JAM stack counterparts in terms of speed, performance and security. However, the ecosystem around the JAM stack is evolving and will eventually make up for the limitations as well.

JAM stack is not a buzzword that we will have forgotten in a few years. It is the future. Just like dynamic development. If you are interested and looking for JAM stack outsourcing developers, our team can analyse your case and bring the most complex idea to life! Write to us and we'll get back to you right away!

Samuel Rhyner, Gründer von Code Crush

Samuel Rhyner

I am Samuel. My world revolves around programme code most of the time. I love understanding stubborn problems and finding solutions for them. I like to be on the train and work best when the landscape is passing me by at 130 kilometres per hour. To switch off, I like to watch real-fiction series - and hate being spoiled. If I have to wait for the stream, I always make a mental note to myself: my applications are programmed with high performance and the waiting times are as short as possible. They are the TGVs among the programmes!