Optimising Static Assets

Modern websites are created using a vast number of static assets, such as images, Javascript files, and stylesheets. These assets quickly add up to large page sizes and give your users a slow and undesirable experience. Even if your website backend is fast, static assets can really damage your user experience. Your assets can be optimized in a number of ways to help speed up your website.

Image Optimisation

The most obvious optimisation is to simply reduce the quality of your images, and therefore reduce file size. Done correctly, this can decrease the overall download size of your website by a large amount with only a very minor degradation in visual appearance. The file format also matters here, photographs and realistic images should always be stored as JPG for the smallest possible file size. Other types of images should be stored as PNG to keep crisp, sharp edges.


Minifying assets is a process which strips out all unnecessary characters from text assets to be used in the production environment. This includes unneeded whitespace and comments. While unusable in development, this can reduce the filesize by a large portion.

Minification can be applied to HTML, CSS and Javascript. It can be taken a step further by merging the same types of resources. For example, if you had a number of Javascript files, it would help performance by merging these into a single files. Even if some of the code isn’t used on all pages, this reduces the connections needed and the whole file can be cached in the browser on the first visit to the website.


Content Delivery Networks (CDNs) are used to globally distribute your assets, so that users browsers can download your files from a server closest to them. This allows for the assets to be downloaded quickly and reduces load on your server.

CDNs have another benefit. Browsers generally limit the number of connections to a server to 6, using a CDN adds a different connection on your page allowing the browser to download more at once.

CDNs are best suited to sites with a globally distributed audience. If this isn’t the case, the other option is to simply add a subdomain to host your assets to get around the 6 connections limit.

Server Configuration

The easiest optimization of the lot is to enable GZIP on your web server. Once enabled, GZIP compresses your assets on the fly to be uncompressed in the client's browser. GZIP works best on text-based assets and can compress them as high as 70%-90% (https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/optimize-encoding-and-transfer). GZIP offers little benefit to image assets due to them already being compressed.

What are load balancers and why use them?

To put it simply, load balancers are a way of distributing work across multiple computers. In web, they are often used to distribute HTTP requests across multiple servers, so websites can handle large amounts of traffic.

Server-side load balancers are the most common method in web applications; it usually consists of a software application that listens on an external port (e.g port 80) and forwards requests from this port to one of its backend servers where the web application is actually hosted. This setup means the client only knows about the load balancer and prevents them from being able to contact the backend servers directly.

Load balancers increase redundancy in web applications by removing servers from the backend groups if it starts misbehaving. Load balancers are often set up in pairs to avoid becoming a single point of failure.

Session Persistence

The majority of web applications have data they persist between multiple requests from a user, for example, a server might need to know if a user is logged in. This causes a problem in load balancers applications as data is normally stored on the server itself, but this would mean other backend servers would not be able to access this data. The first way to solve this, is to make sure the user always connects to the same backend server. While this would work perfectly fine while the server is up, if that server become unavailable, it would mean the data would be lost when the user switched to another backend server.

Another option is to store the session data in the database, this allows any server to retrieve the session data, but increases load on the database server, so can affect performance. Sessions can also be stored in browser cookies, where the content of the session is encrypted. This allows the load balancer to simply forward the session along to the application and does not matter which backend server the user is connected to.


Along with the obvious benefit of spreading load across multiple servers, load balancers often have a range of features to help with the deployment of web applications.

Auto scaling during high loads

Web applications generally have times of the day at which they are used a lot more than others. This is sometimes a predictable pattern (e.g. more usage during work hours), or can be the result of an unexpected spike in traffic. Both of these can be fixed by deploying a huge number of servers to cope with much larger amounts of traffic than needed, however, this is very wasteful as resources that are not needed at all times are being paid for. This can be combatted by only increasing the number of servers when the traffic is high. When a load balancer is being used, this is very simple. Servers are simply added to the backend server pool and your application will now be able to cope with the increase in traffic. The user doesn’t need to know about the new servers, and they can instantly come into use to deal with the high load.

HTTP caching

HTTP caching allows the load balancer to cache static and dynamic content, so that if it receives a request for an object that it has cached, it can simply return it and not have to contact a backend server. This reduces load on the backend servers and improve performance as there is no network transfer between the backend and the load balancer. This comes at a cost of the storage of the cache. The cache can often be stored in either memory or on disk. Memory is much faster than a disk-based cache, but is often more limited.

SSL Offload

SSL is computationally expensive for web servers to handle. You can reduce the cost of SSL on the web servers by performing the SSL operations on the load balancers. This allows the load balancer to send the request as a HTTP request to the backend server and also allows the load balancer access to the request allowing it to perform more advanced features.

DDoS protection

Being DDoS’ed can be difficult to handle, some load balancers include features that mitigate attacks allowing you to better handle the attack and reduce the effect on your users.


Having your backend servers behind a load balancer means that their traffic can be heavily restricted, as the traffic they receive should only come from your servers. This means they are more secure as it is more difficult to detect and attack them.

Updates rollout

Deploying updates in a live application can be a daunting task. Updates could break your application and bring the whole service crashing down. Using a load balancer allows you to pull a server out of use while it is being updated without any affecting your users. Once the update is completed, you can then slowly increase its load until it’s certain the build is okay. This process can be done automatically and allows continuous deployment without too much risk to the service.