Do You Need Server-Side Rendering?
Published on 2019-07-08
Yes. No? Maybe?
The need to use Server side or Client-side rendering in your application is very much dependent on the nature of your application and the kind of experience you need to deliver to your users. Because at the end of the day, they (most likely) do not care what stack you use. They only want to be smiling throughout the experience they get on your website.
In this article, I will labour to identify the advantages and disadvantages of both techniques and some possible pointers to help you make a decision for your application.
Client Side Rendering (CSR)
- Time To First Byte(TTFB) for client-side rendering is faster than server-side rendering. This is because the server has to spend some time to create the HTML for your page instead of just sending out a relatively empty response.
- For large applications, your Time to First Paint(TFP), Time to First Contentful Paint(TFCP) is slower, giving your application a slower perceived performance. A common workaround for this problem is to use a loader image to show on top of the web page while the application is loading. When page load is complete the loader image is then removed.
Server Side Rendering (SSR)
- Faster Time To First Paint and Time to First Contentful Paint. This gives users the feeling of a faster page load and content they can consume once the markup is parsed and rendered by the browser. This means that the blank page flicker that happens with CSR won't happen with SSR. In CSR applications.
- Better SEO indexing. Search engine crawlers will access fully rendered pages in your application.
Development constraints with client-side libraries in your app referencing
More involved build setup and deployment requirements. Unlike a fully static SPA that can be deployed on any static file server, a server-rendered app requires an environment where a server can run.
More server-side load. Rendering a full app in server-side environments like Node.js is more CPU-intensive than just serving static files, so if you expect high traffic, be prepared for corresponding server load and wisely employ caching strategies.
Slower Time To First Byte. The server has to spend some time to create the HTML for your page instead of just sending out a relatively empty response.
ReactDOMServer.renderToStringwas a synchronous process. This would make page load slower if you're prefetching a lot of data on the client.
NOTE: This issue has been mitigated in React version 16. So please use that instead. 😀
Pre-rendering is a tradeoff between client-side and server-side rendering. Every pre-rendered page displays a skeleton template while the data waits to be rehydrated with AJAX/XHR requests. Once the page content is fetched, routing is done dynamically to take advantage of a client-side rendered website.
Pre-rendering is also perfect for static sites. Perfect candidates for this would be a home page, landing page or blog posts. Popular Front End Pre-rendering frameworks include Gridsome for Vue.js and Gatsby for React.js.
Building Universal Applications
index.html page, we pre-load the application on a web server and send them rendered HTML as the response for every route.
Both Server-side rendering, and Client-side rendering are great tools that the web has given us to make great applications for our users. If it matters to your users that they see dynamic content on your site, then SSR might be way to go for you. Example sites can be news, media or dynamically driven applications that need to give your users something to look at immediately they load your page.
If SEO is your most important requirement for a relatively small website, then you might not need SSR. Pre-rendering with hydration for a client-side rendered application like Vue.js or React.js might be the best alternative.
At the end of the day, no solution is 100% perfect. Either way, you will make some tradeoffs while you build applications on the web. So its best to understand what tradeoffs you're willing to bear and minimize the losses while having a little fun along the way!
- Experimentally verified: "Why client-side templating is wrong" by Brett Slatkin