Today, all over the world, computers and networks are getting faster. This is good for web development and user experience in general. And the possibilities of what people can achieve have taken a massive leap forward.
But although growth is evident in many places, others are left behind in this sprint. The big question is how do we level the web experience given this digital divide and make the web more accessible to people with less efficient computers and networks?
In many cases, an answer to this question lies in understanding how we render webpages on the browser.
Terms Used in this Article
Before you go on, I want to make sure you're familiar with the terms used in this article. Some of them might be particularly difficult to grasp for new developers. Feel free to skip to the next section if you are familiar with these already.
- Server: A server is a computer that resides in a remote location (mostly the internet). Its job is to handle requests from the client and process a response.
- Client: A client is any device communicating with a server to access resources. A client, in many cases, is any device that can access the internet. In this article, your web browser plays the role of the client.
- CDN: Acronym for Content Delivery Network. A CDN is "a network of interconnected servers that speeds up webpage loading for data-heavy applications" (from AWS).
- Build-time: During build-time, your application code is prepared for another environment. Most times — a hosted environment on the internet.
Now let's learn about the different ways websites can be rendered.
What is Client-Side Rendering (CSR)?
It's no secret that large files result in increased download time, but there is a catch here: downloading large files at the initial load of the application means significantly less loading time in accessing other pages on that website.
The website primarily fetches data from an API. This data is then used to populate pages rendered on the client.
You can find common examples of a real-life application that use CSR in many of the Progressive Web Applications (PWA) we use today, like Spotify, Figma, and Google Drive.
What is Server-Side Rendering (SSR)?
Client-Side Rendering was a game-changer and still is — in many cases. Although, a closer look at performance in CSR showed that the more features a website had, the more JS code it had. Recall that more JS code means more download time.
Heavy downloads during the initial load to ensure faster access to all web pages did not seem like a trade-off some people were willing to make. This gave rise to Server-Side rendering.
SSR doesn't solve all the problems of rendering on the web. But it solved many of the issues faced by CSR like faster load times on initial visit and a few others highlighted in the Benefits and Trade-offs section of this article.
This means you can always be sure that the website content contains the most recent information from the server. You can think of it as an integration of a REST API — content from the backend is always updated.
Like all other methods of rendering on the web, SSR has its fair share of drawbacks. For one, having to make network requests to the server to load a webpage could impact users with less internet bandwidth. SSR also requires a relatively higher volume of computing power to be active.
What is Static Site Generation (SSG)?
Static sites are still very popular, but there are better ways to generate them. This goes to show how important they are in terms of performance on the web.
But, What is a Static Site?
A static site is rendered on a browser exactly how it was generated. The content of a static site is typically unaffected by the user viewing, unlike a web app rendered in CSR, or SSR, where each user can see content based on authentication or authorization.
Static sites are ideal for showing content that never changes or is updated once in a while.
Static Site Generation Explained
Static Site Generation is different from SSR and CSR in the sense that your HTML webpages are rendered and generated during build-time — before the user attempts to access your webpage. This is why SSG is commonly referred to as pre-rendering. It does the hard work beforehand.
Though SSG seems all bliss, there are tradeoffs. A major drawback of rendering with SSG is that a page must be generated for every accessible URL on your website. This could get even more tedious when you have dynamic pages.
Recall that static sites are ideal for showing content that rarely gets updated, so this rendering method doesn't work for all use cases.
Benefits and Trade-offs of Different Rendering Methods
Now that you understand how all these rendering methods generate pages for the browser, we should consolidate all of this information and do some comparisons.
We'll look at the three major metrics — Performance, SEO, and Cost.
To build websites that are accessible regardless of the user’s internet or computer speed, we need to consider performance. Performance in this context could be how fast a website loads or fetches data from an API.
The subsequent paragraphs shows how CSR, SSR and SSG translate in terms of performance.
Client-side rendering performance
A client-side-rendered website can be relatively slow to load. This is because JS code is first downloaded and used to generate actual content that users see.
Oftentimes, JS downloads are heavy, especially with JS frameworks. Client-side rendered webpages might also need to make API calls to fetch data from the backend. This increases load time for the user.
Server-side rendering performance
SSR Rendered webpages can be very fast. This is majorly dependent on the server's speed and the user's speed. If both conditions are met, SSR could take an easy win in terms of performance.
Static site rendering performance
Webpages generated with SSG are relatively fast as actual rendering does not take place on the browser.
SSG feeds the browser with content that it requires without extra work. SSG-rendered webpages, like CSR, might also need to make API calls to fetch data from the backend. This also increases load time for the user.
Search Engine Optimization (SEO)
Every website that needs visibility should value Search Engine Optimization. SEO determines how accessible your content is on search engines like Google. It also determines how high you rank in the Search Engine Result Pages (SERPs).
Let's see how all three rendering methods perform when they are indexed by search engines.
CSR Search Engine Optimization
Webpages rendered with CSR typically have no meaningful content and depend on JS to generate content. The downside is not all web crawlers support JS, so your website might not be indexed properly on search engines.
SSR Search Engine Optimization
SSR renders complete webpages with updated content from the server. Webpages rendered with SSR can be crawled and indexed by search engines.
SSG Search Engine Optimization
A web crawler very easily crawls webpages generated with SSG. They do not rely on JS to render fully.
It’s important that users have the best experience when they visit a website, but the bills don’t pay themselves, so the cumulative cost of this experience has to be as lean as possible.
The three rendering methods do not share the same financial implications. The paragraphs beneath takes a closer look into the cost of using each.
Client-Side Rendering runs 100% on the browser. This means no additional cost is incurred.
Server-Side Rendering generates a fully functional webpage remotely on the server. This means extra computing resources and extra costs.
No Cost. Static Website Generation is during build-time. Hence, generated webpages are hosted, and no extra rendering is done on the server.
When selecting a rendering method, consider your use case and what works best for it based on what you have learned from this article. Different rendering methods are suitable for different kinds of websites.
An e-commerce website developer might choose to go the SSR route or feel more secure using static sites. A web application developer, on the other hand, might not mind a lengthy initial load as long as it means a better experience for the user in the long run.
Whichever rendering method you select, ensure your website is as accessible as possible — beyond conditions you would not necessarily experience. Finally, never forget to stay on a healthy JS diet.
I hope you found this article helpful. If you did, feel free to connect with me on LinkedIn and check out favourfelix.com to see what else I'm writing and up to.