Why use server-side rendering
In the front-end world, we went from jQuery to all kinds of different frameworks. The Single Page Applications (SPAs) make a big footprint in our world wide web. There are some issues that we miss with this approach:
Search engine optimization
Performance on slow devices
In this blog I will explain how Server-Side Rendering could help you to fix these issues.
Why does a client-side rendered application have these issues?
Well, how does server-side rendering solve these issues?
With server-side rendering, the HTML is being rendered first on the server side. So, at the moment a user goes to your website/application the HTML that the browser receives already contains the content that it will be needing for making the first paint. This means that Angular, Vue and React will run on the server. Also, the API calls will happen on the server side, so there is less communication from front end to back end. When the CSS is compiled there will be a screen ready on the screen.
Let’s compare CSR with SSR
In the video below, I took Client-Side Rendering and Server-Side Rendering to the test. Here, I am using a 3G network and a slow mobile phone. You can create these kinds of video’s at https://www.webpagetest.org/. Small side note is that there are a lot of other factors that influence the loading speed, but both pages in the video were hosted on AWS in an Elastic Beanstalk with a Node.js server with Express in production mode. The front end is Angular, with Angular Universal for the server-side rendered one.
The differences in regards to social media are visible in the image below. Of the Client Side Rendered version, you can only see the link. Server Side Rendering on the other hand already shows an image.
If you are not using Server Side Rendering for the performance, it is still very useful for the SEO of your application. Keep in mind that Server-Side Rendering adds more serverload. This load can be reduced by for example using a CDN caching mechanism to cache the Server-Side Rendered pages.