Why developers are still building slow websites

As developers, we’re constantly finding new, better ways to do things. Programming languages are evolving. Browsers are getting faster and are continually adding support for new features.

So why are so many websites still slow?

Shifting priorities

One of the biggest barriers to performance is a lack of agreement on the definition of a mature product. This problem is more and more common because of a big shift in priorities when it comes to product development and delivery. Today, the common belief is that the faster you release a product, the more profit you will make. Therefore, most people involved in development consider that a project is mature when it does what it was intended to do with as few bugs as possible.

So when did we stop keeping an eye on performance?

It all started with a need to deliver more products faster. To make up for the lack of developers needed to keep up with demand, companies started trading time invested in code performance in favour of faster delivery.

Reliance on frameworks

This started a new culture of over-abstraction, with any new project being more or less a spinoff from a previous one. The need to extend this across multiple commercial environments pushed developers to start building and maintaining open source distributed frameworks to allow everybody to build web products faster. This speed was achieved by being able to build a full web product using only the knowledge of the framework and the basics of programming.

This rush against the clock to build new products, combined with constant progress in hardware capabilities, transformed the way we write code today, towards a more reusable approach. We started to write code so it could be reused in future projects with minimal changes – but with almost no concern for performance. Users have also been fuelling this trend. They have become eager to buy better and newer devices, so they can run newer, more demanding software. People have simply begun to accept that in order to keep up with software requirements, you constantly need newer and better machines.


At a production level, this change makes developers put more emphasis on how the framework is used and how the code looks. This is only natural because it simplifies the sharing of code, as well as workflow continuity. It means one developer can pick up the work of another right in the middle of a project and carry it through to completion as if it had been their own creation all along.

This concept is known as code maintainability: the ease with which a developer can understand, change and use a piece of code. And one of the biggest challenges we now face is balancing maintainability and performance.

Understanding barriers to performance

One of the first questions a web developer should ask is "What could prevent the user from seeing this website?" I'm saying this because, as a part of a software production team, you want to be aware of what can go wrong with your web product from the outset.

Planning every new project with a list of potential anti-performant practices will allow everyone involved, from design to implementation teams, to avoid most of the risks ahead.

Among the most common performance anti-patterns is having big files as dependencies, particularly third-party libraries or frameworks.

Even though most of them facilitate the speed of production, they can significantly harm the user experience. Keep in mind that as a member of a development team, you won't see the same issues because you are probably not using an old or an entry-level machine, as many other web users are. Understanding these limitations can help drive your website’s performance KPIs.

Also, when you create a new product or update an old one, be aware that it’s not just your current customers who will use it – it is also an opportunity for new ones to do so. Analysing your bounce rates and the relationship between page load time and session length may give you strong insight into who wants to consume your website but can't.

By analysing your data on user interactions, you can tailor your new products and updates to their needs. This, together with the fact that we are now able to measure the impact of performance on profit, allows us to balance the cost of performant, purpose-built code versus the benefits that third-party libraries and frameworks bring in speed of delivery.

Ultimately, it comes down to "faster delivery" or "more satisfied users".

Striking the right balance isn’t always easy. There are different types of site: static websites, enhanced websites with some JavaScript widgets, public web apps, private web apps, and so on. Each has its own set of performance requirements. Furthermore, there are different ways to look at performance: for example, initial load/execution and later load/execution (via XHR requests or user interaction).

However, I believe that for many the pendulum has swung too far in favour of speed of delivery at the cost of performance and user satisfaction. And for ecommerce and brochureware sites, more satisfied users means higher profit, better product recognition and higher brand awareness.

Published date:  27 November 2017

Written by:  Dan-Bogdan Vasiliu

comments powered by Disqus

Filter By Service

Filter By Date