 I'm Meno. I'm from the Netherlands. And I make websites. I guess as a lot of you do too. I realize it's been a long day of complex talks. And I realize I'm the only obstacle between you guys and a couple of cold beers. So don't worry. I'm going to keep it short. My talk is timed to about 25 minutes. So it'll probably be 20. And it's no more mentally challenging than an episode of Dora the Explorer. Before I get started, I'd like to get to know you a little better. By show of hands, who here has ever received the request? Can you improve the performance of this page? By show of hands. That many. That's good. The other ones, don't worry. You will get the request one day. It's such a simple question, but it's really, really hard to answer correctly. And through this presentation, I would like to give you some tools to deal with the request like that. I'll give you some ideas about how to approach it. And some tips to help you identify what the issues are. But before we get to that, let's imagine this scenario. This is a race car driver. And he has a really cool car. And imagine that he just got this car from his team of engineers. He's taking it for a spin, driving a few laps. He comes back to the pit. The engineers ask him, what do you think? And he just asks, can you improve the performance? And that will be a silly question, right? Because engineers are not magicians. Performance is meaningless if you make it this ambiguous. For a race car, you have acceleration. Does he want a higher top speed? Does he want better handling in corners? These are the pillars of performance for a race car. But there are also pillars of performance for web pages. And in my experience, these are the three main ones. Visibility, interactivity and responsiveness. Visibility meaning how long does it take to show something? Interactivity is how long does it take to be able to click on something? And responsiveness is how long does it take for it to respond to user input? I will briefly go over each of them. But before you start optimizing, I realize you want to get right under business. You want to start fixing stuff. You want to improve the performance. You have some ideas. Somebody asks you, can you improve the performance? Probably immediately ideas start bubbling up. And you want to get right down to business and fix stuff. But you really shouldn't. Before you start fixing performance, before you start optimizing, there's a couple of really important things that need to be taken care of. And first, you have to establish a baseline. You have to make the performance measurable. You have to make it repeatable. And you have to make it stable. Measurable meaning that the performance is expressible in some sort of number, usually time. Usually the time it takes to perform a certain operation or the time it takes for something to complete. Repeatable means that not only is it measurable, but measurements don't vary widely between tests. They can vary wildly between platforms or between browsers. That's okay. As long as one browser or one platform is stable, that's fine. But if it's not, if measurements vary wildly between tests, it means you don't have a performance problem, you have a bug. And you need to fix that first. Once they're repeatable, you need to make sure that they're stable. And with that, I mean you can safely make changes because you can be confident that your automated testing will pick up any bugs you introduce because you will be introducing bugs if you start fixing performance. Once you have established this baseline, once everything is ready to be optimized, you need to do measurements. You need to start recording data about what the current state of the application is. It's useless to take an application or take a web page when you receive this request. Start fixing stuff and then give it back to the one that complained about it. If you ask, does this feel better? The answer will always be no. It will always be yes, but while if you can come back to that person and say it used to be seven seconds, now it's five and a half, what do you think? At least you have something to fall back on. So first establish a baseline. Then always focus first on the low-hanging fruit. You don't want to climb a tree for a coconut if there's a banana right in front of you. Unless you really like coconuts or climbing. So then we get to the first pillar, visibility, going from a blank page to a styled web page. Something that looks good, something that the designer intended. And how long does that take and how can we optimize that time? How many of you have read this book by Steve Souters? Many? Still not enough. Required reading, really absolutely. I realize this is a cop-out but there's so much good stuff in here I can't possibly hope to cover that in a 30-minute presentation. I just want you all to read this and to use the information as much as you can. I do have some stuff to add, though. Even if you don't read the book, just install Firebug and Weisslow. Weisslow will tell you lots of things that are wrong with the way you're doing what you're doing. You don't have to feel bad about it. Most people don't do everything and you don't have to do everything. Again, focus on the low-hanging fruit. Do whatever Weisslow tells you if you can do it in a day. Don't worry too much about the rest because Weisslow is also very good in pointing out coconuts. And before you know it, you'll be climbing a tree. Another tip I would like to give you is to crowdsource your measurements with Google Analytics. How many people here are using Google Analytics to measure their sites? You can record visitor data like what kind of browser are they using, how long does it take for them to leave the site. What you can also do is record custom events. Now, brace yourself. Code is coming. Imagine this scenario. We just record a little date in a global variable called start. And then as soon as we call document ready, we push an event to Google Analytics saying the performance took this, or saying the DOM ready event took this much time. This will be done for every user that visits your site. Google Analytics will store this data and average it for you. So even if you have millions of visitors, at the end of the day, you will get one value saying it took this many milliseconds for the average user to reach the DOM ready. And this is incredibly useful information because even if you optimize the bytes, if you optimize the HTTP requests, even if you do everything Weisslow tells you, in the end it's all about the user experience. And this is a great way to tell what the actual experience is. Another tip is this is one I actually found recently, is you can have 8-bit PNGs with an alpha channel. So you don't need 24-bit PNGs to have nice-looking semi-transparent pixels. You can do 8-bit PNGs, of course losing some of the color data, but most of the time it still looks pretty good. So depending on how crazy your designer is, this can save hundreds of kilobytes. I recently saved about 200 kilobytes on the site using this. The second pillar is interactivity. Going from a visible page to one that is styled and fully clickable. This is mostly dependent on what scripts are loaded and what scripts are run immediately. So you know the situation where you load a page and even though everything is already there, you still can't click. There's still the spinning beach ball waiting for stuff to finish before it will actually expand the menu before you can click the form. It looks good, but it's a terrible user experience. For jQuery projects, much of this can be found in the on-ready handler. This is another cutout, another book by Steve Souders, even faster websites. It's a sequel, just as gripping as the first one. And actually he didn't write this by himself, all-star cast, people like... I forgot, actually. Never mind. Just some really famous developers. And some really good tips, helping you with improving that performance. So here's a tip for the document ready, and that is to profile it. Using Firebug, you can profile a certain part of your code without actually having to click the profile button. You can use the console API. So at the top, we have a ready function. Let's say we have two functions. We don't know exactly what they do, but they're taking a long time. We just put a console profile and a console profile end. Before and after that, you reload the page and you can see where that time is actually going. Another tip is delay initialization. So like I said, the time that it takes from a visible page to become interactive usually goes into loading scripts and initializing them. But you don't need to initialize everything. I recommend all of you go to Doug's presentation tomorrow on contextual jQuery, because this is one of his good points. Not that there are bad points in there. But this is really good stuff. Take for instance a form that you want to initialize, a contact form at the footer, and you don't need to initialize that for every user, right? Exactly. So what can you do? Instead of the top one where you immediately initialize, you take the bottom one, and actually the recent jQuery has a great event addition called dot one, where you can have an event handler fire exactly once and no more, which is great. The third pillar is responsiveness. So when the page is loaded, it's become interactive, and you actually interact with it. It can take quite a while sometimes for a user action to actually receive feedback, visual feedback. Again, I want you to read this book. These three books really, they're not huge books. They're high level stuff, but they're really required reading. So I just want to say that you really should read those. In my experience, this is actually the hardest one to get right. The first two are there's a lot of work in there, but it's not complex. But getting the responsiveness right, that's really complex material. And this is really hard to get right. It's really easy to introduce bugs. Fortunately, it's also the easiest to fake, but I will get into that later. There's one tip I would like to give you here, and that has to do with repeating events. Some events fire once in a while, like a click event or a mouse hover. Other events fire a lot, like key down events on an input. If you start typing in an input, you fire lots of key down events. Some events fire all the time, like a mouse move or a resize event when you resize the browser. The last two categories, the ones that fire a lot or the ones that fire all the time, they benefit a lot if you throttle them or debounce them. And Ben Alman wrote this great plug-in, which I pretty much use for every project that I start these days, that makes it super easy to throttle and debounce. Throttle means that instead of having a constant event firing, it will fire only once every couple of milliseconds. Debounce means that instead of having a sequence of events being fired, you fire it once either at the beginning or at the end. So take, for instance, a handler on an input that handles the key down event. Let's say some handler is actually pretty complex. Maybe it even does an Ajax call or something because you're doing an autocomplete. The top one could fire a lot of Ajax calls if you start typing really quickly. Using debounce, you can make sure that all key down events are actually taken together and only when a user is not typing for 500 milliseconds in this case will it fire some handler, making sure you don't fire too many of those Ajax requests. Throttle works similarly, like I said, but instead of only firing it once at the end or at the beginning, you can fire it a couple of times, but no more than in this case once every 500 milliseconds. So like I said, responsiveness is the easiest one to fake because even though an operation can take a long time, as long as you give the user immediate feedback that something is happening, they're usually okay with it. But it's better to have something take two seconds and have some sort of progress animation than to have something take one second and have no visual feedback at all in the meantime. And visual feedback is really easy. You just have to show something before you do it and hide it when you're done. Spinners, progress bars, animations, anything to show that something is happening and users will be pretty happy about it. So those are all pillars of performance and they're all different aspects of a web page performance, but there's one thing that really binds them all together, and that is that they're all from a user perspective. And that's fine, but there are other perspectives as well. There's a business perspective to performance as well. There could be money involved. Actually, performance optimizations are pretty expensive. They take a lot of time. It's a time-consuming iterative process. There's lots of trial and error involved. There's lots of testing and comparing and measuring. There's a lot to lose. And what is there to gain? Some user happiness. There are other ways to get user happiness. You can introduce new features. You can fix bugs. You can make old features better. Performance optimizations are relatively invisible. So a user will notice if a performance is bad, but if you improve it, it doesn't mean he will notice that the performance is better. Introducing other features is a much more visible way to making your application better. It's really jittery, right? I was looking in that direction, but it's kind of funky. Not only are they expensive, performance optimizations can actually increase costs. I've seen performance improvements that took one man two days to write and then had an entire team chase bugs for weeks. Unit tests will only catch so much. And maintainability can also be easily compromised without too far with optimizations. Trying to optimize CSS selectors, trying to optimize jQuery selectors, we've all tried to do it. And how much is there really to gain by doing that? Not much, but there's a lot to lose. Using the wrong selectors, even though they're optimized, even though they're a little bit faster, can mean it will take a colleague of yours a couple of hours more later to introduce a new feature. And that adds up. Now, I realize this may all sound a little bit blasphemous. I mean, I did just recommend books by a couple of really famous guys that worked for Yahoo and Google. I did. And I still stand by those recommendations. I think everybody in this room should really read those books. But there's this feeling that I have. I mean, these are the cream of the crop developers for really big organizations. They're working on projects where every millisecond and every kilobyte is multiplied by millions and millions of users. So it's no wonder they really care about these tiny details. But when I look at the job that I'm doing, I feel more like this guy. So I built websites. I'm proud of what I make. But I'm happy with a thousand users in a month. Do I really need to hold myself to the same standards as these guys do? It doesn't mean I can't learn from them, but it does mean that I need to weigh the costs and benefits of their recommendations. And a race car's goal is not just to drive fast. A race car's goal is to win races. And our websites, the stuff that we build, our projects, they have goals. Sometimes it is to provide information. Sometimes it is to make the user perform a task. Sometimes the goal isn't even clear until well after the site has been finished and released. But the performance of a website needs to be measured in how well it achieves these goals, not in how fast it loads. And in the end, it's all about our performance. It's all about how well we are doing our jobs. And are we building the websites that the world needs? Or are we just making them faster? Thank you.