Performance: design, budget, and test

Howdy, perfers! Last week we looked at ways to speed up the initial render of a page. That’s a great optimization if you have the time/motivation, but for many people it’s not their primary duty, and for some it’s not even included in the job description! But even so, it still can make or break the experience of a particular website. As Ilya Grigorik notes, “performance is not a checklist, but a continuous process“ (PDF, page 11). So how can you affect the process of building a site to make sure it ends up being fast and snappy?

Consider performance a design constraint

A great article by Brad Frost encourages readers to think of performance as a primary design element. Brad offers several examples that demonstrate how performance can be THE design element that users care about most. Whether they are aware is completely irrelevant, because ultimately poor performance equates to boredom or frustration, which results in people leaving your site or refusing to use your app. The fact that Facebook is a primary example should be a warning that no service is compelling enough to trump users’ expectations of instant gratification on the web.

Assuming you’re convinced, you’re probably asking yourself how you can enact change within your organization.

Setting a performance budget

Tim Kadlec has an excellent article advising us all to set a performance budget on each project. While it can be helpful to include speed or performance as a high-level project goal, eventually it will be the victim of another design decision unless performance is quantified and measured in some way. Setting a performance budget is one method to help a team to determine when a new feature or design decision is negatively impacting a site’s performance. Here are several methods which could be used individually or in tandem:

• Time until a certain event occurs. This should be accompanied by the device class or network connection. For example, “the homepage must begin rendering within 3 seconds on devices using a 3G connection”
• Total page weight. For example, “the homepage cannot exceed 500K”
• Amount of latency. For example, “individual article pages must not make more than 30 HTTP requests”

While your exact metrics may vary from site to site, a performance budget is an effective way to maintain a fast site throughout development, rather than scrambling to make optimizations at the last minute before launch.

Tools for measuring performance

If you’re looking for ideas on how to measure and track performance, take a look at some of my previous Webperf Wednesday posts: Automated Frontend Tools and DevTools link roundup. Good luck, and keep fighting the good fight! You users will thank you.