Back to Blog
Desk setupDesk setup


October 2022 — 15 min read

Jamstack 101

In this fast-evolving world, keeping up with all the new concepts and tech releases is a challenging task. Website development in particular is no stranger to this rapid evolution. A concept that will stick around is Jamstack websites - setting up new standards in terms of performance and digital experience.

How did you end up here?

You are interested in this article for one of the following reasons:

  • Understand what Jamstack is.
  • Learn the advantages of Jamstack over a traditional approach for your website.
  • Understand what more advanced concepts like SSG and ISG are (hint: we are still in the tech world not in the medical one).
  • You are just curious and always want to learn more about modern tech!

This article explains what Jamstack is and what it can bring to your organization without needing a Computer Science degree. Bear with us, it is actually quite simple!

Architecture of a Website

First of all, it is important to understand that Jamstack is what techie people call an architecture. Similar to how an architect will plan how to build your house, a Web Developer will plan how to build your website. Of course, every website has a different objective, but its architecture establishes guidelines and best practices, which developers should follow.

In order to understand the Jamstack architecture and how it is relevant for today and the many years to come, let’s first illustrate what a website is in simple terms.

Client and Server

When visiting a website, 2 applications communicate together: the Client and the Server. The Client is your browser (e.g. Google Chrome) and the Server is an application usually accessed through the Internet which is just sending files to the browser. These files are then interpreted by the browser to display the website and showcase those cool animations. Simply put, that’s how every website works!

Client and server schema

History of Web

The Jamstack architecture, as crazy as it may sounds, partly takes inspiration from how the first websites were built. To understand how these old patterns are leveraged in a modern and dynamic way, let’s quickly review the history of Website Architecture.

The Web 1.0

The first websites were often very simple and not very interactive. Each page was composed of one or a few files stored on a Server, so each page was very light in terms of processing. One of the main pain points of this approach was that there was a lot of code duplication, making it hard to maintain. If you wanted to add a link to the main menu, you needed to update every file of every page. Even for basic websites, the time spent on maintenance was daunting.


The Web 2.0 (or Server-Side Rendering)

As the Web became more and more popular, more businesses and more complex use cases arose. The most common and relevant use case could probably be marketing people wanting to be autonomous when tweaking websites and not relying on developers for most of the updates. This need led to the introduction of a new tool, a CMS (Content Management System). Ever heard of Wordpress? If not, it is the most popular CMS.

Let’s take a Blog website built on Wordpress as an example. Each blog post is stored as data such as: Title, Page Content, Number of views, etc. When a user wants to see a Blog Post, the server is going to build a webpage from this data every time its requested (hence the term SSR or Server-Side Rendering). If we later add a blog post in Wordpress, this will result in the creation of a new blog post page, but it will also impact other pages like the home page (as this latest blog post would also need to appear here). The main change here over the Web 1.0 is that the pages of a website are no longer just files sitting on the Server and being delivered to the Client - they are dynamically rendered every time they are requested.

As we can understand, this is not always efficient and scalable, as identical pages may need to be generated multiple times for different people. It also requires a lot of work for the Server application, which needs to generate pages for each visitor of the website. This is one of the reasons why those websites, if not optimized properly, tend to be slower as more users visit them.

To illustrate this idea, let’s take a restaurant. You want to open a small fast-food restaurant, which represents the Server application. Each of your customer is a Client application. The burgers you serve act just like pages on your website. If you order a plain Burger, you will surely receive your order quickly, as the restaurant would just need to cook the bread and the meat, and then assemble the burger before serving it. What if we add onions, ketchup and bacon? Your burger is probably going to be ready quickly, but it will be longer to prepare. Now, what if we have a fancier version of our burger? The preparation time will certainly be even longer due to more complex representation of the product. A month later, as a now popular fast-food restaurant, there are now 100 people ordering Burgers at the same time. They will surely now wait much longer to receive a fancy Burger. You are now in a situation where you need more staff working behind the scenes or you need to review how you produce burgers. You could also have planned for these scalability issues from the very beginning…

What we're trying to illustrate here is that as your website evolves and becomes more complex, it will get slower. For example, you could also want a cool plugin on your home page that displays Instagram posts. It will have a large impact on your website since it now needs to ask Instagram for the latest posts every time a user checks the home page. Websites like Wordpress often offer many plugins, and each one adds processing time and makes the page load slower. Basically, every time you ask your website for more, you will get closer to the Server application limited capacity and, much like the 100 burgers example, the more people asking for pages at the same time, the slower it’s going to be. Before Jamstack, to mitigate this performance bottleneck, you would need to review key architecture elements of your website and add more Servers, leading to costly investments, some of which may be recurring.

The Jamstack Architecture - The future of Web.

Of course, a Jamstack website will eliminate or at least greatly mitigate those issues and extra costs. This new architecture norm combines principles of both Web 1.0 and Web 2.0 to maximize the pros and minimize the cons of these approaches. To start simply, let’s go back to our Burger example with a website built with Jamstack. Ordering a plain burger, you would get it straight away. Just like with the Web 1.0, each page is just a few files on a Server. What about the fancier burger? Same experience, you would get your burger instantly. What if 1000 people order the fancy burger at the same time? Still the same experience, you’re going to get your Burger near instantly.

Wow… How is this possible? First, think of a Jamstack website just like a Web 1.0 website built using modern practices. The key here is to generate files that can be served by a simple Server, just like a Web 1.0 Server. Instead of dynamically building pages (files) every time they are requested, the server is only responsible for transferring static files when a request is made, which results in very fast and instantaneous load times. As you add more data and features into your pages, these static files remain very light and quick to transfer.

But, how does it work if you create a new Blog Page for a Blog? A Jamstack website usually rebuilds itself when some data needs changing. A rebuild means that some pages or all of them need to be rebuilt so the new content is made available to users. In our example, the full website is either rebuilt, or thanks to modern frameworks, only the relevant pages with updated data can be smartly rebuilt.

In contrast to a Web 2.0 website, which would do the page generation work on every request, a Jamstack website does this heavy-lifting work once when the data changes, and then simply serves the generated files like a Web 1.0 website.

The Server-Side Rendering schema

However, as website needs are varied, most Jamstack tools add the following concepts, so they can cover all possible needs.

ISR or Incremental Static Regeneration

For websites that change often and that would need to rebuild quite often, Incremental Static Regeneration can help. Even though this seems complicated, this concept means that instead of waiting for a data change to perform a website/page rebuild, it can happen at a specific interval of time. The page is still generated as a static file that is served almost instantly, but it would be updated automatically after a set delay. This approach is not only very useful for websites that depend on data that changes often but also when rebuilding on every data change is very expensive for the Server.

SSR or Server-Side Rendering

Of course, the Jamstack architecture doesn’t solve all the known issues and Server-Side Rendering remains sometimes useful. For example, when you login on a e-commerce website to see your past orders, this data is specific to you and thus the page showing it can be rebuilt every time you visit it. It would be quite expensive to generate this page for all users all the time, so generally those pages are served using SSR, even though most of the website leverages Jamstack.

What’s in it for me and my business?

Performance and user experience

So far, we talked a lot about the performance improvements of this modern architecture, providing performance that feels instantaneous, no matter the device (web or mobile) or the number of real-time users. This can easily suit use cases where graphic, motion design are pushed to the limits, but also when offering a personalized and instantaneous e-commerce experience. Of course, performance is not the only benefit of architecting your website with a Jamstack approach.

Better Rankings on Google (SEO)

A better performance also means a better ranking on Search Engines like Google. Performance is now being taken into consideration when being evaluated by Google, especially on mobile devices. Thus slow and unresponsive websites will rank much lower.

Stronger User Conversions and Higher Revenues

No matter how you design your funnels and calculate user conversions on your website, high-performing websites usually keep users on their website for longer and considerably reduce churn rate caused by longer load times. Additionally, Internet speeds have increased in the last years, but a lot of people now interact with Brands using mobile phones, which may not offer a reliable and fast connection. Depending on the regions of the world you are targeting, even desktop computers may have trouble getting access to a good internet connection. Here are some stats that show how a high-performing website can increase revenue for an e-commerce website:

Source: Milliseconds make Millions, Deloitte

Be Near Your User

When talking about Jamstack websites, we often hear the term “hosted on the edge”, but what does that mean? In short, your website will be served from a server as close as possible to your users. For example, if you go on a website from Montreal (Canada), a server near you will serve the web page, while another user in Paris (France), will get the same web page from a server located closer to them. This results again in fast load times, even for users who are far away from where your business is operating.

Hosting providers such as Vercel, Netlify and Cloudflare offer this at a cheap cost since Jamstack websites are mainly composed of static files. These providers then simply need to duplicate these files on different servers throughout the world. Some providers even serve websites from over 250+ different locations!

Way Cheaper Operational Costs

With previous web architectures, websites required more and more resources as the user base grows, with each user requiring a certain amount of processing power. To ensure good performance of the website, many powerful servers would be needed. This can result in very high costs.

Jamstack, on the other end, only rebuilds its data when it needs to, or can use ISR to refresh itself at a fixed interval. This can easily scales up to millions of users without much impact on the server, as the server only serves files, requiring no computation. Even more importantly, since Jamstack websites are usually “performance optimized by default”, adapted hosting solutions such as Vercel, Netlify and Cloudflare are way cheaper, when compared to traditional providers. Jamstack websites achieve all this while also providing constant and near-instant performance, which benefits you and your user base.

More Security

Jamstack websites tend to be more secure, as they usually expose less sensitive information to potential attackers. Jamstack websites usually interact with systems from the server (and this does not happen on the client/user side), making it invisible to attackers. Certain websites interact with other systems from the client/user side, which reveals a bit more of the architecture to the hackers.

Jamstack websites are also less prone to DoS (denial-of-service) attacks, which consists in overwhelming a server with so many requests that the website becomes unreachable. Since servers are not overwhelmed at all when delivering static websites and most hosting providers have built-in DoS protection at no extra cost, DoS become less feasible on Jamstack websites.

A Greener Option

Nowadays, environment is an important concern that impacts a lot of different industries, including IT. A Jamstack website is usually a much greener option over standard websites for a couple reasons:

  • The website doesn’t do much processing for each request and only does processing when the data changes, therefore reducing the amount of electricity consumed by the server.
  • The website performs better, so users spend less time waiting for a page to load.
  • Jamstack websites hosting providers are for the most part using green energy to run their servers.
  • Most tools used to develop Jamstack websites come with extra out-of-the-box optimizations to reduce the size of your website (bundling and minification of code, media assets optimization). This results in faster load times, but also in optimal usage of data and in general of the whole Internet infrastructure.

TLDR - Why you should use Jamstack?

In short, Jamstack is a way to build websites that brings:

  • ⚡ Performance that feels instantaneous
  • 🔍 Better ranking on search engines (SEO)
  • 💰 Higher user conversions and revenues
  • 🌍 Less latency for users around the world
  • 💰 Cheaper operational costs
  • 🔒 Stronger security
  • 🌱 Environmental friendliness

Interested in assessing the Jamstack potential for your business?

Let's connect!

© 2024 Trampoline Technology Inc.