Web apps – all the things you don’t have to do on your own. Part 2: Performance

Web apps – all the things you don’t have to do on your own. Part 2: Performance

Part 2: Performance

Read Part 1 of the series: Non-functional requirements

Attention spans are getting shorter all the time. If no page content is shown in a few seconds, users will close the tab and go somewhere else. 

Also, if they see it’s loading and loading, and there is no possibility to interact with the application, most likely this time waiting will be spent thinking about your competitors and how poor of a user experience you have delivered. People want to jump into your digital solution, check something, or do something quickly using their smartphones, tablets or laptops, and then move on.

Interview with Stefan Butzlaff: Being relevant to the customer

When we speak about the performance of anything, usually there’s this typical voice that says ‘let’s buy / rent a better stronger hardware and get over it’, because the cost of a developer’s time is much higher. It’s true that a developer’s time is expensive but hardware based fixes are quite limited in terms of what you can achieve. 

Moore‘s law stopped a few years ago. CPUs don’t become faster anymore, we only get more of them (more cores). That puts an end to HW-only optimizations, if the architecture doesn’t allow for horizontal scaling. Most web sites don’t have such sophisticated setups: There is a web server, an application server, and a database. None of which benefit from more CPUs without further tuning and attention.

Plus let’s add the carbon footprint, avoiding smart optimizations, and generating tons of wasted electrical energy. This matters both for the environment and the economy.

Data transmission costs are not a free resource. Either it’s the bandwidth you have to buy or the transmission packages (like N TB / month etc.).

The Internet is not a magical black box or legendary cloud that is everywhere around us. Geographies still matter and will continue to matter in the future, as you want your node to be close to your clients. Close in this context means within the same geographical region, with low latency (physics cannot be beaten) and high throughput (which price heavily depends on how far away you are from the nearest transmission hub).


One of the classical approaches for improving the performance of any IT systems is to use caching. This strategy is used everywhere from the CPU itself to any operating system, application, database, or file system driver, so there’s no surprise that caching is almost as old as the internet itself. 

The idea is always the same. If an operation always yields the same result upon the same input, don’t compute it again. Store and reuse the result. What you think will be used in the near future and/or more frequently, should be located where there’s a lower latency and higher transmission throughput. The cache does it at the expense of its capacity; it cannot store everything.

The cache, in the case of web applications, is located in multiple places. The best idea is to not transmit the content at all (again), so we have a client side cache and client side local storages (HTML5) with different expirations and refresh policies.

But that’s not all. It can be further improved by server side caching. Image generation (especially in case of dynamic images such as custom ads or graphs) is expensive, so this is another step that can be avoided in order to reduce the CPU and memory impact, and transmission costs as well. As a result your local browser cache can be filled faster with pre rendered images cached on the server.

It also applies to heavy Javascript modules which are the key components of a feature rich modern web experience.

What is special about the wao.io caching subsystem?

Wao.io implements multiple caches at different places in its infrastructure. There are varnish caches between the visitors of a website and the wao.io ‘optimization cloud’, there are caches between the wao.io ‘optimization cloud’ and the origin servers, and there are several caches within the ‘optimization cloud’ which contain the optimized files that can be revalidated when the actual http caching requires revalidation or retransmission. That way we ensure that we only re-transfer and re-optimize content when really necessary.

The next part of the series addresses image optimizations and also highlights some tech aspects for business as a holistic guide to improving web app performance 

→ Read about one more Avenga product Couper.io

Back to overview