A new technology trend emerged a few years ago - static websites & static website generators. I saw that, even created my website using one of the frameworks, but I didn’t think much about it.

And then I got busy - between managing people and striving to meet quarterly OKRs, I didn’t notice the emergence of platforms like Netlify and Vercel. I also didn’t immediately see the benefits of using static websites.

However, sometime last year it clicked like a light bulb. During that time, I was trying to create a theme for my own blog as well as build a web app for one of my ideas. I saw the difference in terms of building and managing the landing page and other associated static pages like about, terms, etc. Moreover, I saw Google Lighthouse scores of both the sites and was amazed. Static websites were not only easy to build and manage, but they were also very performant.

This is the time when I also noticed that I was not the only one who had noticed this. Most of the tech companies had already started separating their landing websites and blogs from their dynamic websites (tool, dashboard, etc.) For example - I realized Stripe’s landing website and their dashboard were behind two separate subdomains. Buffer’s landing website and web app were separate too.

Now I know why this separation makes sense:

  • Landing websites generally have marketing content, information about the company, and a blog. There are a finite number of pages, content (generally) does not depend upon who is viewing it and thus can be statically generated when the website is deployed instead of dynamically getting created whenever users are visiting the site. In such cases, the static site will be extremely fast because it has been ‘compiled’ into HTML pages during deployment. For example - Buffer’s about page loads and renders pretty quickly.
  • This also means that your dynamic website (which is behind a login) is isolated and its server (typically written in Python, Ruby, Node, Java) can focus on handling logged-in users and actual business logic. This separation of concern is very powerful (akin to microservices) and means each of these websites (static and dynamic) can operate and scale independently.
  • If you think this in terms of the marketing funnel - the number of users coming to your website and blog will be way higher and depending upon the conversion rate only part of these users would convert into actual customers (i.e. they will log in and transact). By keeping the two websites separate, you ensure that the performance of one website is not impacted by another website. In fact, the static website can completely be cached by servers and browsers
  • This separation also saves cost. Your dynamic website is no longer busy handling marketing traffic.

This stack is being popularly called JAM Stack (disclaimer - this page uses a lot of Jargons, but the idea and implementation are not very complicated).

While building the landing website for Soopr, I decided to extract everything into a separate easy-to-use landing website template. I not only wanted to make my landing website very fast, but I also wanted to use markdown to power additional supporting pages and blog posts.

And the outcome is Cookie. It is completely open-sourced and free to use. You can read more about it here and check the demo here. Give it a try for your next project.