paint-brush
An Overview of CDN Caching, Static Site Generation and Server Side Renderingby@jmalvarez
635 reads
635 reads

An Overview of CDN Caching, Static Site Generation and Server Side Rendering

by José Miguel ÁlvarezSeptember 4th, 2022
Read on Terminal Reader
Read this story w/o Javascript
tldt arrow

Too Long; Didn't Read

Static Site Generation and Server Side Rendering are different types of pre-rendering a website and its combination with a CDN. With [max-age], the CDN can control how long the page can be cached. With Stale While Revalidate, the server is building a fresh version of a page while a new request comes a new version of it will be generated in the server and uploaded to the server. This means the user does not have to interact with the server so the user gets a **fast response**

Company Mentioned

Mention Thumbnail
featured image - An Overview of CDN Caching, Static Site Generation and Server Side Rendering
José Miguel Álvarez HackerNoon profile picture


Here we are analyzing the different types of pre-rendering a website and its combination with a CDN.


Static Site Generation

Every single page of a website is first built and then uploaded to a CDN. The best part of this is that, as the website is static, the user does not have to interact with the server. The CDN can directly return the static generated site, so the user gets a fast response.


The disadvantage is that every time you want to update the website you have to build the whole website again and upload it to the CDN. This costs money.


Server Side Rendering without CDN

Pages are built on demand with Server Side Rendering. When a user requests a page the user has to wait until the page is built and returned from the server. Because of this, response time is slow.


Every visit to a page generates a build. In comparison to Static Site Generation where every page is always built, here only the pages that are visited are built. If no one visits a page, it is never built.


The disadvantage is that for every request we have to build the page.


Server Side Rendering with CDN

In this case, the first visitor of a page requests the page to the CDN and the CDN requests it to the server which builds it and returns it back. But for the second visit, the CDN will already have the page in the cache and can directly return it without generating a new build.


The problem here is that every next visitor is going to receive the build that was generated for the first visitor. What happens if the page is stale? With max-age, we can control how long the page can be cached. When the page is stale, the CDN will request a new build on the next request after max-age. Depending on the kind of the page we could set a different max-age.

We can combine max-age with s-maxage. The CDN will cache a page using s-maxage instead of max-age if it is present. The user's browser will ignore s-maxage. This can be very useful if we purge the website pages in the CDN when they are rebuilt.


As we don't have control over the user's browser, we should have a max-age that is lower than the s-maxage, otherwise, we could have an updated version of a page in the CDN that the user would never request because the user's browser had an older version which would be still valid according to max-age.


For example, we could set a max-age of one minute or one day and a s-maxage of one year. This way the user would request the page to the CDN frequently and the CDN would never request a new build because according to s-maxage the page would still be valid. We would update the cache on the CDN by purging the previous page and uploading the new one.


Incremental Static Site Regeneration

Initially, the whole website is built and uploaded to the CDN as with Static Site Generation. But here if a user requests a page the CDN will return the current cached page and it will also request to the server a new build of only that page. This way, the next user will get the new build and the CDN will again request a new one to the server.


Every user gets a fast response and only the pages that are requested are updated.

This is a technique used by Next.js, I recommend reading their documentation to get a better understanding of this.


Server Side Rendering with Stale While Revalidate

stale-while-revalidate can be added to the cache-control header. What does it do? If a request comes after max-age the CDN returns a stale version of the page while the server is building a fresh one. stale-while-revalidate specifies in seconds for how long can the stale version be returned.


The first time a user requests a page it will be generated in the server and uploaded to the CDN. If a new request comes before max-age then the CDN will just return it. If a request comes after max-age then the CDN will return the stale version but this time it will request the server a new fresh copy.


Every user that requests the page while it is being built will get the stale version.

If after max-age a request comes and stale-while-revalidate has also passed, then the CDN won't return a stale version and it will wait until a new version is generated in the server.


From the user's perspective, it is exactly the same as Incremental Static Site Regeneration. Only that here we don't have to build the whole website for the first deployment, the first visitor will trigger the build of the page that he's visiting.



Also published here.