Top of the Requirements List
What’s the one factor that affects user satisfaction in every step they take, every time they use your web application?
It’s not the feature set. Users can overlook your site lacking some piece of functionality.
It’s not the design. Most people don’t mind if the site looks a little plain.
But there isn’t a user anywhere on this Earth who waits 10 seconds for a page to load and thinks, “That was great. I’m so glad it didn’t come back in 3 seconds.”
Speed is king. How fast your application runs determines how users think of it—how they think of you and your brand. This happens every time they click anything on your site. Every act of navigation, search and form submission is viewed through the lens of page-load speed.
A slow site feels outdated despite snazzy graphics and effects. As strange as it sounds, a slow application interface can make users feel like your site doesn’t care about them. The relationship between application responsiveness and user attention is one well-studied area of human-computer interaction (HCI), as Jakob Neilson describes in Usability Engineering:
The basic advice regarding response times has been about the same for thirty years
– Miller 1968; – Card et al. 1991
- 0.1 second: Limit for users feeling that they are directly manipulating objects in the UI . . .
- 1 second: Limit for users feeling that they are freely navigating the command space without having to unduly wait for the computer . . .
- 10 seconds: Limit for users keeping their attention on the task.
Everybody recognizes performance as a good thing. But we all know that “nice to have” features go out the window as soon as a project runs into trouble. Therefore we must put application speed front and center. Performance should be a “need to have” requirement from the very beginning of the project.
However, vague requirements don’t do the job. You need specific, tangible targets. The only meaningful way to make performance a requirement is to quantify the results you’re looking for.
Quantifying Performance
When gathering requirements for your next web application, you’re probably going to have to integrate with existing back-end systems. Hopefully you’ll get to redesign the front-end to match the new branding scheme. You’ll need to satisfy some feature set to match your competitors. These are all easily quantified, and make for good requirements.
In contrast, many non-technical project stakeholders view web application speed as an intangible. This is a misunderstanding. Performance requirements should be quantified according to the needs of the application:
- Type of site – A front-facing application, such as an e-commerce site, will usually have dramatically different requirements from an internal application or even a business-to-business offering.
- User base – High-traffic websites have a higher bar to clear in terms of due diligence for performance requirements. When are the current peak loads during the day? During the year? What kind of traffic might you expect over the lifetime of the application?
Regardless of application needs, however, the results must be measureable. We’re looking for specific and testable performance requirements. To get those, it’s important to distinguish the concepts of perception, speed and load.
Perception
Perception is how the application feels to the user. Users might report that a certain page or action feels slow or unresponsive because of the way the UI is designed.
While perception is a separate problem from how fast the page actually loads, it’s still important to user satisfaction. Perception issues are best approached by actually making the site faster, but can also be resolved by providing timely feedback. Give the user a “Loading . . .” message or a progress bar to keep them informed of their status. Responsive websites assuage user confusion.
The best way to stay on top of perception issues is to bring users in to test early in the development cycle. Their gut sense is actually the requirement here, so make sure you measure what you want to manage.
Note: it’s important to distinguish between perception issues and actual differences in performance from different machines. Make sure to test the application from a variety of locations to determine if the situation is caused by a network issue.
Speed
The speed of a given page is simply how fast it takes to load. This is also known as the Time To Live (TTL), which starts when the user initiates an action and ends when all components of the page are fully loaded. This is the best benchmark of real performance metrics for an individual user — simply, how long did it take between their request and the response?
The TTL of a specific page in an application is determined by the amount of file I/O, the size and number of web server objects, (X)HTML size, application logic and architecture and hardware. Each of these aspects should be examined and optimized individually. Often, significant savings can be had by just making the page smaller. Minifying script and style files and optimizing images can go a long way.
Developers should periodically check approximate page speed with FireBug’s Network option. Its graphical representation comparing time taken for each element of the page is particularly useful for noticing minor issues as they arise, such as missing files, bloated images, or long execution times. Fiddler is also a solid tool for this. These tools should be used alongside approximate TTL guidelines for each page and action, to ensure that the application stays on track with performance requirements.
Load
“How many users can the application support?” is a different question than “How fast is the application?” Page speed may be fine when only a handful of developers and testers are on the application, but slow to a crawl under a 50-, 500-, or 50,000- user-per-minute load.
It’s important to determine realistic goals for the application. These should include the number of users during normal and peak times. Be cognizant of the difference between page speed goals (e.g., “The Login page must display within 2 seconds.”) and user-load goals (e.g., “The application has to support a peak of 150 simultaneous users.”). Goals for load should be based on past application usage if possible.
Projects with load-based goals should use a load testing tool or employ a third-party load tester. (Most free load testing tools are limited in the amount of data they collect or the degree to which the load can be managed.) One method is to use third-party load tests as milestones in addition to regular self-testing within the developer team.
Recognize the Trade-Offs
There is an inherent tension between the richness of an interface and how long it takes for the user to see it. At some point you’ll need to ask yourself, “Does this project really need big, high-resolution images? Is that one user-interface effect (that depends on yet another JavaScript library) really a critical component?” Software developer Jeff Atwood lays out the stark trade-off in his article, Speed Still Matters:
What’s more important? Getting flash after 5 seconds, or functional no-frills layouts in less than a second? Let’s get our priorities straight.
This doesn’t mean that your application needs to mimic CraigsList’s extremely spare aesthetic. It just means that every decision for a richer interface — bigger images, cool effects, bigger CSS files — should be tempered by the knowledge that you’re slowly chipping away at the core goal of application responsiveness. As web developer and author Jeremy Keith puts it, “I wanted the site to look great, but I also very much wanted it to feel great . . . and nothing affects the feel of a site (the user’s experience, if you will) more than performance.”
That’s why making performance a specific, quantified requirement at the outset of the project is so valuable. It allows you to evaluate these decisions effectively all through the project. If you really need that JavaScript library, then you’ll need to pay for it by decreasing page size somewhere else.
Software consultant Brian Goetz sums up the right attitude:
The right balance is to integrate performance measurement and planning into the process from the beginning . . . Performance work should be driven by performance goals, which must be supported by performance measurement. Anything else is just “playing.”
Don’t try to look back at the close of a project and fix bloated pages retroactively. Empower your developers and project leads to keep a lid on unnecessary functionality. Lay out a performance standard in the beginning. Make web application speed a project requirement, and make it measurable.
