How to boost the performance of web applications

Today everything runs in the cloud and web applications have to handle huge amounts of requests. Things that were minor performance issues in the past are now considered major problems due to the large volume of clients. Every app is different and the biggest optimizations are usually in the business flow where you eliminate the need for certain things or reduce the requests needed to perform the task. However, there are some general things you should consider that can be applied to any web application and that is what we will be discussing in this article.

Static content is everything other than API calls. This can be images, CSS, HTML, fonts, and all sorts of scripts. This is very often the slowest thing to load when the application renders. Here are a few ways you can reduce the load

Compressing static content can prove to be a game changer. Static content is usually served by the load balancer but sometimes you have to serve it via your server. Fortunately, this is usually very easy to configure, for example in spring boot you can do it like this

you usually set the min-response-size because for very small files the compression worsens the performance. For this to be effective you should try to bundle things, serving a few bigger files is always faster than serving lots of small ones.

Make sure everything you are sending to the client is needed. Don’t send large images when you won’t display them in high resolution. Don’t use PNG if you don’t need transparency use JPG instead (SVGs are also a good option)

Don’t import libraries that you don’t utilize, same goes for fonts. Often we just import things until it starts working. Production applications can benefit from the reduced number of dependencies

Browsers can and will cache static resources if possible. The best way to do this is to add a suffix to your static files (for example timestamp of when they were created) and then set a long cache TTL, let’s say 1 year. This way the cache will never be invalidated and in case you need to update a certain resource you just change its suffix and the browser will take care of the rest.

Google search engine uses the website performance as a search rank marker. This places fast-loading sites above the slower ones and sites that give errors during crawling can even be delisted. All of these markers are based on the user experience and even if you are not interested in the SEO performance of your application you should still consider the tips given by these tools

When we are interacting with the server we usually make HTTP calls. There are a few things to consider here.

Things to consider when designing the API

Which one should you choose? It depends on the use case. Usually, static resources are best served in one big bundle. This way it can be properly compressed and latency reduced. API calls on the other hand typically have small responses and rely on parameters, so it’s hard to cache them and they are usually not compressed.

The cache is stored in the RAM and the RAM is really fast (compared to the disk memory). If you have a complex request that takes a longer time to complete or a computation that is requested very frequently (hot resource) you can store them in special RAM and not recalculate them every time. This has too major benefits

In case your server scales into multiple nodes the cache can’t be local and we have to use distributed cache.

Caches shouldn’t become too big as they might become expensive (hard disk is multiple times cheaper). Furthermore, the cache is lost on restart, so consider it as temporary storage, typically entries inside it have TTL and are automatically deleted over time.

This probably goes in favor of small requests, but generally speaking, long-running requests can really hurt the server scalability. In case you have a higher load and your clients occupy connections for a long period you will very quickly run out of available connections and the server will become unresponsive. Typically you would place a timeout on the request (for example 30 seconds) and if requests take more than that split it or optimize it.

When we say that a service is stateful we usually mean that requests need to be executed in a specific order or the same client has to go to the same service (node) also known as a sticky session. This is hard to manage and makes scaling hard. If your server nodes are stateless and independent from each other you will have no problem killing or spawning them on demand. Having said that, sometimes it’s impossible to avoid the server state.

Most version bumps usually don’t bring anything new to the table, but this doesn’t mean you shouldn’t update. Sometimes a new version updates the version of transitive dependencies. This can make your system more secure and less error-prone.

Updating the version of the language or the server can give you a performance boost. For example, Java 17 is ~8% faster on average than Java 11 and ~13% faster than Java 8. You can get a pretty good performance boost by just updating

Instead of making long duration call, process the work asynchronously. For example, clients submit a heavy task to the server and instead of holding on to the connection until the task completes, the server can return an URL where the client can track the progress, or even better push a notification to the client when the task is completed

The reactive style goes very well with single-page applications which are also amongst the best performing.

Most servers store and read data from a DB. As a consequence, oftentimes the DB becomes a bottleneck for the performance of the whole application. Having said that you should use the proper database and configure it according to your use case. Here are some tips for data storage when dealing with high loads

The information in this article shouldn’t be used blindly. Do your own research and perhaps use mine as a starting point. Every application is different and it’s very hard to define a single solution that will work for everybody.

Sometimes speed is not everything. Investing too much effort in making the application faster might not always pay off. Sync with the business and your clients. Do they need that speed? Don’t solve problems you don’t have.

Related posts:

Bad obsession. Don;t try to give me a line. Mark Godfrey

This Christmas and New Year, I have had the privilege to join the brilliant team at Dreamstar IOM Productions in Pantoland for their magical production of ‘Aladdin’. In the show I play PC Ping, a…

Today I have completed 30 challenges in Free Code Camp under the concept of Java Script and I have also learned array concept through self learning for my code contest.This is my first story i am…