One of the aspects of software development I’ve always enjoyed most is optimizing and improving performance, especially in the parts of a project that belong to its core and on which everything else depends.
With the widespread development of web applications, and given that the economy is moving into the digital realm, making a system perform well can provide a major competitive advantage and produce better financial results.
For some reason, I’ve always seen developers worry about performance only when it caused a system failure. If something worked—even with a few seconds of latency—almost nobody cared. Not anymore: now we have to shave off every last millisecond, and of course we win if the end user feels that something happens at the click of a button. I’ve also seen people try to solve serious performance problems by adding more hardware…
A system’s performance isn’t just about running at the right speed; it’s also about whether the person using it perceives that it responds quickly and instantly.
What I’m arguing in this post, especially when it comes to web development, is that we need to keep performance in mind from the very beginning to the very end of a project.
Not long ago, I read that users perceive something as instantaneous if they get a response in less than 100 ms; between 100 and 300 ms they notice a slight delay; between 300 ms and a second, the delay becomes noticeable; after a second, they experience what’s called a mental context switch (that is, they start thinking about something else); and after ten seconds (!!#***xxxx), they’ve abandoned what they were trying to do… In these last two cases, the chances they’ll leave the website are very high. A slow website drives visitors away like flies in an insecticide factory.
This has a huge impact on websites where a high bounce rate means fewer users and, therefore, fewer chances of achieving any kind of result on the site (new sign-ups, sales, downloads, and so on). Improving performance isn’t a secondary concern; without it, everything else we do probably won’t deliver the results we expected.
Traditionally, development teams have focused on the performance of what they build at the end of a project, when it’s almost considered finished and there may be little time left to improve it, because all the remaining effort has to go into finding and fixing validation bugs. I’ve made this mistake a thousand times myself… Still, as the saying goes, there’s nothing like pointing out other people’s mistakes when you’ve already made them yourself. Rather than presumptuously calling myself an expert, I should say that experience has taught me many (painful) lessons.
From the moment we start generating project assets of any kind, we need to start thinking about their performance. In other words, improving those assets needs to become part of our day-to-day work, especially if the project’s success or failure depends on how users perceive its usability and response times. I wonder: is there any software system that can afford to make a user wait several seconds to do something trivial? Sure, there are, and plenty of them, I’m afraid—and those products are probably on the verge of being replaced by the competition.
Working on performance from the outset isn’t without its challenges. In some ways, keeping optimization in mind means:
- Creating optimized code structures where saving even a few CPU cycles matters. It’s sometimes difficult to strike a balance between keeping code readable and not obscuring it through optimization.
- Keeping performance in mind also affects system design: there’s no point in creating a fantastic information architecture if the experience isn’t backed by fast, responsive navigation through the website.
Improving performance involves everyone working on the project: developers, designers, information architects, and so on.
Performance isn’t just about making a piece of code run as fast as possible; it’s a multifaceted concept, especially in a web application where many different elements are involved:
- Good performance depends on the software infrastructure we use (intermediate HTTP servers, SSL, and so on).
- We need a good caching strategy for the different elements of the website.
- We need to analyze whether using CDNs makes sense.
- CSS and JavaScript files need to be validated and optimized (minified and concatenated). Yes, styles can be optimized so the browser takes less time to process them and render the results.
- If images are used extensively, they should be optimized, and we should consider where the CSS sprite technique might help.
- If we build a website using RWD or RESS strategies, optimizing for different user devices becomes more complicated.
- We need to be careful about the external or third-party libraries we use and identify which ones might become a single point of failure (SPOF) and take the site down.
- What we consider good or poor performance depends on the type of project.
We can’t leave all this performance auditing and analysis work (quality work, in short) until the end. These tasks need to be part of our regular workflow or, where established, our continuous delivery or integration processes.
Most important of all (and perhaps most difficult): performance work on a particular aspect must be automatically measurable so we can track progress or regression as the project evolves.
We’re starting a new project for the electricity market, this time 100% web-based (with a backend that retrieves information from a huge cloud-hosted repository). In the first prototype, we’re incorporating all the performance metrics we’ll need to analyze the system as the project progresses over the coming months, as well as integrating automatic generation of all optimized assets into our regular workflow. I hope this work, which initially seems extra, will help end users perceive the site as responsive and, in turn, give them a positive impression of it.
I like Etsy, not only because it puts into practice a collaborative economy that, in my opinion, everything should move toward, but also because it has a highly motivated development team that shares its insights. They write a lot about web performance on their blog.