Fog Creek

Performance Budgets for Web Development – Tech Talk

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)

Transcript

Introduction

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.

The very high-level summary; take your target load time, multiply it by the expected connection speed and then see your size budget. Once you have your size budget, you can divvy that up budget up amongst your site’s various assets; HTML, stylesheets, web fonts, JavaScript, images. A lot of this is just an approximation. It’s the approximate or average speed of your target user. It’s really useful if you’re targeting for example mobile because then you can have a much better idea of what your customer’s connection speed is going to be and a bunch of really cool quotes.

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 a whole range of things that can impact your website’s or web app’s performance. There are the very basics, like the things that have to be downloaded over a wire into your browser; HTML, stylesheets, web fonts JavaScript, images. Then there’s obviously much more that goes along with that. There’s things like your server’s response time using a content distribution network, cache headers, what’s the bandwidth, the client’s computer resources and blah, blah, blah, blah, blah. It doesn’t matter if you only download 50K if you then do terribly non-performant client-side stuff.

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.

This article length at the bottom of this image where this image is taken from goes through all this stuff in much more detail. The idea is for whatever reason you’ve decided that our available asset budget is 114kb, how are you going to divvy that up? Html CSS JavaScript uses Web fonts. If you can make a compromise of just using system fonts, okay, you can get read of that 22.8kb of Web fonts and maybe you can put that toward having fancier, higher resolution images or something like that.

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.

You can do all sorts of different cool stuff with it. This is the screenshot of the basically ChromeTools loading thing and it’s awesome. It shows CPU utilization, it shows bandwidth, it shows browser main thread, browser background thread. It breaks down and color codes html assets, this is JavaScript, This is CSS. The green line is first rendered I believe which is like the first time it goes from being a blank white page and the blue line is completely loaded.

You can drill down and click on any of these and see information about the requests, headers, and all sorts. It also gives you all sorts of breakdowns. This is exactly where your performance budget can make a difference. Contact breakdown by MIME type on first review; 52% percent of what you’re downloading is JavaScript. It weighs 576K roughly. It also will break it down into hard drive so you can say ‘oh man we’re downloading a whole crap load of JavaScript’. It will also break it down by size rather than number of requests. It’s useful to have this kind of stuff.

Resources

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.