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.
- 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.
- 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|
|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.
- 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)
- 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