Tag Archives: performance improvements

It’s not just about being the fastest…

First published on Performance Calendar on 21st December 2013

I have been doing a lot of work this year about creating a performance culture within a company. This is an essential step on the route to creating good performance in your products and only when you start treating performance as a first class citizen will you start to get buy in to the time and effort needed to create performant systems, both from the developers and from the business as a whole.

This is a costly process and requires an investment of time and effort from a company to fully implement and the business will expect to see benefits back in return for this investment.

I would like to address two common problems that cause the value of this investment to be undermined.

1) Solving the technical challenge not the business problem

When I have talked to some developers who are getting into performance and trying to get buy in from their business and are struggling I often hear the same complaint – “why don’t they realise that they want as fast a website as possible?”.

To this I always answer – “because they don’t!”. The business in question does not want a fast website. The business wants to make as much money as possible. Only if having a fast website is a vehicle for them doing that do they want a fast website.

The key point I am making here is that it is easy as a techie to get excited by the challenge of setting arbitrary targets and putting time and effort into continually bettering them when more business benefit could be gained from solving other performance problems.

To address this we need to take a step back and address exactly the performance problems that are being seen and how they are impacting the business.

These may be slow page load when not under load. Equally likely will be that they suffer slowdowns under adverse conditions, they suffer intermittent slowdowns under normal load, they use excessive resources on the server necessitating an excessively large platform or many other potential problems.

All of these examples can be boiled down to a direct financial impact on the business.

As an example, one company we worked with determined that their intermittent slowdowns cost them 350 sales on average which would work out to £3.36m per year. This gives you instant business buy in to solve the problem, a direct problem for developers to work on and a trackable KPI to track achievement and know when you are done after which you can move on to the next performance problem.

Another company I worked with had a system that performed perfectly adequately but was very memory hungry. Their business objective was to release some of the memory being used by the servers to be used on alternative projects (i.e. reduce the hosting cost for the application). Again a direct business case, a problem developers can get their teeth into and a trackable KPI.

To sum up – start your performance optimisation with a business impact, put it into financial terms and provide the means to justify the value of the development efforts to the business.

2) Over optimisation results in technical debt

The second issue I would like to address is the idea that we should always build the most ultra performant system.

No – we should always build an APPROPRIATELY performant system.

Over optimising a system can be just as negative as under-optimising. Building a ultra performant, scalable web application takes many factors such as…


Building highly performant systems just takes longer


Highly optimised system tend to have a lot more moving parts. Elements such as caching layers, NoSQL databases, sharded databases, cloned data stores, message queues, remote components, multiple languages, technologies and platforms are things that may be introduced to ensure that your system can scale and remain performant. All these things take management, testing, development expertise and hardware.


Building ultra performant website is hard, it takes clever people to devise intelligent solutions, often operating at the limits of the technologies being used. These kind of solutions can lead to areas of your system being unmaintainable by the rest of the team. Some of the worst maintenance situations I have seen have been caused by the introduction of some unnecessarily complicated piece of coding designed to solve a potential performance problem that never materialised.


These system require financial support in terms of hardware, software and development/testing time and effort to build and support.


Solving performance issues often is done at the expenses of good practice or functionality elsewhere. This may be as simple as compromising on the timeliness of data by introducing caching but often maybe accepting architectural compromises or even coding good practice compromises to achieve performance.


The warning I want to give here is to understand your performance landscape, set your KPIs, define your performance non functional requirements, set performance acceptance targets or whatever method you use to determine how your application is expected to perform.

This action is essential to allow developers to be able to make reasonable assessments of the levels of optimisation that are appropriate to perform on the system they are developing.


Leave a comment

Filed under Opinions

Making Slow Websites Faster, Quickly

Intechnica recently hosted an event called Faster Websites – aimed at discussing with retailers some of the means and methods that can be adopted in improve performance of their online presence.

As part of the preparation for this event we evaluated the websites of the potential attendees as well as the top 50 leading retail sites in the UK.

As would be expected there was a wide range of results from the very fast to the quite slow.

I had a look into the performance of some of the slower sites to see if there were any quick wins that I could propose to improve their speed. I did a very limited investigation using WebPageTest under normal traffic conditions (as far as I know) and came up with the following observations.

Most follow general good practice

With very few exceptions most were doing the obvious things (minifying javascript, compressing content, using a CDN etc). This illustrated that there was unlikely to be a simple, config based solution to the slowness.

Slowness was caused by client side, not server side, issues

None of the sites spent more than 0.5 seconds waiting for a server response, indicating that the server is not struggling to return content. This is as would be expected for a site homepage that is not under load.

Very large page weights – especially javascript

A large amount of the slowness was being caused by simple page weight issues. All of these sites were requesting well over 100 elements with some requesting over 200 items.

The largest chunk of this was images, as was to be expected. As these are retail sites, there is an argument to be made that high quality imagery is to be expected and is essential for business. However one site was requesting close to 70 images, taking 3.5mb of data. It would certainly be worth investigating whether these images could be compressed, loaded asynchronously or even just removed.

Of more concern to me across all these slow loading sites was the general size and number of javascript files that were being requested. Sites were requesting over 40 distinct javascript files and file sizes totalling 300kb+ were common, with one site topping 600kb of javascript content. In most cases this javascript had already been minified and compressed. In all these cases the use of javascript should be fully investigated and rationalised.

CSS and even HTML files were similarly large (50kb+) and could equally be rationalised.

Complex DOMs

Most of the slower sites had more complex DOMs, often topping 2,000+ elements. This does not necessarily cause an issue but when combined with complex javascript and content manipulation it can easily lead to slowdown.

In the examples I tested this was illustrated in how long the startup event was taking for some pages. In one example this took over 1.5 seconds. This illustrates a page that is far too complex and needs rationalising.

3rd parties causing slowdowns

There were a couple of sites that were slowed down in their load time by waiting for responses from 3rd parties for content (e.g. from Facebook). In one case this was causing a 12 second delay.

As a site owner you really can’t let your performance be in the hands of 3rd party content. You must aim to make all these calls asynchronous after page load if possible.

Part of any performance assessment should include poor performance of these elements.

Overall the impression that I got was that effort on these systems was still mainly focussed on providing server side performance, and the state of the client side was being generally ignored beyond following standard good practice. A more considered approach could easily (days not months of effort) speed these pages up dramatically.

Leave a comment

Filed under Opinions

The Joy of Performance Improvements

I think that most developers get in to development for one of two reasons – they like solving problems, or they like building things. For me when I got into it is was the latter. I loved the fact that I would build things that people would then use (admittedly, I have often also built things that people didn’t use).

However as my career has progressed I have realised that by far a more enjoyable and satisfying element of development is working on performance improvements.

Since I moved into management I don’t get to work on development as much as I would like (which would be all the time), but recently I have built a system from scratch to delivery while also working on some performance improvements to an area of a site that had been declared “not fit for purpose”.

Comparing the two experiences, there was just no comparison. I’m talking about the experience of taking a failing system, investigating, manipulating, testing, making amendments, re-testing, assessing the impact of tiny changes, assessing the likely impact of large changes, finding out why elements that perform independently do not perform in combination, re-testing again, making another small improvement, re-testing, re-investigating and repeating it until performance is acceptable – then doing a few more rounds until performance is awesome. This was soooo much more enjoyable and rewarding than just building a system from scratch.

I’d recommend any developers to try to get involved in this side of development. That’s why I set up a performance management and improvement company!

By the way, if anyone is interested, the outcome of the performance improvements was taking a process that was taking 45 minutes to run down to running in 3 minutes. The target was 10 minutes.

1 Comment

Filed under Opinions