Once upon a time all websites were static. We would have simple websites with minimal dynamic content, so the server would load up a HTML page with CSS and some basic JavaScript for the client to display, without too much trouble...๐ฌ
Nowadays, we desire a lot more complex & high performant websites with not only good search engine optimisation (SEO - so Google can easily return our site when a user searches for it) but also fast and responsive load times โฐ.
There are 3 main technologies in which websites can be rendered, oftentimes easily confused, but no fear - after this article you'll be a site rendering connoisseur ๐
Client-side rendering (CSR)
First off, we have CSR, which arguably is the most different of the 3.
Client-side rendering is used by the most popular JavaScript frameworks that we all know and love, such as React, Vue.js & Angular. In such websites, the heavy lifting is done by the client (surprise surprise) or browser - whichever term you prefer to use.
The browser essentially receives an empty HTML file and JavaScript is in charge of putting together the content of the page. Once the page has been put together, what is dynamically shown on the page from then on is also determined by browser JavaScript, as opposed to a server sending up a fully rendered dynamic page (which we will get to soon!). Seeing as the browser assembles the page, loading times tend to be a little longer in this type of website. But after the initial page load, it's super fast to handle dynamic content as everything that is needed to be done (such as making any API calls) is done within the browser!
Single-page applications (SPAs) are an example of client-side rendering, where the initial request serves up a single HTML file and all other DOM page structures are manipulated by the client. Our handy tools like React & Vue.js are perfect for creating SPAs ๐
Server-side rendering (SSR)
Next up we have SSR, where the heavy lifting is done by the server (shock!). In these websites, the user makes a request for a page, the server listens to this request and composes the page with HTML, CSS & JavaScript. It then sends up a fully rendered page to the browser. This means the initial page load is fast but every subsequent request for dynamic content requires the server to put together the page all over again, so it can be slower than CSR after this point.
However, note that SSR websites are great for search engine optimisation. Crawlers can easily deduce the content of the page as it has already been rendered before being sent up the wire.
Static site generation (SSG)
Finally we have SSG. Similarly to SSR, SSG involves pre-populating the page with content so that when the user loads the page, a fully rendered page is served. The key difference between SSR & SSG is when the page is put together. In SSR the page is put together by the server. In SSG the page is populated at build time. All API calls required to populate the page with content are made at build phase, cached and then deployed to a static hosting service like AWS S3 or Netlify. In SSG websites, no server is needed to render your page! ๐คฏ
Tools such as Nuxt.js or Next.js are perfect for SSR & SSG
- For SSR: In these frameworks, the websites are loaded on the server and the data is brought into local browser state, which can then be easily manipulated on the client, reducing load times.
- For SSG: Nuxt.js & Next.js give the ability to statically generate your website, packaging it up into static files ready to be deployed to your hosting service of choice. Any pages that have been excluded from site generation will typically fall back to an SPA and be rendered on the client.
And that's all folks! ๐ I hope after reading this, you'll understand the key differences between SSG, SSR & CSR. And of course, if you have any more questions, please don't hesitate to contact me in the links below! ๐๐
Top comments (0)