Skip to main content

Differences Between Jamstack and Conventional Websites

· 4 min read
Diverta

This section explains how websites built on Jamstack differ from conventional sites.

What is a conventional website?​

In this guide, a conventional website refers to one implemented with the following basic server architecture. There may be some variations depending on the specific case: for example, PHP websites have an integrated HTTP server and application server.

Web (HTTP) server​

Receives a request from a web browser and calls the application server. It then receives the HTML and returns it to the browser. Some web servers hold static content and return the HTML and images unchanged.

Application server​

Receives data from the web server and exchanges information with the database server. Subsequently, it generates the HTML and sends it to the web server.

Database server​

A database server stores the information on users, products, contents, etc. It returns the requested data when called by the application server.

Before the advent of web API-based sites, the above architecture was commonly implemented.

Similarities between conventional and Jamstack websites​

Conventional and Jamstack websites may look identical. When you visit a site in your browser, you may not be able to tell which one it is at first glance.

Differences between conventional and Jamstack websites​

The main difference between the two is the task flow of the browser from the site visit to the content display.

How conventional websites work​

A conventional website (e.g., CMS, e-commerce site) is displayed via the following process.

Image from Gyazo

  1. The browser sends a request to the web server.
  2. The application server and database server exchange information within the web server.
  3. The application server generates the HTML using data.
  4. The web server returns the HTML to the browser.
  5. Finally, the browser displays the HTML.

The browser and website engage in the above exchange each time you move to a different page.

How Jamstack websites work​

In contrast, a website built on Jamstack follows the mechanism below.

Image from Gyazo

  1. The browser sends a request to the web server (typically a CDN).
  2. The web server (or CDN) returns the HTML to the browser.
  3. The browser displays the HTML.

The application server does not interact with the database or generate the HTML. Since no dynamic processing is involved, the system load is greatly reduced, and the website can display much faster. Moreover, the CDN also speeds up the content delivery and display.

The dynamic parts (e.g., payment, authentication, certain content types) are obtained through external services known as "microservices." Since they often provide very limited functionality, the browser usually calls multiple microservices as needed for a single website.

Image from Gyazo

  1. The browser sends a request to the external service (microservice) API.
  2. The external service returns the processing results to the browser.
  3. The browser then rewrites the HTML according to the processing results.

Unlike the case of a conventional website, the external service returns the data mostly as JSON (instead of HTML) to the web browser. The browser then displays the data using JavaScript.

Advantages of display processing by the web browser​

The difference between server-side HTML generation and display processing done by the browser lies in the display speed. For the browser, displaying HTML requires heavy processing, which includes interpreting the DOM, applying style sheets, and calculating the heights and widths of any images. This process is repeated with every single page transition, causing lags in the site display.

With Jamstack, only the data is returned, so display elements are replaced only where necessary. This eliminates the need to re-display the entire HTML and greatly improves the loading speed. Your UX (user experience) also improves with every click from one screen to another.

Furthermore, Jamstack eliminates the need for the server to generate HTML. Sites that require authentication often have trouble caching the generated HTML. However, with Jamstack, data that does not rely on user authentication (such as product lists) can be cached without any issues. This also helps to reduce the server load.

Kuroco Is Built with Enterprise-Grade Projects in Mind​

Kuroco, the enterprise headless CMS, has all the serverless infrastructure your enterprise project would need to be highly scalable, secure, and performant.

Kuroco also allows you to configure your API with different paths containing different microservice endpoints for each frontend you have.

You can get started today and test it out for free, or feel free to reach out to our customer support team if you have any questions!