SSR or CSR - what is better for Progressive Web App? (2024)

In this post, we’ll take a closer look at the implications of the choice between server-side rendering (SSR) and client-side rendering (CSR) in the context of developing progressive web applications (PWA). An SSR vs CSR face-off. But of course, it’s not as clear-cut as either CSR or SSR being innately superior to the other. The optimal choice between the two 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. Facebook is the perfect example of a CSR website and app, where the page automatically refreshes itself with new data without the user have to send a request. In fact, it was Facebook’s release of the React library that popularised a CSR approach to applications by making it more technologically accessible.

On the other hand, a web-based app serving mainly static content, like this website, would be expected to opt for an SSR approach. One of the main arguments for why (though CSR is making significant strides in that direction 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 choice in the context of PWAs. We’ll start with a quick look at web apps and then progressive web apps more generally – what they are and their advantages in comparison to the alternative of a native app. Then move on to the technical details of both server-side and client-side rendering, and their strengths and weaknesses in different contexts.

Web Apps vs Native Apps

If you or your organisation has taken the decision to develop a fantastic app you now have to decide on the tech stack that app will be built on. The first big call on tech stack is then often if the app should be a web or native app. Each choice has its pluses and minuses.

Web app strengths

1. Easy to share – web apps are easy to share via links which means they can be popularised through social networks or any other website or even search results.
2. Nothing to install – to start using a web app, all a user has to do is click on the link and they are in the app, which is opened through and runs on a browser. No software ever has to be downloaded to a device.
3. Multi-platform – because a web app runs on a browser, not hardware, they have a very wide reach and run the same way on pretty much any device with a screen, internet browser and good internet connection. The only thing for the software developers to worry about is the app’s responsiveness to different screen sizes, such as desktop and mobile.

Native app strengths

1. Easy access from device – no need to open a browser and go to a URL. Just click on the app icon on the device and it opens, ready to use.
2. Faster loading – with software already installed on a device and only the need to update content, native apps rely less on data being relayed to them via an internet connection so generally load faster.
3. More access to hardware capabilities – native apps can make more and smoother use of the hardware capabilities of the device they are installed on, like processing power, graphics cards, cameras and microphones.

Progressive Web Apps combine the strengths of web and native apps

The good news is progressive web apps (PWAs) go a long way towards combining the strengths of both web apps and native apps through an increasingly small compromise that can often swing the balance of considerations in favour of a web app instead of a native app.

What’s the difference between a regular web app and a progressive web app?

Like regular web apps, PWAs are built and live on the web. However, a progressive web app also features some native app capabilities like push notifications and the fact it is installable on a device. Is there, then, any difference between a progressive web app and an installable website. But there is more to PWAs. To qualify as ‘progressive’ a web app must tick a number of boxes:

• Reliability – a progressive web app should load instantly and always be available.
• Speed – a PWA should be fast and respond instantly to user interactions.
• Native feel – a progressive web app should be engaging and feel like a native app on the device.

Progressive web apps also feature two fundamental technical components:

1. The manifest – a JSON file containing all the code that creates how the app’s front end looks visually. Here’s an example on Github.
2. The service worker – a JavaScript file that works with the browser to create a layer between your app and the network. The service work allows for operations and features such as fast loading, caching, notifications and background sync.

Because PWAs use a single code base that accounts for a range of screen sizes they work on both mobile and desktop devices. In short, the strength of progressive web apps is the reach of the whole web while coming close to matching the engaging features of native apps.

All of the above is why, at K&C, we especially love PWAs. And if you have taken the strategical decision of going the progressive web app route with your next app the next question you should answer is if its rendering will be server or client-side.

SSR vs CSR – what’s the difference and why does it matter?

Historically, when a user opened a web-based application, the HTML the user interface and content is comprised of was brought onto the screen of the device by server-side rendering (SSR). The browser sends a request to the app’s server, which sends over a file containing the data needed for the page to be locally reproduced on the user’s device.

When the user clicks onto another page or refreshes the current page, the whole process is repeated with a single monolith file, containing the code of the page to be loaded, sent from the app’s server.

The advent of JavaScript frameworks, especially Facebook’s React, offered software developers a new way to render pages on a user’s screen that leveraged the increasing power of internet browsers and improving mobile internet speeds in developed economies. This is referred to as CSR or client-side rendering.

In CSR, the browser makes an initial request of usually a content delivery network (CDN) rather than server, which send a base ‘wrapper’ that contains all the static HTML, CSS and supporting file elements of a web page or application. These elements are then cached by the browser, which subsequently makes API requests via AJAX to fetch dynamic content JavaScript content rendered on the browser using DOM processing.

When a page is refreshed or the user clicks through to another, the browser only needs to fetch and render the dynamic JavaScript elements, not the whole page. For example, the feed on a Facebook page is dynamic JS while the header, footer and many elements in the sidebars etc., remain constant.

In CSR, the initial page load takes longer compared to SSR because it requires more JavaScript to be downloaded and parsed. A second HTTP request needs to be made to load the content then more JavaScript is needed to generate the template. Even if the initial JavaScript is cached it still needs to be parsed and the second request cant happen until the document is loaded.But once that initial load has been achieved, and what can be cached and parsed by the browser has been, subsequent page loads are faster and smoother than SSR, where all the information has to be fetched from the server each time.

In SSR, the server sends the whole page’s HTML ready to be rendered without the need for it to be parsed first.

Server-side rendering (SSR) or Client-side rendering (CSR) for your PWA?

A decision between the two architectural approaches to building a progressive web app should be taken based on both the technical qualities you require of the app and an understanding of the user profile. For example, if you know your user persona is most likely to have an up-to-date web browser, that would be in favour of CSR. If that’s in doubt and a poor CSR user experience could mean losing a significant number of potential users, SSR might be the better choice.

SSR is usually best for web apps that are heavily text-based like written media apps (eg. a newspaper’s web app). However, the extra demand on servers SSR entails means significantly more cloud budget might be eaten up if the app has a large number of users. If server scalability is an issue, for example you are not using scalable cloud-based server facilities, that could also be an issue for SSR.

The part of an app that usually takes up the majority of resources is database access. So regardless of whether an app will use SSR, CSR or a hybrid approach (which is increasingly common) an efficient database structure will have a big impact on performance. But CSR can help avoid database-related bottlenecks for apps that are heavily interactive.

A hybrid approach – using SSR and CSR for your Progressive Web App

Especially in the case of larger, more sophisticated web apps, a hybrid approach of combining SSR and CSR where most appropriate is becoming increasingly common. This requires more complex architecture but can make sense for apps with large user bases that might save significant sums by reducing server-load in some areas through CSR instead of SSR but also have text-heavy sections like a blog where SSR’s strengths come to the fore.

For some apps, it can be relatively clear that either SSR or CSR is the better, or necessary, choice. For others, it’s a less cut and dried judgement call and both options will have advantages and disadvantages that will need to be strategically prioritised to take a decision or opt for a hybrid approach.

If you would like to discuss the pros and cons of SSR, CSR or a hybrid of the two in the context of a PWA development project please do get in touch. We’d love to help!