In this Tech Talk, Dane, a Senior Developer here at Fog Creek, summarizes talks he heard at An Event Apart conference in Atlanta, discussing Performance Budgets in the context of Web Development. He covers what a Performance Budget is and why they’re useful along with details about WebPageTest.org, an open-source tool for testing a webpage’s performance.
About Fog Creek Tech Talks
At Fog Creek, we have weekly Tech Talks from our own staff and invited guests. These are short, informal presentations on something of interest to those involved in software development. We try to share these with you whenever we can.
Content and Timings
- Introduction (0:00)
- What’s a Performance Budget (0:53)
- Why use a Performance Budget (1:40)
- Factors Impacting Performance (3:00)
- Types of Performance Budget (4:00)
- Overview of WebPageTest.org (6:18)
- Resources (8:44)
I went to An Event Apart, Atlanta and one thing that was actually touched on by five out of the twelve talks were Performance Budgets. So it seems like the obvious thing to kind of summarize and bring back. A lot of the examples, because this is more designer-centric a lot of the examples are taken from website design consultants. It’s not so much like ‘you’re making a new web app so you should do X, Y, and Z’. A lot of it is like, oh you’re working on a new website for a client and they want a flash bang thing. How do you balance that with performance?
That’s just kind of to give context from where these examples are coming from and this slide deck is basically a summary of the Design Decisions Through The Lens of Performance presentation that was given by Yesenia Perez-Cruz. There’s links to all this stuff on the resources slide at the end.
What’s a Performance Budget
A performance budget is using your target load time for a website or web app to dictate the file size of your site’s downloaded assets. The idea behind it is that you think about performance from day one, you set a performance budget early, you measure it throughout the project and you stick to it. A budget is no good if you just go over budget all the time.
Why use a Performance Budget
“We’ve remade the Internet in our image. It’s obese.”
There are ludicrously large web sites and broadband is becoming more and more prevalent but especially for mobile sites. Sometimes it’s easy to take for granted your snappy fast 4G connection in New York City when indeed your market is rural Texas or something where there isn’t 4G or whatever the case may be.
We’ve all been on board with things where performance started as a goal and ended up getting out of control. Performance has a tendency to be one of those goals that’s easier to slip which is disappointing. The example that she used as a consultant is balancing fast, functional and lightweight with beautiful, memorable, on brand, that kind of thing. “Good performance is good design.” There’s all sorts of like pithy quotes that are good stuff to keep in mind.
This one actually I thought was really interesting. “People will visit a Web site less often if it is slower than a close competitor by more than 250 milliseconds.” Of course, I don’t know what the sample was based on or what types of websites, but that’s not a lot of time before a customer is potentially willing to switch to a competitor. This is obviously important stuff.
Factors Impacting Performance
There’s tons of things that go into a website’s performance but file size is obviously one of them and the context of the performance budgets for the talks that mention them is focusing on asset sizes rather than all of these other things. A lot of these websites were not necessarily static, but largely static. The big point was hit enter on a URL and how quickly is the site loaded and ready to use.
Think about performance from the beginning not implement the whole site and then worry about it. Establish a performance budget and then document it, communicate it, and test against it because you are only as accountable as you force yourself to be.
Deciding a page cannot exceed 500K when a mock-up containing three carousels and a full-screen high res background image has already been approved isn’t going to do you a whole lot of good. This is just driving home the point of you should be thinking about this stuff up front, not implementing this big fancy thing and then in the end being like, “Oh crap. It takes like seven seconds to load. That’s no good.” Having a predefined budget is a clear, tangible way to frame decisions about what can and can’t be included and at a suitably early stage in the project.
A lot of the focus was just recognizing and communicating to clients from the presenter’s perspective the consequence is the thing; like I really want a carousel at the top of the page that has 17 images in it. Well that’s going to make the web site slow. Or, I want to use 16 different type faces on my splashy landing page and that’s going to affect things. There’s a trade-off there.
Types of Performance Budget
They summarized two major types of performance budgets. We can use both of them. One is this idea of a user experience budget. Our pages should take no more than 10 seconds to load over a sub-3G connection. Some of them are more technical oriented in terms of how the web site functions. Our pages should weigh no more than 400kb and make no more than 15 requests.
The whole point is just like with a financial budget. You budget things and if you need to take money out of one category you probably have to … If you are going to add something rather to a particular category, that money has to come from somewhere. The same concept is being used here for performance budget.
Overview of WebPageTest.org
What tools are there to do this stuff? If you haven’t already seen it WebPageTest.org is Amazeballs. This is what it looks like but basically what it does is it lets you set up tests or a series of them against one or more websites and then it will make those requests. It will track things like the developer timeline graph. You can even have it record video. It tells you both from, for example right here we are talking about repeat view so first view and repeat view. With a cold browser cache and a warm browser cache, how long does it take to load the content? How long does it take to get to first render or the first style content on the page? How long does it take for the page to be responsive and ready to use? It’s really cool. There’s this scripts tab where you can actually do things like set up authentication cookies. When I was using this for FogBugz on-demand, I got to set the authentication cookie so that it just goes directly to the list page.
This is the report card for WebPageTest.org. It’s not that bad. What I ended up using for all of these tests, I tried to look up what is the average US broadband speed? According to NetIndex.com apparently the average broadband in the US is about 33mb down and 10mb up.
Loading WebPageTest.org. with WebPageTest.org. It takes 5.75 seconds before it’s fully loaded with a cold cache and 4.7 seconds before it’s fully loaded with a warm cache.
That’s a very high level synopsis of it. There’s all sorts of more detail in the slide deck. It’s all linked through here. This is the presentation that I mostly summarized but it was very targeted on this. With WebPageTest.org. is awesome. It’s open source so we can download it and run it ourselves if we don’t want to run it in the Cloud. Another resource you can lean toward is Google PageSpeed. Another cool thing is Grunt-perfbudget. It is a grunt task that uses WebPageTest.org so that you can say this is my performance budget and actually hold me accountable. So it’s pretty sweet.