SSR or CSR for Your Progressive Web App?

Web DevelopmentPUBLISHED ON July 10, 2018 | MODIFIED ON August 11, 2020

SSR or CSR for Your Progressive Web App?

Weighing up The Decision Between SSR or CSR In A PWA

This post is on the subject of progressive web app development (PWA). More specifically, we’ll take a closer look at the implications of the choice between server-side rendering (SSR) and client-side rendering (CSR) when developing PWAs. An SSR vs CSR face-off. But of course, it’s not as clean-cut as one of either CSR or SSR being inately superior to the other. The optimal choice in the context of a specific Progressive Web App, will come down to a combination of the specifics of the technical use case and strategic priorities. 

For example, CSR will most often be the choice for a PWA serving dynamic content. The perfect example is Facebook, where the page refreshes itself with new data automatically. Of course, it was Facebook’s release of the React library that popularised a CSR approach to applications by making it more technologically accessible. An app serving static content, on the other hand, would traditionally opt for SSR. One of the main arguments for why (though CSR is making significant strides in that direction and muddying the waters here which we’ll explore in more detail later), is that SSR has traditionally been the better choice in the context of search engine optimisation (SEO) because SSR pages are more accessible to search engine bots and crawlers.

But let’s take a look at the finer details of the SSR vs. CSR choince in the context of PWAs. We’ll start with a quick look at progressive web apps more generally, what they are and their advantages. Then move on to the technical details of both server-side and client-side rendering, and their strengths and weaknesses in different contexts.

Progressive Web Apps (PWAs) vs. Traditional Web Apps

 A simple development process, instant user interaction, the ability to work in autonomous mode. Yeah, that’s all about PWAs, whose benefits for modern business processes are hard to deny.

  1. Users can switch to progressive applications from links in social networks, while browsing web pages, or directly from search results.
  2. The proposal to install a progressive application is shown only when the web application meets certain criteria.
  3. App installation is instant. All components that require a long download have already been installed into the cache when the user first visited the website.

On the back of total installation of conventional (native) web applications, PWAs gain traction by acting in a smarter way compared to their ancestors, whose go-go days are gone.

PWAs vs Native Apps

We hope you realize  how much we love to work with PWAs. And in this article, we’d like to help you migrate your website to PWA and show how you can do that in the most seamless way, according to the opinion of K&C developers.

Should Server-Side Rendering Be Your Choice?

Creating a PWA doesn’t necessarily imply creating it from scratch. If you’re developing a modern SPA (single-page application), most probably you implement something similar to an app shell. PWA doesn’t include anything extraordinary, considering architecture and items to render:

  • HTML, CSS and JS files
  • Images, media
  • Fonts
  • Data used by JS to create content

Until recently, the most advantageous strategy to migrate was to rely on server-side rendering, a mature technique with rich tooling, which is not only perfect to render static content, but is also suitable for SEO and all connected to it.

Server-side rendering is an ideal solution if your app is intended to work with a great deal of data. Examples are calendars, mail boxes, really any content platforms. Moreover, the realization of server rendering is in no way worse on the client side. Almost any framework used for the client side (Java, Python) can be implemented under server-side rendering.

The situation is a little bit more complicated if it comes to JavaScript, but this can be also dealt with. We take Node.js and Express.js in order to get a basic server and choose a framework for page rendering. This can be a Handlebars.js template or React. Or if you want to dig deeper, you can even resort to such frameworks as La1 (Gmail is based on it) or GWT (Google Web Toolkit), yet they’re not so popular today.

From our own experience here at K&C, we’d advise you to go for the whole functionality on your own, rather than completely rely on ready-made solutions.

Or Client-Side Rendering?

Client-side rendering (CSR) is in its turn more suitable when it comes to dynamic content. Also, it’s more beneficial considering browser performance.

In fact, each website does a kind of CSR, particularly now when there is a strong tendency to use mobile web. Any part of a page that is dynamic (a draggable slider, a sortable table, a dropdown menu) will implement CSR. However, while a major part of a SPA functions on the client side, the files do have to come from somewhere.

At this point, universal (isomorphic) JavaScript comes in, where the same rendering code is used as on the server as well as on the client side.

The point is that you don’t have to choose sides when there is a chance to use both approaches and benefit from it. Let’s not forget that server was, is, and will be always responsible for data. And with such technology as NodeJS, there is little difficulty to migrate the CSR code to the server and use it for SSR, and vice versa.

The main trick with all this is to not make your life difficult with unnecessary work. Choose both, and the K&C team will help you to realize it in the best way possible.

Related Service

Software Development For Startups

Read more >

React Development Services

Read more >

Nearshore IT Outsourcing

Read more >