Single Page Application (SPA) vs Server Side Rendering (SSR)

Single Page Application has been the main approach of web development on the last decade, but in the last year there is a exchange for Server Side Rendering happening. In this post we are going to talk about both approaches, discussing what are them and about the scenarios each one of them is better.

SPA is the most common approach to develop web apps during the frontend age. In SPA when user enters the page, only a single document is loaded and the screen is mounted by Javascript. This implementation allows users to interact with the page while it's loading, because things load on demand while users are interacting with it.

Single page applications brought a lot of performance on user experience as we need to await very small things to load to start navigating. This possibility of interacting with the components of the screen and load things on demand allowed SPA to create dynamic pages and this was very accepted by the people.

The main problem of SPA is that it cannot show information to search engines, as their pages are loaded by Javascript. This fact creates a very big problem for websites that depend on SEO (Search Engine Optimization), because they cannot be indexed and ranked on search mechanisms. And it's also important to mention that SPA have difficults on performance measurments, as it depends on client's brower to be rendered.

But in the other hand, there are very popular and easy to use frameworks and libraries to implement SPA websites, like React, Vue.js and Angular.

The concept of Server Side Rendering came up to try to solve some problems of SPAs. In this approach the browsers receive an file that is ready to be shown because it was already rendered on the server side. With this the content can be read by search mechanisms allowing the pages to be indexed and ranked, what means that this approach allows the web app to have SEO.

In SSR it's easier to measure performance as the pages are rendered at the same place, but it also brings some problems like more usage of the server, because every new page the user access needs to make a call to the server to render that page. The fact that the pages are rendered on the server blocks user from interact with the page unless it is fully loaded, making the TTFB (time for first byte) to be higher than on SPAs.

Server side rendering has some disadvantages, but they are compensated by the power to enable SEO and performance measurments for the apps developed this way.

There is also good frameworks and libraries to implement SSR, like Next.js and Nuxt.js.

SPA vs SSR

SPA Pros

• Good user experience, as they don't need to await the page to load to start interacting with it;
• Easy to implement with very popular frameworks and libraries;
• May give server some relief as the instructions to build the page are loaded in the first call.

SPA Cons

• No SEO. The page depends on Javascript to be rendered and search mechanisms cannot read the Javascript;
• Hard to measure performance as it depends on client's browser to be rendered.

SSR Pros

• Better SEO. The pages are loaded from the server side and don't depend on Javascript to be rendered.
• Better performance measurements as they are rendered at the same place.

SSR Cons

• User cannot interact with the page unless it's fully loaded.
• More usage of the server because every new page needs a call to the server.

Conclusion

Both approachs are very powerfull and have specific advantages and disadvantages what does not mean that one is better then the other and you should think what problem your app wants to solve to decide which approach to choose. If your page depends on SEO, you should go for SSR. On the other hand, if SEO is not important and you want a experience more fluid choose SPA.

Did you like the content?

Share with a friend who would enjoy it and tell me in the commnets what you would like to see in future posts.