Which type of rendering is best suited for your React project and how to choose your architecture based on that? (SEO optimized)
So you have told your friends about your plan to build your next web project in React — the JS library which makes it painless to build interactive UIs. But wait, do you feel like you are drowning now under the weight of countless new jargons thrown at you by them?
Client-side Rendering, Server-side Rendering, Prerendering, Static Generation, Dynamic routing, Single-page Application, SEO compatibility, and many more…
Fear not, cause you are at the right place! In this blog, I will try to explain the whats and whys of all the above-mentioned jargons and try to design the best-suited architecture for your next React project. Perfect! So without further ado, let’s dive into business!
Disclaimer: This blog will be a bit knowledge-heavy. But what can we do? The web itself is knowledge heavy and that’s its beauty. I have tried to divide the content into subsections with specific headings so that you can grab the part that you need. Though I would suggest to read the entire blog so that you can have an overall picture in mind while choosing the right architecture for your React project.
SPA and Client-side Rendering
Our friendly neighborhood React application is generally a single-page application with client-side rendering. Wait but what does that mean? A single-page application loads once and then javascript is used to rewrite certain parts of the page with new data fetched from the webserver whenever needed instead of the traditional approach of loading the entire page from a server whenever a new page is loaded. One of the most important purposes of using SPAs is their performance. SPAs have a huge performance boost over traditional websites due to their short wait time while jumping from one page of the website to another.
As you can guess, SPA and client-side rendering go hand in hand. With client-side rendering, the user request is redirected to a single HTML file that contains JS bundles. The webserver delivers it without any content (or with a loading screen) until your browser fetches all the JavaScript codes from the JS bundles prepared by Webpack and Babel and renders them to paint the screen. Sounds simple right? Because it is! Thanks to Googlebot’s ability to read JavaScript, SPAs are now SEO friendly too.
Overall SPA with client-side rendering is the best approach if you have:
- A small or mid-sized application — maintenance becomes tough for enterprise-scale applications
- Less number of pages — client-side routing becomes complicated with more number of pages/subpages
- Not much bothered with SEO and dynamic meta tags — HTML is easier to crawl and index than JavaScript
- A good and reliable internet connection — else TTFB(Time to first byte) becomes slow
Server-side Rendering
Traditional SSR involved serving HTML pages from a webserver on each request from the client and it was best for SEO. Why? Because Googlebot is highly skilled in crawling HTML pages and since they are already rendered pages, they are crawled very fast as well. SSR has in-the-box support for dynamic routing and meta tags and provides a great user experience owing to its fast initial page load.
So SSR is the best approach if:
- Your website has a lot of pages (eg: E-Commerce websites and Blogs).
- Your website has a major dependency on SEO and you are bothered about dynamic meta tags.
Now to combine the good sides of SPA and SSR, modern React.js frameworks like Next have come with a solution called Prerendering.
Prerendering
Pre-rendering is at the junction of client-side rendering and server-side rendering which involves the process of loading a webpage ahead of time, waiting for it to finish rendering, and then reversing the resulting HTML and JavaScript as a result to the requesting entity. Once the page is fetched, internal routing is done dynamically to use the benefit of a SPA and the displayed template is rehydrated with AJAX/XHR requests as needed.
When you design the architecture of a page that is shown before the final content is rendered to the screen, a static snapshot of the page is immediately taken that can be useful to represent the content to search engines on page load without providing anything. Prerendering focuses on rich sites with a balance between user experience and SEO.
Next.js provides two types of prerendering:
- Static Generation — The HTML is generated at build time and will be reused on each request.
- Server-Side Rendering — The HTML is generated on each request.
Importantly, Next.js lets you choose which pre-rendering form you’d like to use for each page. You can create a “hybrid” Next.js app by using Static Generation for most pages and using Server-side Rendering for others. You can also use Client-side Rendering along with Static Generation or Server-side Rendering. That means some parts of a page can be rendered entirely by client-side JavaScript.
Conclusion
It is very important to choose the rendering architecture before developing your next React project. Once your codebase grows in size, it becomes highly inconvenient to shift to a different style of rendering. Precaution is better than cure as they say.
- Think about the possible impacts of your website/web app.
- Do a rough estimate on the frequency of probable data fetches or dynamic sections of your application.
- Analyze what approach would make your application easily available to your target audience.
- And finally, choose your rendering architecture.
Additional tip: Choose Next.js :)
Thanks for reading through. I will highly appreciate your reviews and suggestions. Do let me know in the comments if you have some other optimization techniques in mind.
If you found it useful, please give me a clap and share it with your fellow devs. Don’t hardcode, code hard!
