Different rendering methods have different benefits such as better SEO support or faster initial load times to name a couple of examples. And, once you understand these differences, how they work, and their relation to your application, you’re in a better position to choose the best one for your situation.
innerHTML property value of a DOM element selected with
Some rendering methods are faster to render, others are better for SEO or security, and some have faster page transitions once loaded. So, your choice between these methods will depend on the benefits your project needs the most.
What is client-side rendering (CSR) and how does it work?
What are the pros and cons of client-side rendering (CSR)?
TL;DR of client-side rendering pros and cons:
- Pro: You’ll get fast page transitions and great interactivity. For highly interactive apps that have dashboards, etc. these benefits make all of the cons worth the effort.
- Con: Your site will have slower initial rendering times because of all of the files that need to be downloaded and executed.
- Con: Your SEO may suffer without extra configuration because not all web crawlers can process pages like these.
- Con: You’ll need to be on the lookout for security vulnerabilities.
What is server-side rendering (SSR) and how does it work?
Server-side rendering (SSR) is similar to CSR in that a user goes to a URL, sending a request to a server for all of the files needed for that web page. But there is one massive difference: the rendering doesn’t happen in the browser. Instead, it happens on the server.
So, the overall flow of a request would be that a user requests a webpage from a server by visiting its URL. Then the server renders the page in its entirety, outputting the final HTML and any assets and other scripts required to run the client. Then this final completed page is sent back to the browser, ready to display.
What are the pros and cons of server-side rendering (SSR)?
It’s also worth mentioning that SSR is inherently more secure because you have the option to run sensitive code on the server as the page is being generated. The client can’t access or interact with this code, which means we can safely include things like secret keys and environment variables without worrying about exposing them publicly, making SSR great for things like authentication and generating payment links for purchases.
However, there are some downsides to SSR. Page transitions and interactivity can take longer because each page change requires a new request to the server, which takes time.
The other possible downside with SSR is the need to have a server running to generate the pages on-demand for each user request that comes in. But, while this is something to be aware of, in the present day of web development it’s not something to be concerned about because modern hosting solutions like Vercel and Netlify handle and maintain all the servers for you and your website.
TL;DR of server-side rendering pros and cons:
- Pro: Faster initial page load speeds than CSR.
- Pro: It’s friendly for web crawlers, making it SEO-friendly without extra configuration.
- Pro: It’s more secure because you can handle sensitive things on the server.
- Con: Slower page transitions and interactivity.
- Con: It requires that you have a server running that can handle rendering with each user request.
What is static site generation (SSG) and how does it work?
The final rendering method we need to look at is static site generation (SSG). It works similarly to SSR in the sense that rendering happens on the server, but the notable difference here is when the rendering happens.
Remember that with SSR the rendering happens in response to a user’s request and on demand. With SSG, rendering happens before any requests are made. Instead, rendering occurs when the website is being deployed.
What are the pros and cons of static site generation (SSG)?
If you’re able to use SSG for your website, then there are some great benefits to gain. Most notably, the performance of SSG sites is the best out of all three rendering methods. This is due to having the rendering complete before the user requests a page. When a user does request a page, the server can respond immediately with the final HTML without having to wait for it to be generated.
In terms of SEO, SSG is similar to SSR, with no SEO issues or problems. However, faster initial page load times can impact the factors that tell search engines that a page not only has good content, but also a nice user experience, like Core Web Vitals.
Security can be a pro or a con for SSG depending on your needs. Since your site is only serving static files, there are fewer attack vectors for malicious agents. However because SSG doesn’t run any code on the server when a user requests a page like SSR, things like authentication and running sensitive code need to rely on client-side code, which brings with it the same issues we had for CSR.
Another potential downside for SSG is that it generates all your pages at build-time using the data that is available at that time. This is great for pages that don’t change often, like blogs or marketing pages. But, for pages that change often, this can lead to displaying outdated data. If you need the latest available data on a page, you’d be better suited with something like SSR that fetches the latest data for each request.
Additionally, each time you want to change something on a page, the entire website needs to be rebuilt and distributed again. This isn’t an issue for smaller websites but for large websites with hundreds of pages, this can take a significant amount of time and delay changes being distributed. Some meta-frameworks like Next.js and Gatsby have developed their own rendering methods to address this issue (incremental static regeneration, or ISR, and deferred static generation, or DSG, respectively). These options essentially allow you to redeploy or rebuild the site incrementally or at particular times.
TL;DR of static site generation pros and cons:
- Pro: It’s SEO-friendly, plus its fast load times can maximize factors like Core Web Vitals scores.
- Pro: Serving static HTML pages means there are fewer ways for someone to attack your website.
- Con: If you need to implement something like authentication, you’re back to a less secure solution than SSR.
- Con: The data on the page isn’t refreshed for each new user, but is rather fetched at build time.
- Con: New updates to the site require a rebuild, and for large sites, those can be very time-consuming, unless you mitigate this impact with the more specific rendering methods that some frameworks provide.
If SSR or SSG sound interesting, you'll also want to explore these articles!
Choosing the right rendering method and framework for your project
Choosing the right rendering method for your needs is all about balancing the priorities for your project. For a marketing blog, the SEO gains of SSG may be very appealing, and there’s not much lost in the lack of data freshness. However, for an e-commerce site, SSR might make more sense because it needs to be SEO-friendly and have fresh data for crucial information like stock levels, prices, and more. In the case of a highly interactive dashboard or application, CSR may be the best choice because SEO and initial load times aren’t as crucial.
If your project really just needs one rendering method specifically, you can also reach for a simpler framework that caters to just that. This may sound like intentionally limiting yourself and your options, but with a lot of these more powerful frameworks, you may also need to do more configuration and setup to get them working as you want. So, it’s good to consider whether the setup and configuration work is going to be worthwhile for the features it unlocks, or if a simpler solution really suffices.
To help you decide which tool might be right for you based on the rendering method you want to use here are some options to help you get started.
Tools great for CSR
Tools great for SSR
Tools great for SSG
Tools great for all three
Dive into your first project!
And, if you’re itching to dive into using any of these rendering methods, then I highly recommend using a modern framework like Next.js or Gatsby. They allow you to easily implement any of these rendering methods without too much work on your part since they abstract away the heavy lifting to let you focus on building.