#fronteers14

Dave Olsen - Optimizing web performance

Fronteers 2014 | Amsterdam, October 10, 2014

Today, a web page can be delivered to desktop computers, televisions, or handheld devices like tablets or phones. While a technique like responsive design helps ensure that our web sites look good across that spectrum of devices we may forget that we need to make sure that our web sites also perform well across that same spectrum. More and more of our users are shifting their Internet usage to these more varied platforms and connection speeds with some moving entirely to mobile Internet.

In this session we’ll look at the tools that can help you understand, measure and improve the web performance of your web sites and applications. The talk will also discuss how new server-side techniques might help us optimize our front-end performance. Finally, since the best way to test is to have devices in your hand, we’ll discuss some tips for getting your hands on them cheaply.

Slides

Transcript

00:01.425 --> 00:03.010 Big warm welcome to Dave Olsen! 00:08.300 --> 00:09.880 Thank you very much, Jake. 00:09.880 --> 00:12.310 Thank you very much to the fronteers folks for inviting me 00:12.310 --> 00:16.125 here today to talk to you guys about performance. 00:16.125 --> 00:18.250 Give you guys a little bit of an idea of what we're 00:18.250 --> 00:20.833 going to talk about, what kind of a road map, a very ambitious 00:20.833 --> 00:22.044 road map for today's talk. 00:22.044 --> 00:24.210 We're going to talk a little bit about why we should 00:24.210 --> 00:25.350 care about web performance. 00:25.350 --> 00:27.558 I think it just-- it really should just be a default, 00:27.558 --> 00:30.216 but hopefully will give you some things you can take back 00:30.216 --> 00:32.549 to your team, or to your management, to kind of explain, 00:32.549 --> 00:34.715 this is why we have to put this during the process-- 00:34.715 --> 00:36.530 or the front of the process. 00:36.530 --> 00:38.160 We're going to talk about how we can 00:38.160 --> 00:42.320 diagnose performance problems, some easy tools to do that. 00:42.320 --> 00:44.190 Some easy web performance optimization 00:44.190 --> 00:47.630 wins, again, that you can get during your process 00:47.630 --> 00:49.160 to make your life a little-- a lot 00:49.160 --> 00:52.490 easier so you don't have to think about it as much. 00:52.490 --> 00:55.210 Some other tools to help test and automate perf 00:55.210 --> 00:56.410 optimizations. 00:56.410 --> 01:01.850 And, finally, because the only real way to test performance, 01:01.850 --> 01:04.050 especially mobile performances on a real device, 01:04.050 --> 01:06.810 is how you can set up a device lab yourself. 01:06.810 --> 01:10.560 Or even better, because you guys are very lucky in Europe, 01:10.560 --> 01:15.040 you have lots of device labs around to go find devices. 01:15.040 --> 01:17.060 So why should we care about web performance? 01:17.060 --> 01:21.000 Why should we care, like the care bears? 01:21.000 --> 01:22.620 The fact of the matter is-- well, 01:22.620 --> 01:26.150 Ethan Marcote laid out three simple rules regarding 01:26.150 --> 01:27.204 responsive web design. 01:27.204 --> 01:28.620 And putting them together you have 01:28.620 --> 01:33.930 flexible grids, flexible images, flexible media, and media 01:33.930 --> 01:34.600 queries. 01:34.600 --> 01:38.270 And together they give you flexible layouts. 01:38.270 --> 01:40.680 And flexible layouts are fantastic. 01:40.680 --> 01:43.960 They allow us to make one design that, essentially, 01:43.960 --> 01:46.400 can be looked and seen everywhere, 01:46.400 --> 01:49.940 and kind of can shift-- you know that old analogy of water 01:49.940 --> 01:53.110 moving between glass containers-- this one layout, 01:53.110 --> 01:54.840 it goes everywhere. 01:54.840 --> 01:56.340 But the problem is this-- shifting 01:56.340 --> 02:00.739 this layout is only one part of doing web development. 02:00.739 --> 02:02.405 And Jason Grigsby does a really good job 02:02.405 --> 02:04.830 of summing it all up, where he says, 02:04.830 --> 02:06.510 "The way in which CSS media queries 02:06.510 --> 02:08.600 have been promoted for mobile hides tough problems 02:08.600 --> 02:10.449 and gives developers a false promise 02:10.449 --> 02:13.370 of a simple solution for designing for small screens." 02:13.370 --> 02:16.290 Simply changing a layout is not enough 02:16.290 --> 02:17.840 when designing for a small screen. 02:17.840 --> 02:21.550 There's so much more we have to be thinking about 02:21.550 --> 02:24.904 and this is just a tiny, tiny little part of that. 02:24.904 --> 02:27.070 We're gonna be thinking about platform optimization. 02:27.070 --> 02:29.880 If we're designing one layout that we're shifting everywhere, 02:29.880 --> 02:31.650 and we have to deal with IE8 users-- 02:31.650 --> 02:34.240 I'm in higher education in the States, 02:34.240 --> 02:36.120 and we still have a lot of legacy 02:36.120 --> 02:39.080 that we have to deal with, plus-- before we're looking. 02:39.080 --> 02:40.860 So platform optimization. 02:40.860 --> 02:43.350 Content strategy, content choreography. 02:43.350 --> 02:45.530 How do we make sure our content is coming out 02:45.530 --> 02:49.300 in the right order, based on different devices? 02:49.300 --> 02:52.270 Ads, making sure those are going the correct places. 02:52.270 --> 02:55.389 So it's not just a simple matter of just squishing things. 02:55.389 --> 02:57.680 It's a matter of figuring out where those things should 02:57.680 --> 03:00.230 go when they've been squished. 03:00.230 --> 03:02.679 And finally, I think for me what the talk is going 03:02.679 --> 03:05.220 to be about-- one thing that we tend not to think about a lot 03:05.220 --> 03:06.480 is performance. 03:06.480 --> 03:09.920 And that's because we tend to develop and do 03:09.920 --> 03:11.720 testing, all at our desktops. 03:11.720 --> 03:14.150 And we go like, yeah, this stuff's really, really fast, 03:14.150 --> 03:15.620 and this is awesome. 03:15.620 --> 03:18.450 Instead we need to be thinking about, kind of, what 03:18.450 --> 03:19.850 our current dev practices are. 03:19.850 --> 03:22.220 And they've led to-- to this. 03:22.220 --> 03:26.280 Absolutely massive bloat for our web pages. 03:26.280 --> 03:27.490 This is HTTP archive. 03:27.490 --> 03:31.040 This is for last month's result. So web pages, 03:31.040 --> 03:35.310 home pages for their 200,000 some odd places that they 03:35.310 --> 03:40.990 index, is at 1.8 megs-- the average home page today. 03:40.990 --> 03:45.310 That's two floppy disks now, to bring somebody any content. 03:45.310 --> 03:47.820 I just-- absolutely blows my mind. 03:47.820 --> 03:49.720 Maybe I'm dating myself by knowing 03:49.720 --> 03:52.460 how big a floppy disk is, but-- 03:52.460 --> 03:55.100 And the massive portion of this is 03:55.100 --> 03:57.049 images and JavaScript-- JavaScript 03:57.049 --> 03:58.340 to a lesser degree, but images. 03:58.340 --> 04:00.740 We have to have this big glossy hero image. 04:00.740 --> 04:01.990 We have to have this carousel. 04:01.990 --> 04:05.680 And we have to have this amazing, just, visual 04:05.680 --> 04:06.750 experience. 04:06.750 --> 04:08.690 And it works fantastic on a desktop. 04:08.690 --> 04:10.500 And it works really great in a static comp 04:10.500 --> 04:12.510 when you're talking to a client. 04:12.510 --> 04:15.380 It makes a huge difference when we start talking about, 04:15.380 --> 04:19.680 this layout's gonna go literally everywhere, to every device, 04:19.680 --> 04:21.260 over every network. 04:21.260 --> 04:24.520 And we have to be thinking a lot more cognizant about that. 04:24.520 --> 04:27.960 And just using responsive design is not a cure-all. 04:27.960 --> 04:32.810 And a kind of proof that these current dev practices are still 04:32.810 --> 04:36.970 failing in responsive design, Guy-- hopefully I'm not 04:36.970 --> 04:39.970 completely butchering his name-- Guy Podjarny did 04:39.970 --> 04:44.340 this study in 2013 where he found almost 3/4 04:44.340 --> 04:47.300 of the websites who had responsive web 04:47.300 --> 04:49.520 design, small screen design, weighed the same 04:49.520 --> 04:50.570 as a large screen design. 04:50.570 --> 04:52.890 There was absolutely no thought put into-- 04:52.890 --> 04:54.490 or probably very minimal thought put 04:54.490 --> 04:57.942 into how these things are different, 04:57.942 --> 04:59.900 and how we're delivering to a different network 04:59.900 --> 05:02.000 and having, honestly, a different use case. 05:02.000 --> 05:04.020 But definitely delivering to a different network 05:04.020 --> 05:06.100 and how that might affect the web pages 05:06.100 --> 05:08.820 that we're trying to do. 05:08.820 --> 05:10.640 And why we need to be thinking about this 05:10.640 --> 05:14.624 is because our users think the web, is the web, is the web. 05:14.624 --> 05:16.540 But the same experience, and the same content, 05:16.540 --> 05:18.880 and the same everything that they get on desktop, 05:18.880 --> 05:20.110 they want it on mobile. 05:20.110 --> 05:23.240 And they don't care that they're on a shitty network. 05:23.240 --> 05:24.890 It doesn't even come into their mind. 05:24.890 --> 05:26.473 They're just like, OK, it's a website. 05:26.473 --> 05:29.310 I'm going to access this website. 05:29.310 --> 05:31.430 And they expect it to load the same, 05:31.430 --> 05:33.444 regardless of where they are. 05:33.444 --> 05:35.360 And so everything we have to be thinking about 05:35.360 --> 05:38.400 is, how do we make it load fast everywhere? 05:38.400 --> 05:40.325 And not just, again, keep doing this, 05:40.325 --> 05:41.700 it worked well enough on desktop, 05:41.700 --> 05:43.990 it probably will work OK on mobile. 05:43.990 --> 05:45.930 How do we figure it out? 05:45.930 --> 05:49.310 And the 5.4 seconds actually isn't a-- it's actually 05:49.310 --> 05:50.060 kind of important. 05:50.060 --> 05:53.020 A website should load in less than five seconds, again, 05:53.020 --> 05:56.610 regardless of platform-- which is kind of incredible-- or else 05:56.610 --> 05:57.470 they leave. 05:57.470 --> 06:01.000 And for us who are trying to generate revenue, 06:01.000 --> 06:05.390 that's kind of a really important number for us to hit. 06:05.390 --> 06:07.990 And kind of a good case study comes from Strange Loop. 06:07.990 --> 06:10.270 They did this a couple years ago, 06:10.270 --> 06:13.920 where they worked with a client where they actually slowed down 06:13.920 --> 06:14.440 requests. 06:14.440 --> 06:16.310 So they held on to requests for a little bit 06:16.310 --> 06:17.518 longer before sending it off. 06:17.518 --> 06:19.676 And they did this little study where they held on 06:19.676 --> 06:21.050 to requests for 200 milliseconds, 06:21.050 --> 06:24.520 held on to requests for 500 milliseconds, and then 1,000, 06:24.520 --> 06:25.690 for a second. 06:25.690 --> 06:27.380 And see what kind of effect they had 06:27.380 --> 06:29.900 on-- on revenue, how much they could 06:29.900 --> 06:32.140 revenue, what the balance rate was. 06:32.140 --> 06:35.780 And it had massive implications. 06:35.780 --> 06:38.480 A simple one second delay-- I mean, one second, 06:38.480 --> 06:43.280 that's like nothing-- had almost a 4% drop in conversions-- 06:43.280 --> 06:46.310 4% drop in purchases. 06:46.310 --> 06:47.980 They lost almost 10% in page views. 06:47.980 --> 06:49.000 People weren't even seeing it. 06:49.000 --> 06:50.916 They just gave up and went away, wouldn't even 06:50.916 --> 06:52.490 record the page view. 06:52.490 --> 06:55.760 And that's simply a one second drop in a page. 06:55.760 --> 06:57.260 If we're talking on mobile networks, 06:57.260 --> 06:59.710 we can be talking two, three, four second drops in pages 06:59.710 --> 07:02.260 if we're not optimizing properly. 07:02.260 --> 07:05.150 So you're losing that much more. 07:05.150 --> 07:07.440 So if we decide that we're going to go mobile first-- 07:07.440 --> 07:09.565 if we're gonna design our layouts for mobile first, 07:09.565 --> 07:12.366 we're gonna start with that small screen and work out-- we 07:12.366 --> 07:14.740 also have to keep thinking that's also performance first. 07:14.740 --> 07:19.030 And I'm not trying to coin a phrase, or coin a design-- 07:19.030 --> 07:20.210 anything. 07:20.210 --> 07:22.345 But, really, if you're going to go mobile first, 07:22.345 --> 07:24.095 you have to be starting and thinking right 07:24.095 --> 07:25.850 at the get-go about what performance 07:25.850 --> 07:28.719 means for the website as well. 07:28.719 --> 07:30.510 So what are some of the primary performance 07:30.510 --> 07:33.820 issues for responsive design? 07:33.820 --> 07:35.780 And I'm breaking these down into two buckets. 07:35.780 --> 07:38.070 The first bucket is something that we can control, 07:38.070 --> 07:40.090 as designers and developers. 07:40.090 --> 07:42.654 And the second bucket is just the stuff 07:42.654 --> 07:44.070 you have to kind of realize you're 07:44.070 --> 07:45.695 going to be dealing with, and there you 07:45.695 --> 07:47.360 have nothing you can do about. 07:47.360 --> 07:52.700 So try as much as you can to deal with the first bucket. 07:52.700 --> 07:57.140 So a lot of things that happen is Download and Hide. 07:57.140 --> 07:59.570 The easy trick in responsive design 07:59.570 --> 08:01.180 seems to be use Display None. 08:01.180 --> 08:04.335 I'm just gonna take this CSS, and I'm going to-- 08:04.335 --> 08:07.270 or I take this div, I'm gonna hide it. 08:07.270 --> 08:08.880 The reality is a browser is still 08:08.880 --> 08:12.159 going to try to parse and download whatever is in there. 08:12.159 --> 08:14.450 So if you have an image and you did Display None on it, 08:14.450 --> 08:16.033 the browser still went and fetched it, 08:16.033 --> 08:17.370 just no one got to see it. 08:17.370 --> 08:21.290 So you're taking that chance to-- so you're just 08:21.290 --> 08:23.570 forcing someone to take an action which 08:23.570 --> 08:25.110 they didn't need to do. 08:25.110 --> 08:26.530 Download and Shrink. 08:26.530 --> 08:28.900 Again we have this big, massive hero image. 08:28.900 --> 08:32.159 And I set height and width to 100% and 100%. 08:32.159 --> 08:34.820 Oh, fantastic, everything just kind of moves. 08:34.820 --> 08:37.480 You sent a ton of extra bytes to someone 08:37.480 --> 08:40.409 when they don't actually get to take advantage of all that-- 08:40.409 --> 08:43.159 of what they can see because it's so much smaller now. 08:43.159 --> 08:45.160 So you're trying to think about-- now especially 08:45.160 --> 08:47.285 with responsive images, has finally sort of arrived 08:47.285 --> 08:49.330 with a source set in the picture element, 08:49.330 --> 08:51.940 that we can actually properly size images to what 08:51.940 --> 08:54.235 the final output's going to be. 08:54.235 --> 08:56.360 And then something that happens a lot, I think more 08:56.360 --> 08:58.693 with JavaScript than anything else, which is downloading 08:58.693 --> 09:01.040 and ignore. So we have a certain feature that we're 09:01.040 --> 09:02.900 going to use on the desktop. 09:02.900 --> 09:04.460 And it didn't quite fit, or we don't 09:04.460 --> 09:07.697 want to quite do the UI at a mobile size. 09:07.697 --> 09:10.030 But we still had the user download the JavaScript anyway 09:10.030 --> 09:11.779 because we just have one layout that we're 09:11.779 --> 09:12.822 sending to everybody. 09:12.822 --> 09:14.530 So the browser's A, downloaded JavaScript 09:14.530 --> 09:16.740 it doesn't really need, and B, it's now 09:16.740 --> 09:18.180 parsed that JavaScript to make it 09:18.180 --> 09:20.917 available to you, which again you're never going to need. 09:20.917 --> 09:22.750 So you burn battery, and you burn bandwidth, 09:22.750 --> 09:26.690 and you made the website slower for-- for no reason. 09:26.690 --> 09:29.270 So that's sort of the things that we can control. 09:29.270 --> 09:32.270 Kind of, ideas of things that we want to address. 09:32.270 --> 09:35.730 On the poor network side, high latency. 09:35.730 --> 09:39.005 If you're on a cable modem, and you're 09:39.005 --> 09:40.810 at your desk doing design, you're 09:40.810 --> 09:43.530 probably seeing like a 20 millisecond latency, 09:43.530 --> 09:46.750 in terms of getting a request, or whatever. 09:46.750 --> 09:49.820 And it's an order of magnitude more on a network. 09:49.820 --> 09:51.490 So, basically, what latency is, is 09:51.490 --> 09:54.926 the-- when a user requests an asset-- 09:54.926 --> 09:56.550 it's the time from when a user requests 09:56.550 --> 09:59.510 an asset, to when the asset comes back to the user. 09:59.510 --> 10:02.140 So on a desktop, it's 20 milliseconds ago. 10:02.140 --> 10:04.475 Hey, I want that image, and it comes back. 10:04.475 --> 10:06.600 And on a mobile network, it's 200 milliseconds. 10:06.600 --> 10:08.150 I want that image, and it comes back. 10:08.150 --> 10:09.691 And something you can't beat, there's 10:09.691 --> 10:11.662 nothing-- no way to get around it. 10:11.662 --> 10:13.870 And so when you start adding up that 200 milliseconds 10:13.870 --> 10:17.320 over every request that you're trying to make, 10:17.320 --> 10:19.730 it adds up massively fast. 10:19.730 --> 10:22.930 When we're talking about one second in terms of, 10:22.930 --> 10:26.220 that was a 10% drop in page views, 10:26.220 --> 10:28.570 you know, five images at 200 milliseconds, that's 10:28.570 --> 10:30.370 a second right there that you've lost, 10:30.370 --> 10:32.650 that you have zero control over. 10:32.650 --> 10:37.620 So try to think about how you can avoid latency. 10:37.620 --> 10:41.390 We have variable bandwidth, and we have packet loss, 10:41.390 --> 10:43.710 to a lesser degree. 10:43.710 --> 10:45.730 So again, trying to think about things 10:45.730 --> 10:47.660 you can't, absolutely can't overcome, 10:47.660 --> 10:50.600 and trying to avoid them as much as you can. 10:50.600 --> 10:52.600 So reviewing why we should care. 10:52.600 --> 10:54.270 We have a set of current dev practices 10:54.270 --> 10:57.580 that sort of encourages bloat, that sort of encourages 10:57.580 --> 11:02.330 this big, glossy web fonts-- big design. 11:02.330 --> 11:05.505 And we test on a desktop, and we look at it on a desktop, 11:05.505 --> 11:07.630 and we tend to review with the client on a desktop. 11:07.630 --> 11:11.260 And we sort of say, hey, by the way, it does work on mobile. 11:11.260 --> 11:13.950 And I've sort of, maybe haven't started mobile first design, 11:13.950 --> 11:16.390 but at the end the day we've tested and everything 11:16.390 --> 11:19.190 on a desktop machine. 11:19.190 --> 11:21.500 And so we didn't get kind of a true idea 11:21.500 --> 11:23.180 of what the performance was, and where 11:23.180 --> 11:25.638 we're going to hit bottlenecks, and how that might actually 11:25.638 --> 11:27.050 affect someone. 11:27.050 --> 11:29.090 And these two things coupled together 11:29.090 --> 11:31.265 lead to the web performance blues. 11:31.265 --> 11:34.300 And that makes LEGO man very, very sad. 11:34.300 --> 11:37.215 And I didn't quite realize how big he would be. 11:37.215 --> 11:37.965 He's gonna eat me. 11:40.790 --> 11:45.460 So how do we go about diagnosing web performance issues? 11:45.460 --> 11:47.000 How can we start figuring out what 11:47.000 --> 11:48.270 problems we have currently? 11:48.270 --> 11:50.624 What tools can we use to do that? 11:50.624 --> 11:52.040 And I've sort of broken this down, 11:52.040 --> 11:57.430 kind of via iTunes essentials sort of schema. 11:57.430 --> 11:59.510 So where are the basics? 11:59.510 --> 12:02.260 So the very basic tool-- most basic 12:02.260 --> 12:05.470 tool you can use to get a really good idea of how your page is 12:05.470 --> 12:08.386 performing, or what things you can improve of an existing 12:08.386 --> 12:09.760 website if you want to kind of go 12:09.760 --> 12:14.240 retrofit an existing solution and see what your problems are. 12:14.240 --> 12:16.830 PageSpeed Insights, from Google, is-- 12:16.830 --> 12:19.090 should be your number one stop. 12:19.090 --> 12:20.090 It does a fantastic job. 12:20.090 --> 12:22.880 You pop in your URL, give it a minute, 12:22.880 --> 12:25.590 and it'll give you two separate reports. 12:25.590 --> 12:26.490 One, based on mobile. 12:26.490 --> 12:28.490 It'll give you tips and tricks that you should-- 12:28.490 --> 12:29.948 things you should be thinking about 12:29.948 --> 12:32.360 for mobile, both from a performance 12:32.360 --> 12:35.600 perspective and a user interaction perspective, which 12:35.600 --> 12:37.610 is really massive. 12:37.610 --> 12:40.200 And then the flip side, it'll also give you desktop. 12:40.200 --> 12:43.192 But obviously, you know, the really useful tool, 12:43.192 --> 12:44.900 and the thing I think you should actually 12:44.900 --> 12:47.025 be focused on more-- they should probably just make 12:47.025 --> 12:52.350 everything the mobile set of rules-- is focusing on that. 12:52.350 --> 12:55.700 And then it links off to all the great documentation 12:55.700 --> 12:58.190 that is in the Google Developer website. 13:00.730 --> 13:03.360 So that's the basic-- most basic thing you can do. 13:03.360 --> 13:06.090 The next step that you can do as you actually develop 13:06.090 --> 13:09.200 your websites, to try to think about how performance 13:09.200 --> 13:13.400 is working, is use the Chrome Developer Tools. 13:13.400 --> 13:15.320 It's much more than Elements View. 13:15.320 --> 13:16.360 It's much more than just being able to, 13:16.360 --> 13:17.990 hey, I can change the style on the fly, 13:17.990 --> 13:20.050 I can look at a source map. 13:20.050 --> 13:23.470 That's all well and good, but there's also the Network panel, 13:23.470 --> 13:26.140 there's a Timeline panel. 13:26.140 --> 13:29.450 You can actually get your page speed audit here too, as well, 13:29.450 --> 13:32.820 and try to figure out what's going on. 13:32.820 --> 13:34.690 And I'm not going to cover it too much, 13:34.690 --> 13:37.790 but there is actually a Chrome DevTools course completely 13:37.790 --> 13:39.130 focused on web performance. 13:39.130 --> 13:42.390 And it's taught by Ilya Grigorik, who is basically 13:42.390 --> 13:44.620 the man when it comes to web performance, 13:44.620 --> 13:46.690 including Steve Souders too, but-- he 13:46.690 --> 13:48.030 did a fantastic course. 13:48.030 --> 13:49.540 It's free, actually, as long as you 13:49.540 --> 13:51.123 don't care about getting a certificate 13:51.123 --> 13:53.940 or anything from Udacity, you can get the free course. 13:53.940 --> 13:57.910 It's supposed to take six hours or so, I guess. 13:57.910 --> 14:00.310 And you can look through it and learn from the man 14:00.310 --> 14:03.240 about how you can actually use Chrome DevTools, 14:03.240 --> 14:10.280 beyond just using it for styles and managing markup. 14:10.280 --> 14:12.160 And the Deep Cuts. 14:12.160 --> 14:17.770 The absolute best tool, I think, and really worth your time 14:17.770 --> 14:20.820 to learn and go through and figure out 14:20.820 --> 14:21.800 how to actually use it. 14:21.800 --> 14:23.340 And as I go through the rest of this talk, 14:23.340 --> 14:24.923 actually, I'm going to be highlighting 14:24.923 --> 14:27.174 features of WebPagetest. 14:27.174 --> 14:28.590 WebPagetest is essentially created 14:28.590 --> 14:32.029 by performance developers, for performance developers 14:32.029 --> 14:33.195 with a lot of love and care. 14:33.195 --> 14:36.430 The interface isn't always the best, 14:36.430 --> 14:38.680 it's a little ugly and clunky, but it 14:38.680 --> 14:41.080 has some absolutely amazing tools 14:41.080 --> 14:43.050 that'll give you great insight into what's 14:43.050 --> 14:45.390 going on with your web pages. 14:45.390 --> 14:47.920 So in the same way that you can go 14:47.920 --> 14:52.820 to PageSpeed Insights and type in your URL, 14:52.820 --> 14:55.950 you can do the same thing with WebPagetest 14:55.950 --> 14:57.420 and get a really basic report. 14:57.420 --> 15:00.410 So this is a basic report for my home page. 15:00.410 --> 15:02.145 And I was very embarrassed with the F, 15:02.145 --> 15:03.645 but I figure I would leave it there. 15:03.645 --> 15:07.157 I have to go change an Apache configuration somewhere. 15:07.157 --> 15:09.490 But it gives you a quick little grade, so a quick visual 15:09.490 --> 15:10.970 about what's going on. 15:10.970 --> 15:12.970 And it gives you, again, more links back to tips 15:12.970 --> 15:16.870 about how you can make sure your website is performing-- 15:16.870 --> 15:20.310 performing better and how you can do stuff. 15:20.310 --> 15:23.770 So a bunch of the features of WebPagetest, 15:23.770 --> 15:26.390 which is what makes it so amazing, 15:26.390 --> 15:27.900 is that you can test real browsers 15:27.900 --> 15:29.812 from multiple locations. 15:29.812 --> 15:31.770 So you can see, how's my web performance in IE? 15:31.770 --> 15:33.830 How's my web performance in Android browser? 15:33.830 --> 15:35.580 How is my web-- without having to actually 15:35.580 --> 15:37.610 have all that stuff on hand. 15:37.610 --> 15:41.770 This is actually-- they're hooked up to these real devices 15:41.770 --> 15:44.620 with real browsers and testing everything. 15:44.620 --> 15:48.610 And latency is also a factor of just pure distance, 15:48.610 --> 15:51.560 the speed of light is an issue of latency. 15:51.560 --> 15:53.960 So you can see how's your website perform from, say, 15:53.960 --> 15:56.043 South Africa if you're trying to request something 15:56.043 --> 15:58.440 from California. 15:58.440 --> 16:01.790 And to give you an idea of, maybe you want to put a CDN in. 16:01.790 --> 16:03.530 So if you see you have a lot of traffic 16:03.530 --> 16:06.940 from a particular location, you can actually test it 16:06.940 --> 16:08.670 and see how people are doing. 16:08.670 --> 16:11.770 You can modify connection speed so you can essentially 16:11.770 --> 16:13.320 shape traffic and figure out, hey, 16:13.320 --> 16:16.020 on a 3G network this is probably what it's going to be like, 16:16.020 --> 16:17.910 or this is what it's going to be looking 16:17.910 --> 16:20.770 like on a cable, or DSL. 16:20.770 --> 16:22.720 I know for me, in West Virginia, I actually 16:22.720 --> 16:25.830 have less than a meg DSL. 16:25.830 --> 16:28.730 And so it's kind of good to see how things might affect me. 16:28.730 --> 16:32.450 Trying to go to certain websites is a challenge at times. 16:32.450 --> 16:36.550 My cell connection's faster than my home connection. 16:36.550 --> 16:38.230 It does video capture. 16:38.230 --> 16:39.560 You can do content blocking. 16:39.560 --> 16:42.700 You can get really, really nerdy and script the session, 16:42.700 --> 16:44.010 and do all sorts of fun things. 16:44.010 --> 16:47.370 And I'll show you an example of one of those later on. 16:47.370 --> 16:50.680 You can actually add WebPagetest to any kind 16:50.680 --> 16:53.370 of continuous integration platform that you have. 16:53.370 --> 16:57.990 So if you're running Travis 16:57.990 --> 17:02.360 can run WebPagetest and get a performance audit as part 17:02.360 --> 17:04.077 of your continuous integration. 17:04.077 --> 17:05.910 So you don't have to think about it as much. 17:05.910 --> 17:07.619 You can just be like, hey, ran the test 17:07.619 --> 17:09.119 and it came back-- oh, wait, maybe I 17:09.119 --> 17:10.490 should go fix something. 17:10.490 --> 17:12.439 So it becomes more a part of your process. 17:12.439 --> 17:14.980 And I think that's the beautiful thing about web performance, 17:14.980 --> 17:17.540 is trying to figure out, not just tacking it on the end, 17:17.540 --> 17:19.630 but how can we integrate performance 17:19.630 --> 17:21.532 into every part of what we do. 17:21.532 --> 17:23.116 And so WebPagetest allows you to do it 17:23.116 --> 17:24.930 with continuous integration. 17:24.930 --> 17:26.480 You can also collect tests over time, 17:26.480 --> 17:28.855 and kind of record them and see how your performance gets 17:28.855 --> 17:31.980 better, or doesn't do as well. 17:31.980 --> 17:35.440 And, finally, it's free so you can go ahead and use it. 17:35.440 --> 17:38.630 About the only problem is, at times, it can be a little busy, 17:38.630 --> 17:41.240 and you have to kind of wait in a queue for the test to run. 17:41.240 --> 17:44.920 But, still, it's a fantastic way of learning more about how 17:44.920 --> 17:47.220 your website performance is. 17:47.220 --> 17:50.870 So to review some diagnostic tools, fast and easy, 17:50.870 --> 17:55.410 thing to go back tonight and play with, PageSpeed Insights. 17:55.410 --> 17:57.810 If you're going to do local development, Chrome DevTools. 17:57.810 --> 18:00.300 And I would highly encourage you to take the time-- 18:00.300 --> 18:05.242 to take a day to do that course on Udacity from Ilya. 18:05.242 --> 18:06.950 And if you want customization, and if you 18:06.950 --> 18:11.430 want integration with your process completely, 18:11.430 --> 18:16.360 and massive amounts of data to mass amounts of results, 18:16.360 --> 18:18.870 go with WebPagetest. 18:18.870 --> 18:22.620 So what are some easy web optimization wins? 18:22.620 --> 18:25.812 What are some things that you could do during your process 18:25.812 --> 18:29.510 to actually improve the performance of your website, 18:29.510 --> 18:31.950 without having to think so much? 18:31.950 --> 18:33.750 The very first thing I would recommend 18:33.750 --> 18:37.170 is a web performance budget. 18:37.170 --> 18:39.810 So a budget is a guide that you would-- in the same way 18:39.810 --> 18:41.940 that you would do a creative brief with a client 18:41.940 --> 18:45.160 at the very beginning of a project, you and your team-- 18:45.160 --> 18:47.430 or, even better, with the client, 18:47.430 --> 18:49.912 decide what your performance numbers. 18:49.912 --> 18:52.120 What metrics should you reach, from a web performance 18:52.120 --> 18:54.770 perspective, by the end of the project. 18:54.770 --> 18:56.550 You could do something as simple as, we 18:56.550 --> 18:59.080 want to keep it under a certain number of kilobytes. 18:59.080 --> 19:01.380 So for my own personal website I've 19:01.380 --> 19:03.940 set a performance budget of 50k. 19:03.940 --> 19:07.250 And that sort of defined for me, as I made decisions, 19:07.250 --> 19:09.114 how does that fit within this budget 19:09.114 --> 19:10.530 that I kind of gave myself, things 19:10.530 --> 19:11.770 that I want to think about. 19:11.770 --> 19:16.480 And it's not a hard and fast limit, it should be a guide. 19:16.480 --> 19:18.010 I really wanted web fonts. 19:18.010 --> 19:20.710 I thought, hey, my web page looks better with web fonts, 19:20.710 --> 19:22.460 they're kind of sexy. 19:22.460 --> 19:26.500 And that broke my budget, web fonts will tend to do that, 19:26.500 --> 19:28.750 so now my web page is a little under 100k. 19:28.750 --> 19:33.680 So it's not horrible but I made a compromise. 19:33.680 --> 19:35.280 And that's a lot of performance. 19:35.280 --> 19:37.870 Performance tweaks are about compromises. 19:37.870 --> 19:41.654 They're about figuring out what's gonna work best for you 19:41.654 --> 19:42.320 and your client. 19:42.320 --> 19:45.380 You can't just do everything and hope it's going to work. 19:45.380 --> 19:48.520 So performance budget works really well. 19:48.520 --> 19:52.350 If you take anything away from this talk beyond, like, 19:52.350 --> 19:55.630 PageSpeed Insights, create a performance budget 19:55.630 --> 19:57.985 to work with folks. 19:57.985 --> 19:59.860 And another good way of actually figuring out 19:59.860 --> 20:01.318 what a performance budget would be, 20:01.318 --> 20:04.050 especially with a client and somebody who makes money, 20:04.050 --> 20:05.560 is to look at their competitors. 20:05.560 --> 20:10.030 Figure out what their PageSpeed score is, or whatever. 20:10.030 --> 20:11.920 You get that from PageSpeed Insights. 20:11.920 --> 20:15.750 And then figure-- say our threshold for our performance 20:15.750 --> 20:19.630 budget is 25% less than that PageSpeed score, 20:19.630 --> 20:21.810 so we know our website's gonna perform better 20:21.810 --> 20:25.436 than your competitors. 20:25.436 --> 20:27.310 And that way you're going to make more money, 20:27.310 --> 20:28.580 and everyone's gonna be a lot happier. 20:28.580 --> 20:30.830 So that's a way of also doing a performance budget, 20:30.830 --> 20:33.610 is figure out who your-- who the competitors are, figure out 20:33.610 --> 20:35.490 what their baseline is, and do something 20:35.490 --> 20:39.007 like 25% lower than that them. 20:39.007 --> 20:40.840 So the three things to keep in mind, as kind 20:40.840 --> 20:43.510 of tenets-- things that you should 20:43.510 --> 20:45.720 have in the back of your head as you make 20:45.720 --> 20:47.460 tweaks with web performance. 20:47.460 --> 20:49.990 Number one is, obviously, reduce requests. 20:49.990 --> 20:51.365 Less requests, less chance you're 20:51.365 --> 20:54.160 gonna run into latency issues, the faster everything's 20:54.160 --> 20:55.280 going to be. 20:55.280 --> 20:58.790 Reduced asset size, clear your-- the browser pipeline 20:58.790 --> 21:01.220 that much faster to go get more assets. 21:01.220 --> 21:03.740 Smaller is better. 21:03.740 --> 21:06.030 We'll talk a little bit more about that in a bit. 21:06.030 --> 21:08.290 And then speed up page render. 21:08.290 --> 21:10.460 You actually can get a lot of benefit 21:10.460 --> 21:12.960 out of making things look like they're filling 21:12.960 --> 21:15.020 in faster than they really are. 21:15.020 --> 21:17.110 So trying to figure out how you can make a page 21:17.110 --> 21:19.370 look like it's rendering more quickly. 21:21.980 --> 21:24.900 So again, getting back to the no request-- the first tenet, 21:24.900 --> 21:28.200 the best request really is no request. 21:28.200 --> 21:31.570 The less request you make, the much, much happier. 21:31.570 --> 21:33.890 So the more you can cut out the better. 21:33.890 --> 21:36.540 And probably the number one easy win 21:36.540 --> 21:40.020 to make that happen is making sure browser cache is properly 21:40.020 --> 21:43.080 enabled on your server, and making sure that elements are 21:43.080 --> 21:45.780 being cached on the browser. 21:45.780 --> 21:47.490 A really easy way of figuring out 21:47.490 --> 21:50.030 if browser cache is enabled, you can go to redbot.org 21:50.030 --> 21:51.819 and it'll tell you, hey, your server 21:51.819 --> 21:54.360 for your particular website is caching assets, or not caching 21:54.360 --> 21:55.680 assets. 21:55.680 --> 21:59.210 If it's not, start figuring out what the metrics are 21:59.210 --> 22:01.770 for actually setting that up with Apache, 22:01.770 --> 22:05.170 or whatever you're using, so that the browser can hold on 22:05.170 --> 22:06.187 to requests. 22:06.187 --> 22:08.270 Because, basically, what the cache allows it to do 22:08.270 --> 22:10.800 is, they'll say, hey, this asset hasn't changed, 22:10.800 --> 22:13.660 or I've been told not to go request this for awhile. 22:13.660 --> 22:15.330 And the browser makes less requests, 22:15.330 --> 22:17.750 which means your web page appears to be faster. 22:17.750 --> 22:20.110 So browser cache is definitely the number 22:20.110 --> 22:21.750 one easy web perf win. 22:21.750 --> 22:24.000 As a front end developer, you have zero to do. 22:24.000 --> 22:26.736 Just go tell a server admin, please do this. 22:26.736 --> 22:28.610 And that's sometimes easy and sometimes hard. 22:28.610 --> 22:30.760 I've been waiting on years for that 22:30.760 --> 22:33.720 at my university for some things, so. 22:33.720 --> 22:36.040 Compress HTML and CSS, use mod_deflate. 22:36.040 --> 22:38.310 Again, this is a really easy win, 22:38.310 --> 22:39.685 making sure things are compressed 22:39.685 --> 22:42.680 and as small as they possibly can be. 22:42.680 --> 22:45.410 And this is just, again, set up on a server. 22:45.410 --> 22:47.610 One thing that I think is a little harder, 22:47.610 --> 22:50.470 and maybe isn't necessarily necessary, is 22:50.470 --> 22:52.560 avoiding AJAX requests. 22:52.560 --> 22:55.160 If you know your web page is going 22:55.160 --> 22:57.461 to be making a request eventually for content, 22:57.461 --> 22:58.960 and that content's never-- not going 22:58.960 --> 23:02.455 to change based on an action that a user has taken, 23:02.455 --> 23:04.580 there's nothing wrong with taking that and actually 23:04.580 --> 23:06.944 embedding that as part of the web page to begin with. 23:06.944 --> 23:08.360 And maybe putting it into a script 23:08.360 --> 23:11.220 tag with set-to-type text HTML, and then 23:11.220 --> 23:15.500 using that content to populate the AJAX area instead. 23:15.500 --> 23:19.070 So you're essentially kind of concatenating markup together. 23:19.070 --> 23:22.850 So it's a way of thinking about how to improve performance. 23:22.850 --> 23:25.480 It's not really a server thing, but something to keep in mind. 23:25.480 --> 23:27.610 So images easy wins. 23:27.610 --> 23:30.590 Again, no request, try to avoid images. 23:30.590 --> 23:33.830 Think about how you can use blocks of CSS color, blocks 23:33.830 --> 23:37.350 of-- to make gradients, to make patterns all with CSS, 23:37.350 --> 23:40.240 rather than trying to use an image to do it. 23:40.240 --> 23:42.970 Number one thing would be, for me, is image compression. 23:42.970 --> 23:45.560 That's the most difficult thing I have dealing with designers, 23:45.560 --> 23:49.370 is going, you don't have to save it at 80% JPEG. 23:49.370 --> 23:51.756 Not everything has to be saved at PNG24. 23:51.756 --> 23:53.880 You can actually kind of decrease that, get smaller 23:53.880 --> 23:55.440 sizes and still be good. 23:55.440 --> 23:57.220 People don't notice artifacts, they really 23:57.220 --> 23:58.247 don't, they don't care. 23:58.247 --> 23:59.830 They're actually probably more worried 23:59.830 --> 24:02.880 about your textual content than your image content anyway. 24:02.880 --> 24:05.960 So being a little less and being critical 24:05.960 --> 24:08.920 about what compression you use can save massive amounts 24:08.920 --> 24:11.305 of bandwidth in size. 24:11.305 --> 24:13.590 On responsive images, I'm just getting 24:13.590 --> 24:15.410 into this, use sourceset. 24:15.410 --> 24:18.810 It's an addition to what you're using with your regular images. 24:18.810 --> 24:20.910 Pictures should, kind of, only be used in terms 24:20.910 --> 24:24.890 of art directed and I'm not sure how much people use 24:24.890 --> 24:28.110 art directed. And again, avoid dark matter. 24:28.110 --> 24:30.520 If you have an element that has an image in it, 24:30.520 --> 24:33.380 and you're using display none, it's really bad. 24:33.380 --> 24:35.170 You're still downloading the image. 24:35.170 --> 24:36.545 You haven't done anything, you've 24:36.545 --> 24:40.740 just essentially enforced a penalty on your end user 24:40.740 --> 24:43.370 to make something a little bit easier for yourself. 24:43.370 --> 24:45.470 And really, honestly, in responsive design, 24:45.470 --> 24:46.970 if you're using display none, you're 24:46.970 --> 24:48.511 probably doing something wrong anyway 24:48.511 --> 24:52.860 because we should be showing as much as we can to people. 24:52.860 --> 24:57.710 Desktop and mobile should be the same. 24:57.710 --> 25:00.240 So what kind of tools can we use, in terms of images, 25:00.240 --> 25:01.850 to make your life easier? 25:01.850 --> 25:04.200 If you're not using a task runner, 25:04.200 --> 25:06.420 it is, after performance budget, the thing 25:06.420 --> 25:08.990 you should be using to increase your-- 25:08.990 --> 25:10.650 to make your life easier, in terms 25:10.650 --> 25:12.300 of performance perspective. 25:12.300 --> 25:14.650 So imagemin, instead of a designer 25:14.650 --> 25:18.465 having to think about some image compression ability, 25:18.465 --> 25:20.590 imagemin will take care of it a little bit for you. 25:20.590 --> 25:24.350 Image-resize will resize images in terms of doing SourceSet. 25:24.350 --> 25:28.130 Spritesmith-- svgmin, if you're using SVG. 25:28.130 --> 25:29.890 If you're not using a task runner, 25:29.890 --> 25:33.750 you can also use services like kraken.io or smushit 25:33.750 --> 25:36.860 to compress images for you, to get the most out of it. 25:36.860 --> 25:39.990 And imigix.com, I guess that's kind 25:39.990 --> 25:42.430 of the replacement for the sentia.io, 25:42.430 --> 25:45.780 will automatically, on the fly-- if you just add a URL, 25:45.780 --> 25:48.510 it'll automatically, on the fly, resize images for you. 25:48.510 --> 25:50.380 So these are some tools that you can use in terms of images, 25:50.380 --> 25:51.546 and work into your workflow. 25:51.546 --> 25:54.000 Again, with Grunt & Gulp they have 25:54.000 --> 25:56.640 made web performance so much easier, 25:56.640 --> 25:59.850 it becomes a lot less thought. 25:59.850 --> 26:02.630 So, web perf in JavaScript. 26:02.630 --> 26:04.620 So this is our second, kind of massive thing 26:04.620 --> 26:06.880 that we're dealing with. 26:06.880 --> 26:10.810 I would avoid using bulky frameworks if you can. 26:10.810 --> 26:13.576 I know jQuery is awesome, and makes life great, 26:13.576 --> 26:15.575 but you're getting penalized for two things when 26:15.575 --> 26:17.460 you use JavaScript. 26:17.460 --> 26:21.217 A, it's the download, and then B, the browser still parses it, 26:21.217 --> 26:23.800 takes time to figure out and try to make that available to you 26:23.800 --> 26:24.710 to use. 26:24.710 --> 26:26.930 So everything in jQuery is available to you 26:26.930 --> 26:28.020 to use at any time. 26:28.020 --> 26:29.660 And, of course, for the most part 26:29.660 --> 26:32.200 people tend to ignore the vast bulk of it. 26:32.200 --> 26:35.920 It's gotten better with jQuery2, but still we had a developer 26:35.920 --> 26:39.490 the other day who used jQuery UI, had the entire framework, 26:39.490 --> 26:41.760 so that-- and it was 200 kilobytes, just 26:41.760 --> 26:44.559 so he could have a accordion on his web page. 26:44.559 --> 26:46.100 And that's the kind of stuff you have 26:46.100 --> 26:49.150 to be a little more critical of, and be thinking about that, 26:49.150 --> 26:52.535 hey, I don't need all of this to do a really simple thing. 26:52.535 --> 26:53.910 And so a better thing to do would 26:53.910 --> 26:57.880 be microjs.com, which has a handful 26:57.880 --> 27:00.070 of these really tiny little packages that 27:00.070 --> 27:01.390 do really specific things. 27:01.390 --> 27:06.470 I think it's very much in that kind of node style of thinking 27:06.470 --> 27:08.310 about front end JavaScript. 27:08.310 --> 27:10.910 Or, even better, learn Vanilla JS 27:10.910 --> 27:15.800 and get really familiar with Mozilla Developer Network. 27:15.800 --> 27:18.180 There's some really great things that you can write, 27:18.180 --> 27:19.930 just really simply. 27:19.930 --> 27:22.140 If all you're doing is selecting elements on a page, 27:22.140 --> 27:24.890 it's a lot easier to write document.getElementById 27:24.890 --> 27:28.260 than it is to include jQuery to get sizzle. 27:28.260 --> 27:31.330 Kind of an easy trade off there. 27:31.330 --> 27:34.790 Try to avoid DOM re-flows and repaints. 27:34.790 --> 27:38.490 Using JS to modify DOM is something that we all use. 27:38.490 --> 27:41.210 But if you're going to be inserting document elements 27:41.210 --> 27:43.500 into the document, kind of build them 27:43.500 --> 27:47.420 off canvas with a document fragment, and then insert them. 27:47.420 --> 27:51.260 Or if you're going to add styles, add classes. 27:51.260 --> 27:53.210 Don't add actual styles to the elements, 27:53.210 --> 27:55.050 just always add a class. 27:55.050 --> 27:57.100 So as you add more attributes to the class, 27:57.100 --> 27:59.780 it's a lot easier to A, keep updated, and B, 27:59.780 --> 28:02.190 you're applying that style and all those parameters 28:02.190 --> 28:05.256 at once to an element, Instead of like, select element, apply 28:05.256 --> 28:07.380 style, select element, apply style, select element, 28:07.380 --> 28:09.750 apply style. 28:09.750 --> 28:10.840 Use Touch or FastClick. 28:10.840 --> 28:12.940 FastClick, I think, would be the best bet 28:12.940 --> 28:18.180 to reduce perceived performance, in terms of Touch events. 28:18.180 --> 28:21.480 And CDNs to serve common JS libraries. 28:21.480 --> 28:25.130 Google does a fantastic job of having a CDN for, basically, 28:25.130 --> 28:26.430 everything. 28:26.430 --> 28:29.047 And that makes your website just, again, that much faster, 28:29.047 --> 28:30.630 because people already have it cached. 28:30.630 --> 28:34.070 And that takes care of the caching for you. 28:34.070 --> 28:35.710 So some tools to think about using. 28:35.710 --> 28:38.540 Uglify, which will minify things for you. 28:38.540 --> 28:43.490 Concat, use with discretion, concatenation. 28:43.490 --> 28:46.580 Taking all of your files and putting them into one request 28:46.580 --> 28:49.290 is not always the best thing. 28:49.290 --> 28:52.110 There's actually kind of a break point, where 28:52.110 --> 28:54.240 having all that stuff into one massive request that 28:54.240 --> 28:55.510 takes a really long time to download, 28:55.510 --> 28:57.093 is actually worse than just having two 28:57.093 --> 28:59.424 or three requests that are a little bit smaller. 28:59.424 --> 29:00.840 Something you have to kind of find 29:00.840 --> 29:03.740 on a per-project basis, what is gonna make sense for you. 29:03.740 --> 29:10.260 So don't just like be-- concat is one part of a Gulp task. 29:10.260 --> 29:13.970 You have to think about maybe splitting that up a little bit. 29:13.970 --> 29:18.055 Closure-compiler, google-cdn-- google-cdn is pretty cool, 29:18.055 --> 29:19.430 because what it does is basically 29:19.430 --> 29:21.220 takes all of your local libraries, 29:21.220 --> 29:23.020 if they exist in google-cdn it'll 29:23.020 --> 29:26.810 replace those local requests with what the CDN version would 29:26.810 --> 29:28.190 be in your markup. 29:28.190 --> 29:30.490 And so that's an amazingly handy tool. 29:30.490 --> 29:34.270 I would only use it if you have, like a production task in Gulp. 29:34.270 --> 29:36.616 But, yeah, that would make, again, your life easy. 29:36.616 --> 29:37.990 You don't have to figure out what 29:37.990 --> 29:40.210 exists there, and doesn't exist there and take advantage of it. 29:40.210 --> 29:41.930 You can just use it right your way. 29:41.930 --> 29:44.100 And, again, on the web, in terms of things to learn, 29:44.100 --> 29:46.250 microjs.com. 29:46.250 --> 29:48.100 I can't stress enough how awesome it is, 29:48.100 --> 29:49.600 in terms of being able to find tools 29:49.600 --> 29:52.680 that do exactly the right thing, the exact thing you're 29:52.680 --> 29:53.910 looking for. 29:53.910 --> 29:56.060 And to learn from developer.mozilla.org 29:56.060 --> 30:00.230 and developers.google.com because there's 30:00.230 --> 30:02.340 a massive amount of infrastructure 30:02.340 --> 30:05.261 and write up right now, regarding what's going on. 30:05.261 --> 30:07.760 And kind of to get an idea of what a content breakdown looks 30:07.760 --> 30:11.865 like, in terms of WebPagetest, so you 30:11.865 --> 30:14.440 can get an idea of where you might want 30:14.440 --> 30:18.630 to focus on your various tools. 30:18.630 --> 30:20.910 In terms of-- that's pretty straightforward. 30:20.910 --> 30:25.450 Web fonts are by far my biggest issue. 30:25.450 --> 30:27.570 And then, third party code easy wins. 30:27.570 --> 30:29.070 A lot of times we don't really think 30:29.070 --> 30:33.380 that if we're relying on a third party group, 30:33.380 --> 30:34.705 how does that affect us. 30:34.705 --> 30:36.330 Hey, I just include this little snippet 30:36.330 --> 30:38.850 that was this like button, it was like one line, 30:38.850 --> 30:40.600 it's gotta be awesome and fast, right? 30:40.600 --> 30:41.497 It's only one line. 30:41.497 --> 30:43.080 But behind the scenes, they're loading 30:43.080 --> 30:45.200 100k of JavaScript with 15 requests, 30:45.200 --> 30:46.560 or something along those lines. 30:46.560 --> 30:49.970 So you're taking a really big hit by including third party. 30:49.970 --> 30:52.562 If you want to test it, you can use spof-o-matic, 30:52.562 --> 30:54.770 which is something that's available in the Chrome Web 30:54.770 --> 30:57.061 Store and becomes a little thing that's part of Chrome. 30:57.061 --> 30:59.520 And you can test to see, hey, if Facebook went away, 30:59.520 --> 31:00.947 how would my page react? 31:00.947 --> 31:02.780 How much longer would my page take the load? 31:02.780 --> 31:03.620 What would happen? 31:03.620 --> 31:05.960 And it's, again, a way of testing it. 31:05.960 --> 31:08.950 And I would also avoid social media widgets. 31:08.950 --> 31:11.550 I mean, is everyone really excited to say 31:11.550 --> 31:16.730 how much-- they only have zero likes on every article? 31:16.730 --> 31:22.270 So a good way of avoiding that is Heiss, in Germany, 31:22.270 --> 31:23.589 uses a two click social widget. 31:23.589 --> 31:25.380 So it kind of says, hey, if you click this, 31:25.380 --> 31:29.900 you'll get your chance to like this page. 31:29.900 --> 31:33.040 But it increases your privacy and, again, 31:33.040 --> 31:35.685 increases performance massively, drastically increases 31:35.685 --> 31:37.310 the performance of your web page by not 31:37.310 --> 31:41.310 relying on that social media widget to be included. 31:41.310 --> 31:44.382 WebPagetest also allows you to test SPOF. 31:44.382 --> 31:45.840 There's actually a little tab where 31:45.840 --> 31:48.010 you can type in all the URLs that you essentially 31:48.010 --> 31:52.700 want dropped to dev/null, and see how your page reacts. 31:52.700 --> 31:56.900 What kind of loads, what doesn't load, and when it loads. 31:56.900 --> 32:00.010 So if the best request was no request, 32:00.010 --> 32:03.540 then the worst request is one that blocks the parser. 32:03.540 --> 32:06.140 And so it's really important to also understand not just that 32:06.140 --> 32:10.540 we're-- what we're requesting, but how the browser actually 32:10.540 --> 32:13.176 handles and draws what we've requested. 32:13.176 --> 32:14.550 And the most important thing here 32:14.550 --> 32:17.120 is to understand the Critical Rendering Path. 32:17.120 --> 32:19.340 So what the critical rendering path basically states, 32:19.340 --> 32:22.900 is the browser goes and fetches your markup 32:22.900 --> 32:24.830 and starts creating your DOM tree. 32:24.830 --> 32:26.750 Starts laying out all of y our-- not 32:26.750 --> 32:30.090 laying out all of your elements but at least building the tree. 32:30.090 --> 32:32.010 As part of that, it says, hey, there's CSS. 32:32.010 --> 32:35.220 I should go download the CSS, so it downloads your CSS. 32:35.220 --> 32:37.294 So the parser is still creating the DOM tree 32:37.294 --> 32:38.460 but it's waiting on the CSS. 32:38.460 --> 32:41.710 Because it doesn't know how to actually draw that stuff out, 32:41.710 --> 32:44.220 and it's gonna say, CSS is gonna tell me how to actually 32:44.220 --> 32:45.760 draw everything out. 32:45.760 --> 32:48.367 And so once the CSS is done your rendering can start. 32:48.367 --> 32:49.450 So that's render blocking. 32:49.450 --> 32:51.880 CSS render blocks your page. 32:51.880 --> 32:55.604 Once the CSS is done, your page can start being rendered. 32:55.604 --> 32:58.020 And then if you have JavaScript, it finds your JavaScript. 32:58.020 --> 33:00.690 It'll actually blocked everything, because JavaScript 33:00.690 --> 33:04.200 can affect both the DOM and CSS, so it says, hey, 33:04.200 --> 33:05.060 I'm going to stop. 33:05.060 --> 33:07.870 So what you want to understand is 33:07.870 --> 33:10.950 how to optimize to make sure your website actually 33:10.950 --> 33:12.876 starts loading as quickly as they can, 33:12.876 --> 33:15.375 for the thing that-- for the most important thing the person 33:15.375 --> 33:17.041 can see, which is above the fold, what's 33:17.041 --> 33:18.660 actually in the view port. 33:18.660 --> 33:20.760 You want that to load as fast as you can. 33:20.760 --> 33:22.630 Anything that's not in view should 33:22.630 --> 33:26.440 be able to be deferred and delayed for later. 33:26.440 --> 33:29.636 And maybe your web page actually takes quite a while to load, 33:29.636 --> 33:31.510 but you've deferred everything and the user's 33:31.510 --> 33:34.230 starting to actually interact with content. 33:34.230 --> 33:37.050 So you want to optimize for the critical rendering path. 33:37.050 --> 33:39.115 You want to-- in the waterfall view-- 33:39.115 --> 33:41.410 and you have to learn to love the waterfall if you want 33:41.410 --> 33:47.020 to learn web performance-- is you try to make-- it's not 33:47.020 --> 33:50.740 amazingly obvious-- that Start Render line as far to the left 33:50.740 --> 33:52.640 as you possibly can. 33:52.640 --> 33:54.480 You want so that the user actually starts 33:54.480 --> 33:55.707 seeing something happening. 33:55.707 --> 33:57.040 That's what the Start Render is. 33:57.040 --> 34:01.250 It went from a web-- went from a white block, nothing is there, 34:01.250 --> 34:03.970 nothing-- I don't know what's going on, to actually, 34:03.970 --> 34:06.010 hey, things are starting to happen. 34:06.010 --> 34:08.710 You want to make sure that that page render is as far 34:08.710 --> 34:10.929 to the left as you possibly can, as close to DOM 34:10.929 --> 34:14.310 content loaded as you can make it. 34:14.310 --> 34:17.190 So people know that after the DOM has been loaded, 34:17.190 --> 34:19.840 and after CSS has been loaded, hey, 34:19.840 --> 34:21.527 we can start seeing things. 34:21.527 --> 34:23.819 So you want to start figuring out where these lines are 34:23.819 --> 34:27.159 and trying to make them as good as you can. 34:27.159 --> 34:29.760 And this is kind of an example of WebPagetest, actually has 34:29.760 --> 34:30.610 this filmstrip view. 34:30.610 --> 34:34.380 So it could show you where that cut-off is between nothing, 34:34.380 --> 34:37.130 0%, lowered at two seconds in on my web page, 34:37.130 --> 34:40.409 to, at least something has started to load. 34:40.409 --> 34:42.498 And this is on a 3G connection, which 34:42.498 --> 34:44.800 is why it seems a little slow. 34:44.800 --> 34:46.760 Well, this is a great way-- like, you never 34:46.760 --> 34:50.710 would really get this out of DevTools or PageSpeed Insights. 34:50.710 --> 34:52.630 But this is a way of trying to figure out, 34:52.630 --> 34:54.045 hey, this is actually how it would 34:54.045 --> 34:56.080 look on this particular device, or this 34:56.080 --> 34:58.200 is how it actually would look loading 34:58.200 --> 35:02.550 on this particular connection from this particular location. 35:02.550 --> 35:05.670 And so you can get an idea of how we can better do that. 35:05.670 --> 35:08.470 So the filmstrip view is a really good look 35:08.470 --> 35:11.450 at critical rendering path as well as percent complete. 35:11.450 --> 35:12.200 [BUMPS MICROPHONE] 35:12.200 --> 35:13.299 Whoops, sorry. 35:13.299 --> 35:14.840 So again, you can start figuring out, 35:14.840 --> 35:17.200 with these massively useful charts, 35:17.200 --> 35:20.040 how can I get these things faster and better 35:20.040 --> 35:23.730 and farther to the left, so things are going on. 35:23.730 --> 35:27.230 So some easy wins in terms of the critical rendering path 35:27.230 --> 35:30.730 would be to defer loading of JavaScript. 35:30.730 --> 35:33.385 Probably the easiest thing, and best thing you can still do 35:33.385 --> 35:36.180 and the best practice, is put your JavaScript right 35:36.180 --> 35:38.280 before the body tag. 35:38.280 --> 35:43.092 That's, regardless of your multiple HTML5 attributes 35:43.092 --> 35:45.050 that you can use now, it's going to be the best 35:45.050 --> 35:47.650 and simplest thing to do. 35:47.650 --> 35:50.452 Otherwise you would probably use deferred 35:50.452 --> 35:52.160 if you have to have JavaScript elsewhere, 35:52.160 --> 35:53.960 to at least make it look like it's 35:53.960 --> 35:57.980 being above that-- above the body tag. 35:57.980 --> 35:59.525 And then async. 35:59.525 --> 36:02.710 That's the order I would do, and I think most people actually-- 36:02.710 --> 36:04.550 others would say async comes before defer. 36:04.550 --> 36:07.100 I would say defer before async. 36:07.100 --> 36:09.460 And you can also script elements into the DOM 36:09.460 --> 36:10.509 using the on-load event. 36:10.509 --> 36:12.050 So if you know something isn't needed 36:12.050 --> 36:14.700 at all until after the on-load event, until the page has been 36:14.700 --> 36:17.340 finished loading, the best thing to do 36:17.340 --> 36:20.750 is start inserting element after on-load event. 36:20.750 --> 36:23.630 So place critical CSS directly within your document 36:23.630 --> 36:26.140 and load the rest of the CSS after on-load, with JavaScript, 36:26.140 --> 36:28.330 is another way of getting the critical rendering 36:28.330 --> 36:30.246 path to make sure everything in that view port 36:30.246 --> 36:33.326 that CSS is not blocking. 36:33.326 --> 36:34.959 And defer the rest. 36:34.959 --> 36:36.625 A good service to use this is Penthouse. 36:36.625 --> 36:41.160 Penthouse is also, I believe, a Grunt &Gulp plug-in that you 36:41.160 --> 36:44.170 can use to figure out what your critical CSS is and have it 36:44.170 --> 36:46.460 embedded in your web page. 36:46.460 --> 36:48.680 And then for anything that's above the-- again, 36:48.680 --> 36:50.690 above the fold-- the fold is gonna-- 36:50.690 --> 36:54.952 is coming back in a massive way for web performance-- 36:54.952 --> 36:55.910 use the same host name. 36:55.910 --> 36:58.930 So one DNS for all of them reduces DNS look-ups, 36:58.930 --> 37:01.760 which is, again, being affected by latency. 37:01.760 --> 37:03.440 So how slim can you make it? 37:03.440 --> 37:05.820 And could you possibly try to have a single request 37:05.820 --> 37:08.250 for all above the fold content. 37:08.250 --> 37:12.250 So having your CSS in lines, no real need 37:12.250 --> 37:13.710 for images-- you can use data URIs 37:13.710 --> 37:15.160 if you have really small images. 37:15.160 --> 37:16.770 Could you do that all in, essentially, 37:16.770 --> 37:20.650 one package of the markup and deliver that to the client, 37:20.650 --> 37:23.276 and then defer everything else after that 37:23.276 --> 37:25.800 to be amazingly fast? 37:25.800 --> 37:29.660 Because the ultimate goal is a narrower and shorter waterfall, 37:29.660 --> 37:31.070 but also focus on getting, again, 37:31.070 --> 37:33.090 that fast initial render to at least give the user 37:33.090 --> 37:34.590 something, instead of them just kind 37:34.590 --> 37:36.550 of waiting and waiting and waiting 37:36.550 --> 37:39.260 for something to happen. 37:39.260 --> 37:41.920 Give them something to look at and the rest of it 37:41.920 --> 37:44.500 can be lowered afterward. 37:44.500 --> 37:47.380 And it's not enough to be like, hey, I did one test. 37:47.380 --> 37:51.480 You also want to make sure you test what I call the squishy. 37:51.480 --> 37:53.864 So test set all your break points 37:53.864 --> 37:55.530 and see how your performance is working, 37:55.530 --> 37:58.113 and make sure you're using the correct media queries, like min 37:58.113 --> 38:00.085 width versus max width. 38:00.085 --> 38:02.540 They can have massive implications 38:02.540 --> 38:04.890 if you use them incorrectly. 38:04.890 --> 38:08.930 And so you can use scripting and custom view ports 38:08.930 --> 38:12.130 with WebPagetest. 38:12.130 --> 38:16.030 So you can actually go in, and type in and say, 38:16.030 --> 38:18.700 hey, this is my break point, I want you to test at this point 38:18.700 --> 38:20.330 and see what happens. 38:20.330 --> 38:21.270 And, again, save that. 38:21.270 --> 38:23.960 And go through each iteration of all your break points 38:23.960 --> 38:26.170 and test those each individually, 38:26.170 --> 38:29.480 and see how your web performance works from each viewpoint 38:29.480 --> 38:33.760 to each-- each break point to each break point. 38:33.760 --> 38:37.440 And again this is what, if you scripted it and set it at 324, 38:37.440 --> 38:41.640 it would give you a filmstrip view in a separate report. 38:41.640 --> 38:45.490 WebPagetest, I've given you kind of like an amazingly high level 38:45.490 --> 38:48.470 view, the things that I find massively useful 38:48.470 --> 38:49.910 in WebPagetest. 38:49.910 --> 38:53.240 But Andy Davies and Aaron Peters go 38:53.240 --> 38:57.540 into much more detail about what you can get out of WebPagetest. 38:57.540 --> 39:00.610 It's a massively useful, massively customizable 39:00.610 --> 39:03.710 tool to figure out what's going on. 39:03.710 --> 39:05.460 And they did this-- and this was actually, 39:05.460 --> 39:08.820 I think, one of the top 10 talks in Europe last year, 39:08.820 --> 39:09.890 or two years ago. 39:09.890 --> 39:12.360 And they do just a fantastic job, 39:12.360 --> 39:14.790 so this is how you can learn more. 39:14.790 --> 39:16.970 So reviewing tips for easy wins. 39:16.970 --> 39:18.430 Number one, I would say, is budget, 39:18.430 --> 39:20.930 to give yourself and a client a performance goal. 39:20.930 --> 39:23.900 And if you can, base that on competitors. 39:23.900 --> 39:27.270 Figure out what their baseline performance is and make sure 39:27.270 --> 39:29.020 their website-- their client's website 39:29.020 --> 39:32.120 works better than the competitors. 39:32.120 --> 39:35.320 Enable cache headers, really easy win. 39:35.320 --> 39:37.590 Enable compression, again, amazingly easy win. 39:37.590 --> 39:39.480 Just talk to a server admin. 39:39.480 --> 39:41.630 Properly format or reduce images. 39:41.630 --> 39:42.722 Defer as much as you can. 39:42.722 --> 39:44.930 Just start thinking about how much can you put off to 39:44.930 --> 39:47.846 after the on-load event that you can. 39:47.846 --> 39:49.720 So the web page is at least there and usable, 39:49.720 --> 39:52.130 and then everything else can kind of fill in after the fact. 39:52.130 --> 39:53.260 This includes images, actually. 39:53.260 --> 39:54.660 You can defer images to just after on-load 39:54.660 --> 39:56.034 if they're below the fold, right? 39:56.034 --> 39:59.380 If you don't need to see it-- if you can't see it, 39:59.380 --> 40:01.290 does it need to be loaded? 40:01.290 --> 40:03.860 And then, finally, use a task runner to build web performance 40:03.860 --> 40:04.651 into your workflow. 40:04.651 --> 40:06.490 If you're not using a task runner, 40:06.490 --> 40:09.770 it's gonna be the easiest way to make all this stuff work. 40:09.770 --> 40:12.850 And there's tons of tools, and tips and tricks 40:12.850 --> 40:15.440 about how to make sure web performance 40:15.440 --> 40:17.900 is working that way. 40:17.900 --> 40:20.680 Because I mentioned it in my description, 40:20.680 --> 40:22.680 I wasn't sure how much time I was going to have, 40:22.680 --> 40:25.090 I'm just going to cover this really quickly. 40:25.090 --> 40:31.770 Another way of kind of slicing into performance, 40:31.770 --> 40:34.480 if you're not as-- if you don't feel as comfortable, I guess, 40:34.480 --> 40:37.070 with the front end stuff, is to use a technique called 40:37.070 --> 40:39.450 RESS, which stands for Responsive Design 40:39.450 --> 40:41.090 and Server-Side Components. 40:41.090 --> 40:42.600 I don't know what happens to the D 40:42.600 --> 40:45.190 and the C. You'll have to take that up with Luke Wroblewski. 40:45.190 --> 40:47.080 I have no idea how he actually came up 40:47.080 --> 40:51.110 with RESS out of that amazingly long description. 40:51.110 --> 40:52.930 But, basically, what it is, it gives you 40:52.930 --> 40:57.140 an interesting way of sort of swapping in and out elements. 40:57.140 --> 41:00.110 To be things based on, primarily, 41:00.110 --> 41:04.530 user agent string to make things perform a little better. 41:04.530 --> 41:06.590 So in our case, we used it on our homepage, 41:06.590 --> 41:10.310 because we didn't feel quite comfortable doing a responsive 41:10.310 --> 41:12.880 slide show or carousel. 41:12.880 --> 41:14.644 Politically, we had to have a carousel. 41:14.644 --> 41:15.810 Who doesn't love a carousel? 41:15.810 --> 41:18.370 It makes everyone's lives amazing and easier, 41:18.370 --> 41:19.130 I don't know. 41:19.130 --> 41:21.885 But we didn't have, I think, the in-house talent 41:21.885 --> 41:25.010 to kind of make it responsive and fast and performant. 41:25.010 --> 41:27.770 So we used the technique RESS to actually swap that out 41:27.770 --> 41:28.500 on the server. 41:28.500 --> 41:33.980 So for a mobile device we gave you a slightly different 41:33.980 --> 41:37.450 carousel, and on the front end, for desktop, 41:37.450 --> 41:39.502 we gave you a different carousel. 41:39.502 --> 41:40.460 So it can be a scalpel. 41:40.460 --> 41:42.510 It doesn't replace what you're doing with responsive design, 41:42.510 --> 41:44.080 responsive design is still the base. 41:44.080 --> 41:47.140 Flexible layouts, all that kind of stuff is still the base. 41:47.140 --> 41:49.660 If you don't feel quite as comfortable on the front end, 41:49.660 --> 41:52.490 you can use RESS to actually swap things out. 41:52.490 --> 41:55.300 I did a presentation a long time ago, 41:55.300 --> 41:57.615 called An Evolution of Responsive Design. 41:57.615 --> 41:58.990 It's definitely not an evolution, 41:58.990 --> 42:03.530 I think I was a-- bit of hubris on my part several years ago. 42:03.530 --> 42:06.330 Makes me seem like a real ass. 42:06.330 --> 42:10.190 But, basically, it goes into tips and tricks and techniques 42:10.190 --> 42:14.590 about how you can actually use RESS, or use the server 42:14.590 --> 42:17.530 to help you in delivering a performant website, 42:17.530 --> 42:20.900 beyond just the cache headers, or whatever it would be. 42:23.770 --> 42:28.100 So some more web performance tools. 42:28.100 --> 42:31.080 Perf tooling today. 42:31.080 --> 42:33.880 If you're using Gulp and Grunt, this 42:33.880 --> 42:35.670 is the resource you'd want to use 42:35.670 --> 42:39.320 to find all the tools to make your life easier. 42:39.320 --> 42:41.870 It's a really great, handy list of resources 42:41.870 --> 42:44.760 to automate your process, to just kind 42:44.760 --> 42:47.360 of slide in these things to figure out how well they're 42:47.360 --> 42:49.870 going to work for you. 42:49.870 --> 42:52.630 As important as it is to think about performance 42:52.630 --> 42:55.710 during development, you also have to monitor performance 42:55.710 --> 42:57.730 and make sure your web performance is still 42:57.730 --> 42:58.872 holding up. 42:58.872 --> 43:00.330 So Google Analytics has site speed. 43:00.330 --> 43:02.710 So if your website is using Google Analytics to monitor 43:02.710 --> 43:04.160 your hits and stuff like that, you 43:04.160 --> 43:08.170 can also track how your site speed is doing, 43:08.170 --> 43:09.500 good or poor or whatever. 43:09.500 --> 43:11.580 And this is-- the great thing about this, 43:11.580 --> 43:12.930 this is real user data. 43:12.930 --> 43:15.457 It's not you trying to mimic it with WebPagetest, 43:15.457 --> 43:17.082 or whatever it is, which is-- you know, 43:17.082 --> 43:18.457 ends up what you're doing, you're 43:18.457 --> 43:20.320 mimicking a real request. 43:20.320 --> 43:21.720 This is real requests. 43:21.720 --> 43:22.991 This is real feedback. 43:22.991 --> 43:24.490 And you can start narrowing it down. 43:24.490 --> 43:27.860 Say, hey, from particular-- you can cut and slice this data 43:27.860 --> 43:29.560 the same way you would page views. 43:29.560 --> 43:32.860 So you can say, hey, from this particular country we're seeing 43:32.860 --> 43:35.077 a big uptick in purchases. 43:35.077 --> 43:36.660 You know, how's our performance doing? 43:36.660 --> 43:37.860 Is there anything we can do to tweak 43:37.860 --> 43:39.450 that to make it load that much faster, 43:39.450 --> 43:42.430 and maybe get more conversions, get more page views? 43:42.430 --> 43:44.010 Be better for them. 43:44.010 --> 43:46.220 Another tool for using performance monitoring 43:46.220 --> 43:50.300 would be SpeedCurve, which is a tool from Mark Zeman. 43:50.300 --> 43:51.904 Would recommend that. 43:51.904 --> 43:53.820 Not only can you monitor your own performance, 43:53.820 --> 43:55.444 but, again, you can look at competitors 43:55.444 --> 43:58.010 and say, how's the competitor's performance doing? 43:58.010 --> 44:00.590 It'll tell you, and then as their performance changes, 44:00.590 --> 44:02.200 you can go, hey, maybe I need to start 44:02.200 --> 44:05.050 tweaking myself to stay ahead of them to be better 44:05.050 --> 44:06.265 than the competitor. 44:06.265 --> 44:10.390 And to make-- so we can, again, beat them. 44:10.390 --> 44:12.990 And he just released, I think literally yesterday, this perf 44:12.990 --> 44:14.990 map, which is kind of a different way of looking 44:14.990 --> 44:16.010 at web performance. 44:16.010 --> 44:18.200 So I haven't used it yet, but it's 44:18.200 --> 44:20.590 another way of looking at what assets on your web page 44:20.590 --> 44:24.160 may actually be the slowest, or what's taking the longest time, 44:24.160 --> 44:26.490 and kind of categorizing it in a really nice visual way 44:26.490 --> 44:28.490 instead of just having to learn the waterfall 44:28.490 --> 44:32.110 and sort of visualize in your own head. 44:32.110 --> 44:35.090 This gives you a really nice tool 44:35.090 --> 44:38.300 for seeing individual bits, and how long they were taking, 44:38.300 --> 44:41.910 and maybe where you can make changes. 44:41.910 --> 44:44.180 More real user testing would be Boomerang. 44:44.180 --> 44:46.180 It's something, again, you have set up yourself. 44:46.180 --> 44:47.554 But you can figure out, hey, this 44:47.554 --> 44:50.430 is how performance is working for real end users, 44:50.430 --> 44:52.570 and what I have to tweak. 44:52.570 --> 44:54.280 Because performance is not just a-- 44:54.280 --> 44:56.280 it really is not the end of-- it's not something 44:56.280 --> 44:57.720 you tack on to the end of a process, 44:57.720 --> 44:59.050 and it's not something you just give up when 44:59.050 --> 45:00.282 you hand it off to a client. 45:00.282 --> 45:02.740 Or if you're internal, it's not something you just be like, 45:02.740 --> 45:05.320 I'm done, I sort of use these tools and I'm set. 45:05.320 --> 45:07.570 You have to keep monitoring it, and see how things do. 45:07.570 --> 45:11.110 When new browsers come out, they may be 45:11.110 --> 45:12.450 better or worse at performance. 45:12.450 --> 45:14.320 You never know, may do different things. 45:14.320 --> 45:16.882 So you want to keep on top of it the same way 45:16.882 --> 45:18.840 you would keep on top of any of your operations 45:18.840 --> 45:22.030 or how things are performing. 45:22.030 --> 45:26.782 And last but not least, in terms of tools, is mod_pagespeed. 45:26.782 --> 45:28.240 This is something that you can just 45:28.240 --> 45:29.700 have a server admin turn on, and it 45:29.700 --> 45:32.680 takes care of a whole lot of the stuff 45:32.680 --> 45:37.780 that you would normally take care of with Gulp or Grunt. 45:37.780 --> 45:40.140 It'll convert images for you, it will do cache, 45:40.140 --> 45:43.550 it will do in-lining your CSS for you 45:43.550 --> 45:45.620 to get a faster page render time, things 45:45.620 --> 45:47.430 you don't have to think about. 45:47.430 --> 45:49.490 The good is you don't have to think about it, 45:49.490 --> 45:51.220 and it's kind of just always running. 45:51.220 --> 45:56.137 The bad is it can be-- I found it to be kind of annoying 45:56.137 --> 45:57.720 on the cache side, where you just have 45:57.720 --> 46:00.800 to try to clear things out. 46:00.800 --> 46:04.970 And then also, I mean, it's not as intelligent as you would be, 46:04.970 --> 46:07.200 in terms of what the trade-offs are. 46:07.200 --> 46:11.140 It's just going to kind of go in and do stuff, and kind of 46:11.140 --> 46:13.280 cross your fingers and hope that it all works. 46:13.280 --> 46:15.300 So it's great because it's automated. 46:15.300 --> 46:19.720 The flip side is its automated. 46:19.720 --> 46:20.660 So devices. 46:20.660 --> 46:22.620 Finally, to think about what we have 46:22.620 --> 46:27.339 in terms of how devices can work well together, 46:27.339 --> 46:29.380 and how we can actually get our hands on devices. 46:29.380 --> 46:33.430 Because this is the ideal, is to actually test, not 46:33.430 --> 46:35.050 just in a browser in Chrome DevTools 46:35.050 --> 46:36.660 to see how performance is running, 46:36.660 --> 46:39.840 or to use WebPagetest and kind of hope 46:39.840 --> 46:41.610 that all that stuff is set up correctly. 46:41.610 --> 46:43.401 It's to actually have a device in your hand 46:43.401 --> 46:45.550 that's connected to a network, and to actually 46:45.550 --> 46:47.430 be able to see things, edit things, and see 46:47.430 --> 46:49.360 how the performance is running. 46:49.360 --> 46:52.910 Because you'll have access to all the same Chrome dev tools 46:52.910 --> 46:55.030 that you would on a desktop, you'd 46:55.030 --> 46:59.577 have that access with a remote device as well. 46:59.577 --> 47:01.410 So one of the things you want to think about 47:01.410 --> 47:04.610 is how can you slow things down if you happen to have a device, 47:04.610 --> 47:05.570 locally? 47:05.570 --> 47:07.220 And you have two options. 47:07.220 --> 47:09.090 On Windows you probably want to end up 47:09.090 --> 47:12.660 using Charles, which is a HTTP proxy. 47:12.660 --> 47:15.070 So you can set up, basically say, hey, 47:15.070 --> 47:16.570 slow down all my network connections 47:16.570 --> 47:19.200 to like a 3G speed or slower. 47:19.200 --> 47:21.670 Muck around with latency, all that kind of good stuff. 47:21.670 --> 47:23.140 So on a local device in your hand, 47:23.140 --> 47:26.550 you can start mimicking poor network performance, 47:26.550 --> 47:29.030 even if you have great network performance. 47:29.030 --> 47:30.510 If you're on a Mac you can actually 47:30.510 --> 47:31.880 use Network Link Conditioner. 47:31.880 --> 47:38.140 It's actually a tool that's on the Mac Developer CD setup. 47:38.140 --> 47:41.120 And you can install that if you have the Mac Developer Tools. 47:41.120 --> 47:44.090 And that way, again, locally on your own machine 47:44.090 --> 47:46.700 you can start mucking around with network connections 47:46.700 --> 47:49.412 and seeing how network connections affect 47:49.412 --> 47:50.120 your performance. 47:50.120 --> 47:51.950 And it has a bunch of built-in profiles. 47:51.950 --> 47:55.160 So this is a 3G connection with a 200 milli-- or 300-- 47:55.160 --> 47:57.780 probably 350 millisecond latency. 47:57.780 --> 47:58.345 What happens? 47:58.345 --> 48:00.890 And it gives you a really great idea of locally, 48:00.890 --> 48:01.730 of what's going on. 48:04.280 --> 48:06.200 Jason Grigsby, hate to go back to him again, 48:06.200 --> 48:08.340 but-- Jason did a really good write-up, 48:08.340 --> 48:10.950 in terms of setting up Charles Proxy for iOS apps. 48:10.950 --> 48:14.160 But the basic instructions that are there work for Windows, 48:14.160 --> 48:16.280 work for Mac, and explain how you 48:16.280 --> 48:18.580 can go about using it-- using Charles Proxy. 48:20.905 --> 48:22.280 And if you want to get your hands 48:22.280 --> 48:26.780 on real devices, eBay-- mobilekarma.com, 48:26.780 --> 48:29.240 I know this works really well in the States, we use it. 48:29.240 --> 48:31.950 Basically it's a reseller of older devices. 48:31.950 --> 48:33.882 You're never gonna get the latest, greatest, 48:33.882 --> 48:36.090 but-- it's a reseller of devices you can actually get 48:36.090 --> 48:39.180 your hands on for very cheap. 48:39.180 --> 48:41.570 Again, in the States, cell phone store leftovers. 48:41.570 --> 48:43.280 But finally, open device labs. 48:43.280 --> 48:46.720 And this is where you guys are massively lucky. 48:46.720 --> 48:50.640 You actually have an open device lab here in Amsterdam. 48:50.640 --> 48:52.860 It's got 39 devices, Front Lab. 48:52.860 --> 48:56.300 So if you're like, hey, I want to go test something, 48:56.300 --> 48:57.030 it's there. 48:57.030 --> 49:00.120 It's open for you to go ahead and go use. 49:00.120 --> 49:03.511 And there's eight other open device labs in the Netherlands 49:03.511 --> 49:04.010 alone. 49:04.010 --> 49:05.820 So you can go ahead and figure that out. 49:05.820 --> 49:07.860 And they're all over Europe, It's 49:07.860 --> 49:09.360 a really big movement here in Europe 49:09.360 --> 49:11.800 where people are being great and sharing devices. 49:11.800 --> 49:14.744 And not only do you get this chance to kind of go and use 49:14.744 --> 49:16.160 the device, but it's also a chance 49:16.160 --> 49:19.090 to go network with other people and learn, hey, maybe some tips 49:19.090 --> 49:19.700 and tricks. 49:19.700 --> 49:22.860 If you have a problem, they can go on a device, 49:22.860 --> 49:24.840 maybe they'll be able to help you out. 49:24.840 --> 49:27.300 So it's a good way of-- kind of a geek coffee shop. 49:27.300 --> 49:29.340 Congregate, figure out what's going on. 49:29.340 --> 49:32.435 So, again, Front Lab here has 39-- a massive device 49:32.435 --> 49:33.530 lab, 39 devices. 49:36.120 --> 49:39.200 At least that's what they list, so I hope they still have it. 49:39.200 --> 49:43.660 So summing it all up, on this massive talk, 49:43.660 --> 49:46.490 all the various things that you can do with web performance. 49:46.490 --> 49:49.010 Definitely open conversations with a client or with a team, 49:49.010 --> 49:53.640 using performance budget right from the get-go on a project. 49:53.640 --> 49:55.430 That gets you in that mindset and culture 49:55.430 --> 49:57.890 of thinking about performance from the start. 49:57.890 --> 49:59.740 At the same time, you would say to a client, 49:59.740 --> 50:02.430 we're going to be a snazzy website with these brand 50:02.430 --> 50:04.070 colors, you can say, and we're going 50:04.070 --> 50:07.410 to beat your competitor by 25%. 50:07.410 --> 50:11.320 And it's something you can add on as part of your-- 50:11.320 --> 50:13.570 your project. 50:13.570 --> 50:15.140 First render speed is probably more 50:15.140 --> 50:16.964 important than pure resource size. 50:16.964 --> 50:18.880 So if you're going to be focusing on anything, 50:18.880 --> 50:20.838 I would definitely focus on getting page render 50:20.838 --> 50:23.740 as fast as you can-- the initial page render as fast 50:23.740 --> 50:25.970 as you can to show a user that something actually 50:25.970 --> 50:27.070 is happening. 50:27.070 --> 50:29.030 And the rest of it can all be deferred. 50:29.030 --> 50:30.800 You can still have a massive web page, 50:30.800 --> 50:34.890 just make sure stuff loads somewhat quickly 50:34.890 --> 50:36.610 on the front end. 50:36.610 --> 50:38.679 Try as much as you can to integrate performance 50:38.679 --> 50:39.470 into your workflow. 50:39.470 --> 50:42.430 Again, this comes down to, I think, a task runner 50:42.430 --> 50:44.700 has just become the thing that you have to use. 50:44.700 --> 50:47.910 No matter-- I'm on the back end more so than anything, 50:47.910 --> 50:50.660 and I still use a task runner to make my life easier. 50:50.660 --> 50:54.320 But also to take care of these kind of manual tasks 50:54.320 --> 50:57.739 that, I think, is what stops us from doing these things 50:57.739 --> 50:58.530 in the first place. 50:58.530 --> 51:00.110 And it's why we always try to push them off to the end, 51:00.110 --> 51:01.280 because they are a test. 51:01.280 --> 51:04.490 To minify a file is annoying. 51:04.490 --> 51:07.355 It used to be like, you had to have this Yahoo thing to do it, 51:07.355 --> 51:10.970 and it was-- Yahoo-- YUI Compressor. 51:10.970 --> 51:14.590 And now you can actually make that, just as your project, 51:14.590 --> 51:16.260 every time you run the project. 51:16.260 --> 51:19.010 Every time you update a file, it gets minified. 51:19.010 --> 51:22.390 So definitely integrate that performance into your workflow. 51:22.390 --> 51:25.610 Test, evaluate, and most importantly, monitor. 51:25.610 --> 51:27.361 It's not just a matter of having done that 51:27.361 --> 51:28.901 during the development phase, but you 51:28.901 --> 51:30.880 want to make sure as new browsers come out, 51:30.880 --> 51:35.320 as new features come out, as you get traffic from new places, 51:35.320 --> 51:39.090 they're optimizing your performance as best as you can. 51:39.090 --> 51:42.610 So some performance tweeps to follow. 51:42.610 --> 51:43.590 Definitely Ilya. 51:43.590 --> 51:46.360 Steve is in the crowd, or was in the crowd. 51:46.360 --> 51:49.510 Andy Davies, I think, is a fantastic follow. 51:49.510 --> 51:53.610 He shares amazing amount of great stuff. 51:53.610 --> 51:56.110 Tam(my) Everts and Pat Meenan also 51:56.110 --> 51:57.860 would be good people to follow on Twitter, 51:57.860 --> 51:59.592 if you're on the Twitters. 51:59.592 --> 52:01.990 And so, with all that, thank you very much for listening. 52:01.990 --> 52:04.406 I appreciate you guys learning more about web performance. 52:04.406 --> 52:07.166 [APPLAUSE] 52:10.875 --> 52:12.490 Almost forgot my microphone. 52:12.490 --> 52:14.300 Right, well, your talk over-ran a bit 52:14.300 --> 52:16.090 so I'm going to revoke your chill-out lounge privileges. 52:16.090 --> 52:16.840 Oh, that's fine. 52:16.840 --> 52:18.680 But we will do one question. 52:18.680 --> 52:19.390 What's there? 52:19.390 --> 52:20.450 Okay, we'll do this one. 52:20.450 --> 52:23.066 So of all the performance advice you 52:23.066 --> 52:29.180 gave there, how does HTTP 2 change things? 52:29.180 --> 52:31.696 Ah, jeez. 52:31.696 --> 52:33.196 It's a short question, so I presume 52:33.196 --> 52:34.487 it'll be a short answer, right? 52:37.280 --> 52:38.840 It will change things massively. 52:38.840 --> 52:43.165 And I think, for the short term, focus on the old tech, 52:43.165 --> 52:46.180 because you're still delivering to the old tech. 52:46.180 --> 52:49.924 And just keep doing-- the other things that are going on now, 52:49.924 --> 52:51.840 I think all the tools are changing so quickly, 52:51.840 --> 52:55.050 just get the basics right first, and then worry 52:55.050 --> 52:56.450 about stuff after the fact. 52:56.450 --> 52:56.950 Cool. 52:56.950 --> 52:58.010 I know lots of you had questions, 52:58.010 --> 53:00.551 but we're going into a break and it'll be lunch time as well. 53:00.551 --> 53:02.320 So bother Dave with your questions then. 53:02.320 --> 53:03.090 Dave Olsen! 53:03.090 --> 53:04.940 Thank you.