Asp.net mvc SPA app server side rendering for Performance

Question

We're trying to squeeze as much performance out of our single page application written in asp.net mvc. The current layout is:

• Asp.net mvc server side which talks to an SQL Database
• Clientside SPA written with JS/Html5 + requireJS and KendoUI

Our major performance issues seem to be that the SPA side of things is quite chatty with the Server to retrieve JS and HTML files required for the current pages and also to push and pull data from the SQL DB via mvc WebApi.

Im wanting to somewhat change up our architecture to limit the chattiness between the client browser and the server. I'm reading all about server side rendering but it seems like it would be a major rewrite to put that into a mature application at this point.

Just wondering if anyone had any advice on methodologies to approach this issue and any libraries to checkout?

Answer 1

I'm assuming in this answer that your performance problem is the usability kind: The user feels the application is slow. If so you should be aware that what people actually remember is not, was the application slow, so much as was it difficult to complete the task they were trying to do (sorry I can't immediately find the source for that research/conclusion).

But anway. I would start by distinguishing out two quite different things:

• The retrieving, or rather, bundling of static files
• The ajax calls to service endpoints

The static files problem is not a problem. It should not involve any architectural changes, but is a learning curve. You address it with WebGrease (or alternatives) and/or by using BundleConfig . Both of these are part of the out-of-the-box aspnet template projects.

The chattiness of api calls is very different. Resolving that is a case of reviewing your service & application design. I would probably

1. start with background reading eg websearch q=reduce+chattiness+of+service+design .
2. Draw some sequence diagrams of the conversations the client is having with the server; and a sketch of when those conversations are triggered.
3. Based on those pictures, start to think about how can you hold fewer conversations:
   • Can static/cacheable data be got in one big hit?
   • Can Ajax data reads get bigger globs of data at one hit?
4. And, can async patterns be used to mean that the user doesn't see any delay? Ajax data pushes should be async, so should not cause a big performance hit -- unless the application is structured in such a way that the user is waiting for a data push to finish before they can move on.
   • Study the UI design of applications–facebook, trello–which do their data pushes in the background so that the user doesn't wait.

Finally, I come back to my opening point that it may be all about UX design not under-the-hood performance. Can a user complete the task fairly easily? Have any actual users told you it's slow, or are you just assuming it is? Sit with a user and watch how they work; what is actually bugging them?