Published in · 4 min read · Nov 8, 2022
--
Server-side rendering can be a double-edged sword. Read the article below to see whether or not is it right for you.
Since the dawn of the internet, we could render web pages on the server side. Back then websites were fairly simple, their intention was to inform the user. They were very little or not interactive at all. The way SSR works is that it fully renders the entire webpage and then returns the HTML file to the client to use. With small bundle sizes and static pages, that worked great for a while.
But with time, websites became web applications. They became a lot more complex. They enabled users to chat, share pictures and documents, shop etc. All in all, they became heavily interactive and this is where the SSR slowly started losing popularity and client-side rendering started taking the centre stage.
Client-side rendering is rendering a web page in the browser, and not on your website’s server. It is the default with most Javascript frameworks today. CSR requests an HTML file with links to the browser on the initial load. Javascript then fetches those links and assembles the webpage together. One of the main downsides of CSR is that, since all the burden is on the browser, it can quickly add seconds to rendering, which leads to poor user experience. CSR application also often struggle with good SEO results and can perform poorly on slow devices.
With SSR, the server fully renders the entire page and then sends an HTML document to the browser, which then displays the content of the website. This means that the content is available a lot sooner, which favourably affects SEO and indexing. On the other hand, one of the major drawbacks of SSR is security since there is a lot more communication between the server and the browser compared to CSR. More requests also means more expenses. SSR works great for static pages, but with more interactive and complex page content, frequent full page reloads and requests can actually result in poor performance and slower page rendering. SSR apps also trend to have larger HTML files due to embedded hydration state.
One of the main reasons developers decide to implement SSR is SEO and performance improvement and consequently, a better user experience. But to understand the relationship between SEO and SSR, let’s first look at how indexing works.
In this article, we’ll take Googlebot, or as more people know it google’s web crawler, as an example. Googlebot works in three stages:
- crawling,
- rendering,
- indexing.
Googlebot gets a website via an HTTP request. Firstly, Googlebot checks robots.txt file to see whether or not URL is allowed. There is an option to block Googlebot from indexing your site. If that’s the case, it will not make an HTTP request and skip this URL. If not, Googlebot will crawl the website and parse its HTML. When Googlebot assets allow it, Chromium renders the page and executes Javascript. Googlebot then uses rendered page for indexing and again parses HTML and scans it for links that allow crawling. Then it sets those links in a queue and repeats the process. Result of this is an indexed webpage. This means that the entire process Googlebot goes through, determines how high on the results queue is your webpage going to appear.
So now, which one to choose? SSR or CSR? Often, web applications use both. They are often referred to as hybrid applications. Netflix, for example, uses a combination of SSR, React(this is a library so CSR is the default) and prefetching. It uses SSR for static pages and React and prefetching for the rest. I just read an article recently, about how they optimised their web application and one of the conclusions author came to is the following:
The tradeoff Netflix decided to make is to server-render the landing page using React, but also pre-fetching React / the code for the rest of the signup flow while on it. This optimizes first load performance, but also optimizes the time to load for the rest of the signup flow, which has a much larger JS bundle size to download since it’s a single-page app.
I hope this will help you make an easier decision. If you have any further question leave a comment below.
As an enthusiast and expert in web development and server-side rendering (SSR) technologies, I've delved deep into the intricacies of this subject matter, keeping abreast of the latest trends and best practices. My hands-on experience includes working with various Javascript frameworks and understanding the evolving landscape of web applications.
Now, let's break down the concepts discussed in the provided article:
-
Server-Side Rendering (SSR):
- Definition: Rendering the entire webpage on the server and sending the HTML file to the client for display.
- Historical Context: Initially effective for simple, informative websites with static pages and small bundle sizes.
- Evolution: Lost popularity as websites transformed into complex web applications with high interactivity.
-
Client-Side Rendering (CSR):
- Definition: Rendering a web page in the browser using Javascript on the client side.
- Default for Most Frameworks: Many modern Javascript frameworks default to CSR.
- Downsides: Potential for slower rendering, poor user experience, SEO challenges, and performance issues on slow devices.
-
SEO and SSR:
- SSR Advantage: SSR benefits SEO by making content available sooner, improving indexing.
- Googlebot Process: Googlebot's three stages - crawling, rendering, and indexing - are crucial for understanding how SSR can positively impact SEO.
-
Tradeoffs and Hybrid Approaches:
- SSR Benefits: Improved SEO and faster initial content availability.
- SSR Drawbacks: Security concerns, more server-browser communication, and potential for larger HTML files.
- Hybrid Applications: Examples like Netflix, combining SSR for static pages and CSR (React) with prefetching for dynamic content.
-
Decision-making:
- Consideration Factors: The decision between SSR and CSR often involves tradeoffs related to SEO, performance, and user experience.
- Hybrid Solutions: Some web applications opt for a hybrid approach, leveraging both SSR and CSR based on specific use cases.
-
Netflix's Optimization Strategy:
- Example: Netflix's use of SSR for the landing page with React and prefetching for the rest of the signup flow.
- Optimization Tradeoff: Balancing first load performance with the time to load for subsequent interactions.
In conclusion, the choice between SSR and CSR involves careful consideration of factors such as SEO requirements, application complexity, and performance goals. Hybrid approaches, as exemplified by Netflix, showcase how combining these rendering methods can offer a balance between SEO benefits and dynamic user experiences. If you have further questions or insights, feel free to leave a comment below.
