Rendering Strategies from a Performance and SEO Perspective

Depending on the website or web application we want to build, we may consider different rendering strategies. Every rendering strategy has its pros and cons, but the great thing about Next.js is that we don’t have to compromise. Instead, we can choose the best rendering strategy for every single page in our web application.

Let’s pretend Next.js doesn’t exist for a moment. Pretty scary, isn’t it? We want to build a web application using React, but we have to compromise between rendering strategies.

Client-side rendering

CSR is a great starting point. The application would be deployed as a JavaScript bundle that dynamically generates the HTML content once it gets downloaded to the web browser. The performances will be outstanding because all the computation will be done on the client side. In addition, the user experience will be amazing because the customers would feel as if they were using a native app. On the other hand, we’d have to struggle with SEO since CSR makes life harder for search engine bots.

Server-side rendering

On second thought, we might consider SSR. We would render all the content that’s important for SEO purposes on the server side, allowing the client to generate the rest. This could be the best option security-wise because we can hide many data fetch, validation, and sensitive API calls on the backend. That’s a good alternative but has some drawbacks. With CSR, we’ve seen how the app could be bundled into a unique JavaScript file. With SSR, we’ll need to set up, maintain, and scale a server. With an increase in traffic, it would get slower, more expensive, and harder to maintain. Time to look for a third option.

Static site generation

Our last option is to generate the whole website at build time statically. We would achieve the best possible performance while SEO scores would increase significantly, but we’d still have some significant drawbacks. ...