Performance on the web doesn’t come for free. It’s the result of a concerted effort to make sites fast. It takes conscious thought, and, occasionally, sacrifices of both time and desired features.
We want sites that perform feats of functionality and user interface complexity that were unimaginable in the early days of the web, but we also want sites that we don’t have to wait for. In fact, forcing our users to wait has repeatedly been shown to reduce revenue across most web business models, whether it’s lead generation, publishing, or eCommerce.
In many ways, we can think of performance optimisation as a balancing act: on one side there’s the features we want to implement, on the other there’s a desire to create fast sites. Existing web technologies impact the position of the fulcrum — the faster the tools we have, the more features we can include before the whole thing becomes unbalanced and topples over into unacceptable performance.
What’s the best way to approach maintaining a balance? In practical terms, we usually either add features until performance becomes so bad we have to spend time optimising the work that’s already been done, or we design and build for performance from the start, in the knowledge that it will limit what we can do.
Not long after, Vox Media issued a mea culpa, admitting that its sites performed poorly and that the company was declaring “performance bankruptcy,” which seems to be their way of saying that they’re going to do something about performance.
The interesting part is this:
In a nutshell, it means we’re consolidating all of our performance debts and working holistically to get back in the black. The first step in the process is to take an honest look at where we’re starting. After all, you can’t pay off your debts if you don’t know what they are.
In its early days, Vox Media was all about driving traffic, building a great product, and generating revenue. Performance didn’t get a look in. Now the issue has become critical, Vox is going to have to spend significant resources doing something about it. They chose functionality first.
The alternative to performance bankruptcy would be to implement workflows and processes that force a site to remain performant throughout its life. One of the most common ways to approach this is to have a performance budget: a page can have whatever functionality the designers want, so long as it doesn’t tip the scales on metrics like number of HTTP request or overall bandwidth requirements.
What’s interesting about this method is that it doesn’t say: “you can’t have feature X”. It says you can have feature X but only if you can find a way to implement it without blowing the budget. There are two major effects on the development process here:
- It forces developers to come up with novel solutions that implement the features they need in the most performant way possible.
- It forces developers to choose — they can’t just throw everything at the wall to see what sticks.
“Performance first” is a more mindful approach to developing a site. It’s the difference between a precisely crafted sonnet where every line and syllable count and Game of Thrones. In the long run, it’s likely to result in a faster site, less performance debt, and happier users.