What Is a Static Site Today?

It’s good to remember that at the beginning of the Web, everything was static HTML pages, and to make more Dynamic applications, people innovated and produced languages to render web pages that are not really Static. CGI, Perl, and PHP were the most popular solutions at the beginning.

Those languages were used to generate (on the fly) HTML pages, making them dynamic, those computations being done on the server side, where other resources were available, like a database, for example.

And for a while, that was the way to go. You would pick the framework and the stack that you’d like to build your application. (LAMP, Linux, Apache, MySQL PHP might ring a bell to some of you).

For example, imagine you are building a web application, a Blog. On a simple blog, you probably have four templates of pages:

• The Home page lists all recent Blog Posts.
  • Highly dynamic, it will change each time a new blog post is published.
• The Category page lists all the Blog Posts for a specific category.
  • Dynamic, it will change each time a new blog post is published in that category.
• A blog post page to render the blog post's content and receive comments.
  • Almost static if we exclude the comments.
• A contact page with a form.
  • Always the same: immutable.

To run your blog, your web application needs to save the content (and media) of your blog post in storage (most likely a database), and it will use processing and computation power to render (on the fly) your blog post.

Ex: https://www.crystallize.com/blog/what-is-static-site

- The web server receives the request from the browser.

- It extracts the URI /blog/hello-world, looks in the database, and fetches the content related to `/hello-world`.

- Compute and merge the content data with the template.

- Return the fully generated page to the browser. (HTML/CSS/JS).

Regardless of whether you have one blog post or 10 million, the process is always the same, and it is repeated.

We call that a dynamic web application; in more technical terms, it’s called SSR for Server Side Rendering. Like everything, there are benefits and disadvantages, as we explained in our practical guide to web rendering.

They refer to applications that are pre-generated (or built) one time, deployed, and served. Once the application is built, there is no more computation and no need for databases or server-side processing. It could be seen as a form of compilation that results in HTML, CSS, JS, and media files deployed (stored) onto the server(s).

That’s a huge performance benefit right there.

Back in the day, we would usually build a dynamic application that we would consume to generate static files out of it, but doing that was not trivial.

If I take the same Blog example mentioned above, we would need a new step, the build step.

We would not deploy the dynamic application; instead, we would pre-generate all the possible pages in advance. The build would be the only place that would require access to the database.

Once all the pages would be generated, they would be deployed, allowing:

Ex: https://www.crystallize.com/blog/what-is-static-site

- The web server receives the request from the browser.

- It returns the fully pre-generated page to the browser. (HTML/CSS/JS).

No computation, no processing, back to the old times. Blazing fast, secure, and easily scalable.

That is what we call a static web application. In more technical terms, it’s called SSG, which stands for Static Site Generation (look at the web rendering post). Like everything, there are benefits and disadvantages to the SSG approach as well.

Another approach is to have a “kind of” middleware called Reverse Proxy. Those components are installed between the servers and the browsers, and they would save the static version of a dynamically server-side rendered page, to serve it statically thereafter.

That’s called HTTP Caching, and a CDN, Content Delivery Network, does that on the edge of the world. Those reverse proxy servers usually have a built-in mechanism to purge entries from their storage, so you can invalidate one page instead of rebuilding everything. 

It's a very powerful approach, but it requires a very good comprehension of the web of HTTP and can become complex for small projects. You probably should read mine and Bård's post Event-Driven HTTP Caching for eCommerce for more information on HTTP Caching.

What changed in recent years is the toolings that have evangelized the SSG. From the development framework to the hosting of it with Serverless in the middle to make it cheap.

The best example is NextJS, the Node JS framework made by Vercel, the hosting company. (or Gatsby and Gatsby Cloud, and others, of course).

The framework is made to generate static pages in opposition to rendering pages on the fly (SSR) to make them static eventually.

It’s SSG first, and when you need dynamic things, then the framework and the hosting would allow that in a very streamlined way.

Following the framework + hosting conventions, you would have part of your code that can be executed in serverless function when it has to be dynamic (when you need computation server side).

With NextJS, for example, you can decide per page (or type of page) if you want SSG or SSR. Even better, if you want to build an API with the frontend framework, you can do that as well. Behind the scenes, when hosted, they would trigger the serverless function that needs to run to execute (process) the code server side.

But they don’t stop here. On the hosting part, they also provide all the automation needed to rebuild. They provide webhooks to trigger actions like a rebuild:

• You change a typo in your blog post.
• Your CMS calls the webhook.
• The application is rebuilt and redeployed.

All the processes are streamlined now and are way more trivial than they were years ago.

Another thing that enables that, part of the Jamstack ideology, is that hosting companies are CDNs on steroids. You cannot add your database there. Instead, you rely on other services that provide APIs for it.

Not really, because the approach you’ll take depends on the use case. Performance is what matters, so the decision has to be made for performance:

• If you have 500 pages and rebuilding everything takes seconds, you are probably going to use SSG.
• If you have 500 pages, and rebuilding everything takes seconds, but you have to update almost every minute, you will consider SSR with a good HTTP Cache mechanism.
• If you have millions of pages and rebuilding everything takes hours, SSR and a good event-driven HTTP Cache will be the way to go.
• If you have thousands of highly dynamic pages, SSR might be the way.

Pretty straightforward, right? Well, then the questions and the ideas start to pop:

• Maybe you don’t have to rebuild everything all the time. If so, isn't an Incremental Static Regeneration (ISR) approach a better option when using NextJS? Or how about Reactive Site Generator (RSG) with Gatsby?
• Maybe you can combine SSG, SSR, and HTTP Cache?
• Maybe you can split and decouple even more your web application to take full advantage of those concepts?