Server-Side Rendering (SSR) vs Client-Side Rendering (CSR)

Share

We love high Google ranks.

But Google, on the other hand, loves short rendering time a lot, which gives fewer chances for heavy apps to position themselves well.

Simply put – the more complex your React app becomes, the more effort Google needs, to chew it and assign a position on the list.

There is a possibility to take a part of this effort away and increase your chances to appear higher on Google rank with Server-Side Rendering (SSR).

However, SSR is not the ultimate answer for heavy apps. At higher levels of complexity, it can even make the response time longer than the Client-Side Rendering (CSR).

Let’s see when it is better to use SSR instead of CSR.

How React works on the Client-Side?

Normally it works like this:

  • Step 1: The browser downloads a minimal HTML page.
  • Step 2: The browser fetches a JavaScript file, executes it and fills the content into the page.

However, it can cause a few problems.

SEO Problems

As mentioned above, we prefer to appear higher in Google rank (or at least higher than the competition).

But Google crawlers do not understand JavaScript well. The Search Engine Bot is only able to handle apps with loading time around 300-400 ms.

If loading takes longer, Google Bot sees a blank page:

Fetch as Google

how google and visitors sees your page

Long Loading Time Problem

This creates another problem, which is loading time.

Nobody likes to wait for the content to appear. Heavy apps are often too slow, frustrating, and less competitive, if not maintained well. (Check how loading time affects the quality feeling and conversion rates). Users with medium-price devices or slow internet connection will definitely have a struggle and more probably will complain about the poor UX.

This is why server-side rendering can be extremely useful for content-heavy sites. (Mind that content-heavy doesn’t mean function-heavy).

Client-side rendering vs Server-side rendering

We know already how Client-Side Rendering works. Our browser downloads a minimal HTML page, then it renders the JavaScript and fills the content into it.

Server-side rendering, on the other hand, renders React components on the server. In this case, the output is HTML already filled with content, so there is no need to fetch any JS.

There are obviously weight differences between apps, therefore reaction and rendering times are also different. In the case of the app from fetching example earlier, times were different around 100ms, but they may be smaller, or much bigger in other cases.

However, when the app becomes very heavy (not by the content, but by functionalities), SSR may make your loading times even longer.

Client-Side Rendering

client side rendering code example

Server-Side Rendering

client side rendering code example

There is also a possibility to combine these two to create an isomorphic app, but this is the case for the whole another article.

Main Benefits of SSR

The most important benefits are:

  • 🚀Performance – the loaded app is sent down from the server on the first request (Google doesn’t have to fetch JS)
  • 🔍SEO – Google favors sites with fast load times

Disadvantages of SSR

  • 🍔SSR can improve performance if your application is small, but it can also degrade performance if it is heavy.
  • ⌛Increased time can be even worse if the server is busy.

When should you use SSR?

  • If you want your app to be SEO prepared.
  • When your app is content-heavy and needs a small performance improvement.

How to add SSR to CRA?

ReactDOM.hydrate(<App />, document.getElementById("root"))
import path from 'path'
import fs from 'fs'

import express from 'express'
import React from 'react'
import ReactDOMServer from 'react-dom/server'
import ServerLocation from '@reach/router'

import App from '../src/App'
const PORT = 3000
const app = express()

const router = express.Router()
const serverRenderer = (req, res, next) => {
  fs.readFile(path.resolve("./build/index.html"), "utf8", (err, data) => {
    const app = ReactDOMServer.renderToString(() => (
        <ServerLocation url={req.url}>
            <App />
        </ServerLocation>
    ))
return res.send(
      data.replace(
        '<div id="root"></div>',
        `<div id="root">${app}</div>`
      )
    )
router.use("^/$",), serverRenderer)
router.use("/dist", express.static("build"))

app.use(router)

app.listen(PORT, () => {
  console.log(`SSR running on port ${PORT}`)
})

SEO for heavy apps

If your app is highly complex and has many functionalities, maybe it is a good idea to build a lighter landing page that will refer to your app.

Use GatsbyJS to build a blazing fast product page to win the fight for the highest SEO ranks with your competition.

Comments
Leave a Reply

View Comments (0)...

Related articles:

The basics you should know about Gatsby API files.

What is React Context And How To Use It?