Category: CommunityThe Balance Between Performance And Functionality

Share this post...Tweet about this on TwitterShare on Google+0Share on Facebook0

Balance Performance And FunctionalityPerformance 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.

Functionality First

Vox Media is a web publisher that owns a stable of popular sites, most notably The Verge, Polygon, and SBNation. Recently, the Verge in particular has come under fire for its dire performance. This is part of a conversation that’s been making the rounds for some time now. Nilay Patel, The Verge’s Editor-in-Chief, entered the fray with an article entitled “The Mobile Web Sucks,” in which he largely blamed the performance problems of mobile users on bad mobile browsers. His argument created something of a hostage to fortune, and not long after, a developer fired back with “The Verge’s Web Sucks,” pointing out that the Verge performs badly for any number of reasons — like the 263 HTTP requests and 7 MB of JavaScript it downloads over a half-minute load time — that have nothing to do with shoddy mobile browsers.

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.

Performance 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.

Image: Flickr/Kinchan1

DevelopersEnterprise ITSystem AdministrationWeb Server
Aug 13, 2015, 12:23 pmBy: Corey Northcutt (0) Comments

Leave a Reply
Surround code blocks with <pre>code</pre>

Your email address will not be published.

Newsletter

Sign up to receive periodic InterWorx news, updates and promos!

New Comments

Current Poll

  • This field is for validation purposes and should be left unchanged.

Forum Posts