To create dynamic websites, we had to generate the HTML dynamically in the server. This technique is called server-side-rendering (SSR). For example, upon a user request for a page, the server had to query the database and generate an HTML file and serve it to the client based on the results. Whenever the user navigates to a new page, the page is fully reloaded with the new HTML file. SSR as mentioned was the only way to build websites at the time.
A singular point that changed web development forever is the invention of AJAX by Microsoft. AJAX provided a way to modify the DOM on the client-side and dispatch asynchronous HTTP requests back to the server. This opened the door to improve the performance of websites drastically. We no longer need to do a full reload to the page. We can dispatch a request and, based on the response, modify on the client-side the page. Today, AJAX requests are very popular, but at the time, this was innovative and revolutionary.
The Birth of Single Page Applications
In the search for improving the performance of the web, developers started to wonder if SSR can be replaced with a new technique that will be more performant. SSR's problem is that it delays the rendering of the whole page until all the required data is resolved. This means that the first paint might take a lot of time. Thanks to AJAX, we no longer need to load the page as a whole. We can load parts of it. With the essence of this concept and the frameworks at the time, such as Backbone, Ember, and Angular 1, the Single Page Application (SPA) was born.
SPA takes care of everything on the client-side, this includes even routing. We can store all our assets in a CDN and deliver them to our users, with no need to dynamically generate a single HTML file. No matter what page the user requests, they will always get the same index.html file as a response.
To provide data dynamically for the SPA, Web API was introduced. Web API consists of HTTP endpoints that only delivers data, usually in JSON format. Some modern implementation of Web API might follow the REST API convention or GraphQL. The SPA can send a request to any of these endpoints to receive the data it needs and modify the DOM accordingly.
This calls for a new solution that will combine the pros of both worlds of SSR and SPA. The hybrid model, or as I love to call it, SSR 2.0, delivers different HTML for every page but does not necessarily render everything on the server-side. You render only the bare minimum required for SEO and then let the client-side do the rest incrementally.
Next.js is one of the frameworks that push server-side-rendering to the front line and keep innovating in this domain. Next.js made it more user-friendly to build a server-side-rendering application that follows the best practices of performance and includes a modern framework (React) inside.
One of their latest inventions is called Incremental Static Generation (ISG). With ISG, you can render the page on the server and then cache it in the CDN so the following visitors will get it almost instantly. Of course, you could have done it before, but Next.js made it all so simple. Cache invalidation is one of the hardest problems to solve for a developer, and they do it for you. You can also set a cache policy. For example, refresh the page every 1 minute.
When I migrated daily.dev from SSR to ISG, it dramatically increased the Lighthouse score. And it was super easy to do.
ISG is an important step to make SSR applications much more performant and I believe it will be embraced by more SSR frameworks.