React Server Side Rendering

What is Server Side Rendering

Server rendering generates the full HTML for a page on the server in response to navigation. Server-side rendering is a technique for rendering a normally client-side only single page app (SPA) on the server and then sending a fully rendered page to the browser.

Why Server Side Rendering

  • SEO friendly – SSR guarantees your pages are easily indexable by search engines.
  • Better performance for the user – User will see the content faster.
  • Social Media Optimization: When people try to post your link on Facebook, Twitter, etc. then a nice preview will show up with the page title, description, and image.
  • Shared code with backend service.
  • User-machine is less busy.

Reasons we choose server side rendering

  • With the introduction of server-side (universal) React, The initial page is rendered from the server, meaning the subsequent pages load directly from the client.
  •  A universal app sends to the browser a page populated with data.
  • Then the app loads its JavaScript and rehydrates the page to get a fully client-side rendered app.
  • Often referred to as Universal Rendering or simply “SSR”, this approach attempts to smooth over the trade-offs between Client-Side Rendering and Server Rendering by doing both.
  •  Navigation requests like full page loads or reloads are handled by a server that renders the application to HTML, then the JavaScript and data used for rendering is embedded into the resulting document.
  •  When implemented carefully, this achieves a fast First Contentful Paint just like Server Rendering, then “picks up” by rendering again on the client using a  technique called (re)hydration.

React 16 SSR so much faster than React 15

In React 15, the server and client rendering paths were more or less the same code. This meant that all of the data structures needed to maintain a virtual DOM were being set up when server rendering, even though that vDOM was thrown away as soon as the call to renderToString returned. This meant there was a lot of wasted work on the server render path. In React 16, though, the core team rewrote the server renderer from scratch, and it doesn’t do any vDOM work at all. This means it can be much, much faster.

More info :- https://reactjs.org/docs/react-dom-server.html

React 16 Supports Streaming

React 16 now supports rendering directly to a Node stream. Rendering to a stream can reduce the time to first byte (TTFB) for your content, sending the beginning of the document down the wire to the browser before the next part of the document has even been generated.

SSR vs CSR

Features SSR(Universal) CSR(Client Side Rendering)
Initial Load Fast
Seo  If not implemented correctly
Performance (mobile/ slow internet)
Fast render after initial load
Web crawling
TTFB(Time to first byte)  Can be improved
Html doc size  Bigger  Smaller
Largest Contentful Paint  Sonner  Takes time
First Input Dealy  Takes time

Performance with Bluehost maestro

 We implemented React server side rendering for our maestro application.

Challenges

  • Initial setup is complicated
  • Redux configuration is complicated
  • Hot module reload is difficult to setup
  • Lazy loading setup is complicated (It can be done by using loadable)

Outcome

  • Faster page load
  • Improved performance

Why build custom React framework

  • More control over the application
  • Better handling of the components
  • Better dependency management
  • Less or no bloat npm packages

Comparison with Next.js and Gatsby

  • No Framework specific knowledge required in React SSR
  • Smaller Builds
  • Adaptable to new changes published by react team related to server side rendering
  • Static html pages can be created for pre login screens
  • Prefetching React for subsequent pages

Ways to Improve Performance Of React SSR

  • Using rendertoNodeStream instead of rendertoString
  • Link preload/prefetch
  • Lazy loading of assets
  • Using Brotli compression format
  • Code splitting

React SSR framework

Coming soon