/I/O BootCamp 2011: Optimizing your Web Performance for Success

I/O BootCamp 2011: Optimizing your Web Performance for Success

Video: I/O BootCamp 2011: Optimizing your Web Performance for Success

Subtitles

>> RABBAT: Hi and welcome all to Bootcamp, IO Bootcamp. Today we'll be talking about optimizing web performance for success. My co-presenters are Andrew Oates and Shawn Ligocki. I'M Richard Rabbat. And we will be taking turns. But first agenda, I will be motivating why one needs to pay attention to speed, motivating it obviously by revenue. Everybody is very interested in making money on the web.

Then Andrew will be talking about a new API that we're releasing today which is the Page Speed Online API. He will have a really cool demo about it. And finally, Shawn will be presenting mod_pagespeed which is an Apache module that allows you to speed up your webpages automatically. So performance equals revenue. Let's talk a little bit about what's been happening with webpages over the past few months. This is data from HTTP Archive. I picked the data about images as well as JavaScript transfer size. And from November of last year through March of this year images–images on webpages have gone bigger. There's more images and they are getting bigger. These are for the–about 10,000 like top webpages on the web [INDISTINCT] over 10,000. If you look at the JavaScript it's also slowly growing into–in terms of the amount of JavaScript that your browser has to interpret and execute.

Obviously, pages are–on the web are getting richer. The Pickle Page that used to have a little bit of HTML and some nice style sheet is now a much more complex web application. And one needs to pay attention to the performance of these pages because they directly relate to how people approach and use the web, more data from HTTP Archive that was released over a month ago. If we look at things that we need to pay attention to when optimizing webpages, the–we can correlate that with the load time. And if you look at column number 3, for example, total requests are a direct–almost a direct correlation with the load time. And there's two pieces that you should always pay attention to, which is the image transfer size. It has a very good correlation with the load time of the page. As well as at the end, the JavaScript request, they're very well correlated with the page load time.

So when somebody pays attention to optimization of images as well as JavaScript, that helps a lot directly in speeding up your webpages. And how does load time impact success? Here's some data from several websites out there. Amazon.com did a study where they saw for every hundredth millisecond latency decrease, they would increase their revenue by 1%. You can imagine that the scale of Amazon.com, that's quite a bit of money. Edmunds.com worked with us last year. They were working on optimizing their webpages. They used Page Speed to look at how they can optimize their pages and this resulted to about 50% load time, load time decrease. The impact on this was about 17% page views per session. And who wouldn't want to increase their pages? This is by focusing on speed alone. Strangeloop Networks which builds boxes that allow you to optimize webpages on the fly.

Did some analysis on consumer behavior and they looked at like the consumer behavior of a three second delay on what would happen? And for 100 consumer visits, three second delays would make sure that about–little bit under 60% of people will just drop off and leave your website. About 50% of them will not return to your website. And that's very important. And worse than this, they're going to tell others not to go to your website. So paying attention to speed is critical for–to your success on the web. So I'd like to welcome Andrew to talk about Page Speed Online API. >> OATES: Thanks. Hi, I'm Andrew Oates. I work on the Page Speed Team based out of Cambridge. And I'm going to talk about the brand new Page Speed Online API. So first, a little bit of background of the Page Speed Project. Page Speed is a tool that helps web developers speed up their websites by applying sort of well known web performance best practices.

We launched in 2008 originally as a Firefox Extension. And then in 2009, we released the Page Speed SDK which lets you sort of build tools on top of the Page Speed library. Then most recently, we launched the Chrome Extension and Page Speed Online. And so the way Page Speed work is we have a collection of rules. Each of which encapsulates a single best practice. Something like minifying your resources or optimizing your images or doing asynchronous patches. By one sort of piece of consistent feedback we've gotten from developers is that they want a way to run the Page Speed analysis on their sites and get back sort of an easy to consume machine readable format and do this really easy without having to load up a browser and script it or to do a compile against the SDK. And so that's what we're launching today. It's a new online API that lets you do that.

How does it work? It's super simple. So you can see it at the top, you the developer make a simple HTTP request to our servers. Give us a URL to fetch, we will go out and fetch and render that URL, then run the Page Speed library on it and then give you back the results in sort of a standard JSON format. So here's an example. The top is just a URL you might fetch from. So googleapis.com/pagespeedonline/v1/runpagespeed, URL equals–give a URL and then the key equals your developer keys. So if you've worked with Google APIs before, you're familiar with the developer keys. Based with a token that you used to authenticate your request and lets you control and track your usage. And I also have little Python snippet here that illustrates how you could use it in a language. The response looks like this, standard JSON. We have the URL you passed in, a response code and title. We give you the Page Speed score.

So if you're not familiar with Page Speed, the Page Speed scores and numbers, 0 to 100, it basically says "How well are you doing?" Low score is bad. You have a lot of room for improvement and a high score is good. You're, you know, applying lots of the best practices that we know about. We're using stats about your webpage and then down in this format results block, we have a chunk for each rule that we apply. So avoid bad requests, I guess, google.com didn't have any bad requests. So we got a hundred on that. And then this, you know, continues on, past the bottom of the slide. So that's all of my slides. Let's do a demo because that's what we're all here about. All right. So first, let's just take a look at the request response. So I'll take it out. So here we're going to run Page Speed on www.google.

com and that's my developer key, don't steal it. And here's the result. All right. So we fetch it, we got a 200, still get a 99 from when I made the slide. And you can see here these–all those rules I was telling you about. So avoid bad requests, avoid CSS import, defer parsing of JavaScript, et cetera and looks like here's one that we fail, Minify HTML. So we get 99 on. That's still pretty good. And then we have these sort of chunks that let you format this. So this will be great if you're building a tool to present to the users. And actually if you use Page Speed Online or any of the Page Speed products, we use this exact same API and sort of various forms internally. So you can build the same tools that we have. We're also launching with the 40 language support. So let say locale=korean.

Oh, and hey avoid, bad request. That's how you say avoid bad request in Korean, I guess, I don't speak Korean. So now, I'm going to show you a quick demo of how you could use this in your development environment. So I put together a little website, "Andrew's vacation photos." And it's my vacation photos. Really simple, has some images on them, since CSS. Let's take a look at what it looks like. Well, it's five images but I really care about web performance. I want people who come to see my vacation photos to have a really snappy experience. So I have the script, I call it push_and_test.py. And basically what it does is it lets me push a new version of the site to App Engine, this is hosted on App Engine. And then tested to an AV comparison against the old version and see what's changed.

So you can–don't worry about the push version script, that does some fancy stuff with hashes in the App Engine environment. And now I have this function test URL that basically, it reads the webpage and counts number of image tags and make sure that it's greater than two. So let's give this a shot. Push_and_test.py. Ah, and there were no changes. Testing, okay, great. Now let's see how we can integrate the Page Speed tool with this. So is that a function? If you don't know Python, you should be able to follow along. Anyways it's pretty simple. GetPageSpeedResults, taken a target URL, it's the URL of the site we want to analyze. So let's split up our URL parameters. Target_url and my developer key, which I don't remember. So you can get this if you go to the APIs console. Just sign up. Enable Page Speed Online API and we're live right now. And you can get your own developer key and then try this out. All right. So now to construct our URL.

So we want https://www.googleapis.com/pagespeedonline/v1/runpagespeed which is the only thing we can do. And then we're just going to encode that URL parameters as a string. All right. Let's fetch that URL, and then let's parse it to JSON. So I like Python a lot because you can do this pretty easily. Load string response. All right. So you can see, I have two URLs here: andrews-vacation-photos and 0.latest.andrews-vacation-photos. I'll explain that the next time we're waiting for App Engine. So, let's get our Page Speed results for both of those. Analyzing old page, stable URL. Analyzing the new page and lets do test URL. And we can delete this old stuff. All right. So let's just make sure this will work. And let's print out the results that we get. And let's give it a shot. And like the old page, analyzing the new page and that looks like JSON, awesome. You notice it takes a few seconds because we have to fetch the page and render it and do all this analysis on it.

So now let's look at the Page Speed score. So let's say if the old result's score is greater than the new result score, score decreased, it's a hard word. And then we'll print the old results and the new results. Otherwise, we're doing okay. We haven't introduced any regressions. And let's print the page we'd score for good measure. Old results, all right. Oh, new results. Thank you. Feel free to speak up if I screw up. All right. Analyze the old page, new page, okay. Page Speed score 84. Okay. So I have some room for improvement. But I haven't introduced any problems which is true because I haven't made any changes. So let's make a change. Let's say I want to adjust my site up with some jQuery and I have it comment it out here because I can't remember the URL.

So we're going to load from the Google hosted version. If you've used it before you might notice I'm not loading the minified version, that's my mistake. And we'll see why in a second. Type rules. And let's say whenever you mouse over an image, let's give it a red boarder because I like gaudy things. [INDISTINCT]. All right. Let's push and test. Okay, so here's the App Engine magic. So App Engine lets you upload multiple versions of a site. So I'm using that to my advantage here because I'm uploading one version but keeping the old version around. And then I can do an AV comparison. That does an exponential back up. Okay? Analyzing old page, analyzing new page, score decreased 84 to 74. Lets just double check and make sure that its doing what I think its doing. Refresh. Yes, that's working, for some definition of working. Score decreased 84 to 74. So in this case, it's pretty simple to figure what I did wrong.

READ  Texas Lawmaker: Jail Women For Abortions!

I only added one chunk, right? But let's say I did a really complex change and I want to–I want to know more about what's going, so I can do that. So let's go back to the script, okay. So let's add a new function. Let's call it compare results. It's the old results, new results, and as you saw briefly, we give the results, they're formatted and then we have the structure called rule results which is a dictionary which map from rule names to result blocks, so we add it for the new and the old. All right, so now, let's say, for every page speed rule in the old one–in the old results and I was going to assume that the page speed library didn't change between these two implications. It's a fair assumption for this demo. Let's say if the old–get the result block and let's say rule score, so we also assign the score to each rule, is the gray of them, the same thing in the new results block that means of this rule, the score is decreased, so it's a pretty good bet that this is the chain that's causing a problem. Let's print a rule is triggered.

And then let's give the localized name of the rule, so if you were–if you're making this–if you're making this tool to publish for instance, you could the grab the locale out of–from the client and they would see these strings, well, not the strings you're writing but any page with strings they would see in whichever the locale you choose. All right, I think that will work. All right, so if old results score, grade a new results scores, let's also do compare results, old results, new results. All right, cross your fingers. And there's old and there's new score, decreased 84-74, rule triggered Defer parsing of JavaScript and Minify JavaScript. Okay, so some of you do a JavaScript. Let's say that I only have a few minutes. I really want to fix something, which one of these is more important.

Well, page speed can tell us. We also sign something called an impact to each rule. So basically, the score will tell you how badly did you do on this rule. So you get a zero on a rule, right? That means that you're doing really badly on it but if it only affects one teeny tiny part of your page, you probably don't care that much. There could be another rule that you did okay on, maybe got a 75 but it affects a large portion of your page and you will get a lot more out of fixing that and that's what the impact means. So let's add the impact here. So we know which one–what we want to fix. It's going to run over in my line, so new rule results, get the rule and rule impact. And all of this is documented.

You can just stick in and play around and take a look at it, they're also all documented on the code site. So let's try again, oops, will that change? Did I not close my bracket? Well, that's odd, I think let's try this in a four set push new version again and see, so let's check to make sure it's–hey, it's still doing the add jQuery thing. So we say caching headers on the page speed responses, so if there was weird cache in between page speed and me right now that might–there we go, perfect. Okay, score decrease 84-74. Rules triggered Defer parsing JavaScript, impact 1.0 whatever. Minify JavaScript impact 9.3. Okay, so Minify JavaScript has a lot more impact on my page in deferring parsing event. So let's focus on fixing that. So let's edit, index I can move back up I forgot to use minified version.

Fortunately, I can just add that. So minification, if you don't know, is basically process of removing anything extra, so your JavaScript file will have, you know, comments in white space, that aren't necessarily the [INDISTINCT] JavaScript, but necessary for reading it, so when you minify, you strip all that out and you can make your page run a lot faster or the resource load a lot faster. Now, let's run it and see what happens. It's going to push again, waiting two seconds, four seconds and this is really a simple example, so we're designing this so people can build page speed like tools. Okay, page speed score 86, so we fixed the problem. You also notice the score, it's a little cut off, that's okay. The score went up a little bit. The reason for that is we made our page heavier. We got–we added a whole bunch of JavaScript to it and so as a result any deficiencies that we have before sort of matter less of the grand scheme of things that's why our page speed score went by a few points. And so that's an example of how in just a few minutes, we–I integrated the API, build this regression testing tool that will help me catch these performance bugs, you know, maybe I would have launched the site without realizing it.

I would have–two months later found out that I've been losing traffic because of this regression. All right, let's go back to presentation. We lost our place. So we're launching us today, you can go try that now. Also launching today is W3 Total Caches is adding Integration with us, so here's the screen shot that the [INDISTINCT] cache on us, showing–this is the exact same UI that we have in all of our page speed products. We integrated it with the page speed online API and just inserted it right into this performance dash board. And that's a sort of–that's a sort of part of integration and tools we want to encourage with this. It's basically lower the barrier to entry to using the page speed library in a tools and work flows and a lot of the good stuff.

If you want to learn more, that's a giant Q, our code for our docs. as well as the actual URL and the goo.goalurl you can scan that in and get started right away and that's all I have. Going to hand it off to Shawn who will talk about mod_pagespeed. >> LIGOCKI: Hey, how are you guys doing? I'm Shawn Ligocki and I'll be talking about mod_pagespeed. Now–mod_pagespeed is–the idea is to automate some of these rules–these page speed best practices on a server so that you don't have to do it yourself. Right now it's the Apache Web server plug in and it reverts your HTML and your resources and it's an open source product. You might ask, "Why do I need to use mod_pagespeed?" Can't I just implement all these optimizations myself? And there's a couple of reasons you might want have something automated but one of them is that a number of these things specifically I'm going to be talking about leveraging browser caching and combining images into CSS sprites can be kind of difficult to do and specifically to maintain if you do them yourself.

And so to talk about this little bit, I'm going to go in some detail about why you want to do it in the first place. So the first one is our extend cache filter and this is–the basic idea here is you have a cache so by default, your cache lifetime for most resources is going to be that five minutes. And here's an example of what happens. This is the initial request the user makes to your website and this is going to be covering a single resource so one image on your site, one CSS file. And then here's the response that comes back and you can see kind of response, there's a lot of content there because it's a whole image or whole CSS file. And then if your user then goes ahead and visits the site again, maybe let's say four minutes later, they're actually going to make no request all the way to the server because they still have the resource cache in their browser.

But if they go visit let's say six minutes later, they're going to have to go and ping your server and say this resource is [INDISTINCT] out of the cache, is it still good and your server has to response back saying, yup it's still good, 304 not modified. And this kind of repeats forever as they come to visit your site again and again over the next, you know, minutes, hours, days, each time they visit after five minutes is going to have another response. And you might say, you know, this is just a really simple request response. It should be really short but it's a whole round trip which can, you know, be tens, hundreds of milliseconds and as Richard pointed out, there can be, you know, 50 images, hundreds of resources on your site if each one has these round trips, it's expensive. And so–and the best practice is to have longer caching lifetimes. So what if you just set your cache lifetime to one year? You know it looks great, right? I mean, you know, you have–there's nothing, you load it the first time, you have to and there's–you never have to go connect the server again.

And you know, it sounds perfect except of course–what if you ever changed that file? And if you change it, just say like 13 minutes after, you know, the user visit the first time. They might not notice for another year as it stays in their browser cache, you know, probably less than that but maybe like, you know, week, a day and anything like that, you–that whole time if your JavaScript, let's say you fixed an error in it or you updated the versions of your JavaScripts, now they're going to be out of date. So most people when they–when they put cache headers on their files, they put reasonably short cache headers and the reason is that now let's say here's the–again the five minutes, you know, sure you're doing these pings every once in a while, this time the ping really matters.

This time the ping tells you, you should really update your request and download the new resource. So a question you might want to know is, "Well, can we get both?" Can we get the best of both worlds, so that we don't have to keep pinging the server when the thing's not updated. But we can ping it and get the actual results. Get the new updated resource when it is updated and that's exactly what we've done in mod_pagespeed. So for the whole that it hasn't been updated, you don't do anything and then finally, when it has been updated, you go ahead and ping the server get the new response back and get the updated resource. So that's sounds great, how do you do it? We're going to go all detail here.

If this is the original thing, it's just an image, walrus.png and now when we rewrite it with my pagespeed, we're going to change the URL. We're going to add–specifically you're going to note hash code here, just the 91_www and that's md5 hash of the content of the file. And so every time this file changes, you're going to have a different URL and so it's going to tell the browser you have to update. And so now, you can see that we can add, you know, this is the original cache lifetime, we waited five minutes to be–have as much control over our website as possible. And now we can extend that out to be a whole year long. And whenever the file changes, you know, here's the new–here's the new hash code automatically when you load the new HTML file, where you're going to get the new resource, the new image, the new CSS. And that's how we can avoid all these extra checks but still get it updated after you updated your resource.

Another example I'm going to cover is a spraying images. The idea here is that if you have, you know, probably multiple images on your site. Richard showed that the average site has 50 images on each site. So here we just have an example with three. Each one of these, you're going to have to make a request out to the server and a response back, that's a roundtrip and then get the results and another request out, response back at the results. And in addition each time, the user visits the site again after some number of–some time past the caching date, it's going to have to make this again three roundtrips for each of the images or 50 roundtrips if you have 50 images. So you'd like to be able to just get rid of all the extra roundtrips to say I want to request all the images and get them all back. And then each time I can just make a single ping to say, you know, is this still up to date. And that's exactly what we do except in addition of course, we also cache extend it and so you don't even have to do those extra pings until the images actually change.

READ  Many Hands Working Together | The Supremes Cartoons | Nursery Rhymes & Songs For Babies - Kids TV

And how do you do this? Well, in this case, you know, here, let's say this is the original page, this is the original CSS file and you have, you have these two PNGs here in different backgrounds. And now when you–we've written the page, you have them both come out together into a single URL, it's repeated twice here. That's one, you know, resource is going to be loaded and each of these have offsets to show you–to tell the CSS which one to show. And so, you know, this is the original images, these are just the two images put together. And we do the same thing with CSS files and JavaScript files to be able to combine them to reduce the number of roundtrips that we need to make to the server. Great. So this is some of the motivation for why you want to install a mod pagespeed, why you want to automatically rewrite your web pages, and so here's a little information about how you could install it. If you're using Go Daddy or DreamHost basic hosting, it's actually already provided.

All you need to do is sign up with clicking a little check box or putting in a small configuration file and you can test it out. If you're using CentoS or Ubuntu there is binary downloads you can put into the package manager, it'll automatically update themselves. And of course it's also open source so it's available by–you build from–oops, you can build from source using instruction on the website. In addition, as soon as you download it, it will already start rewriting your webpage in a way that we think are both safe and really useful for your site. So it has kind of a core set of filters enabled to rewrite your site. But in addition, we provide lots of configurability, you can do number of things, you know, simple things like turning web page speed off so you can just do it for testing. You can change the default instead rewrite level to more conservative or liberal levels.

And you can turn on and off individual rewrite passes to do things like removing comments to spreading images, things like that. There's some more detailed configuration options you can do. If you're one of the–a big help that mod pagespeed can provide is rewriting images if you have large images that are represented in small size in your webpage, you can really resize those. And even if they are the same size, often you'll have extra information that's unnecessary so we can run through opt PNG, another optimization software to reduce the size of the images. But that's kind of an–it can be CPU intensive so you can reduce–you can set the number of images to be rewritten at the same time. And there's other things you can set up to pinging your local architectures. Great.

Let's say–so now that you've installed mod pagespeed, you might want to know how do I really know that it's helping my page. And this is what we love to get your feedback and see how it's working for you guys. And we have two examples that we're suggesting for how you can go and check this. And the first one is Page Speed Online, it's the tool that Andrew's team released a couple of months ago. And you just go to the website and input your URL and it tells you what the page speed score for your site and some suggestions that you want to follow. And so by using that before and after, you can get some feel how much is it actually implementing those decisions, is it improving your page speed score. And addition you probably want to know how much is it actually speeding up your site. And so webpage test is a nice website that allows you to actually go and load using an IE browser in a real location along cable modem or something like that.

And to actually see how long it takes for the page to load, how–you can see the waterfall diagrams and all the details about it. And so I'm going to cover–I'm going to actually through and demo some of these to show you how you can test this. So here's Page Speed Online and in this case, we're going to be testing one of our user sites which is Androidacademy and we're going to set it first to get a baseline with page speed turned off. [PAUSE] Great. And so here you can see that, you know, the page speed score is 69. And here they have some examples of things that you might want to do on the website to make it faster. So specifically here, I noticed, you know, it's leverage browser caching and combining which is CCS sprites and these two other things I just mentioned that–one page we can help you with and in addition there's also a yellow one for inline small CSS files which we also do.

So now we go ahead and let's say we can open this in a new window so we can compare them and let's try loading just a page with no [INDISTINCT] so that we get the actual mod page speed version. And–great. [PAUSE] So, as you could see, I mean, this increased all the way to 79 points, it's up 10 points which is almost, you know, 15% to 20% and in addition, the leverage browser caching is down to a yellow item. The inline CSS is gone. You'll notice that that combine images of the CSS sprites is still here. You might ask me why is that I just mentioned it, inline images in CSS sprites is a new feature that we're releasing. We haven't worked all the details yet and we haven't suggested people's turn on yet. So that's kind of an example of something that we can still be working on for the site to provide value to it.

And for the leverage browser caching, so, you know, you might say, "Well, we reduced it from, you know, a red item to a yellow item but it's still on there. Why is it on there?" if we could just leverage all the browser caching. But if we look at this a little bit we can see, glancing at this, there's maybe 15 or 20 of these guys. It seems like that's kind of a lot, you know, things we haven't been able to increase the cache lifetime on. But look at the original one, it's actually like, you know, 40 to 50 maybe 100 of these. There's quite a number. And so we've made a significant improvement. Each of these again is like a roundtrip when you visit the site again. And so reducing it, you know, from 100 down to 20 is 80% improvement of that kind of load time in some ways. In addition–probably what's happening here for these why these aren't being inlined, they're probably something in an ajax poll or a JavaScript that's–we can't find when we're rewriting the page.

And if that's the case then it's probably actually not so bad because if they're in an ajax call, that's probably after the pages are reloaded and so it's not going to impede sort of using the page that they're not cache extended, might be a pretty good thing. So–so, yeah, here you can–you can go back and look for some reason, you can compare these as one way of seeing your optimization were. But–another example–but you might say your mod pagespeed of course, you're going to improve the page speed score, what does that really tell me? And so it's, you know, another good example to go check out is webpage test which like I mentioned. We'll actually go and load this page from a real browser. You can choose whether you want to load it from IE, from Chrome, and there's a number of different locations, you can pick one where you think your users is going to be or test different locations in the U.

S. and internationally. And specifically we'd suggest if you're doing this, you up the number of runs, because one run doesn't give you very good statistical significance. You could have a bad run, bad network things like that. And so we'd, you know, suggest you up it to about 10 which is the maximum. And to see it will tell you all the different runs. You can see the distribution of it and it will all specifically point out so the median–the median time which is kind of what your average you usually see. I'm not going to run this one live because there's kind of a queue for waiting for this and so it could take, you know, maybe 10, 20 minutes to run through. But I have some examples saved here. This is also from Android Academy. Here's the before, and as you can see at the top here, we have a bunch of metrics about load times, start render, first [INDISTINCT], things like that, and the number of request size.

And if we look down here, we can see the waterfall diagrams. And the first one here is–is the initial load, and the second one here is the return load. You can see there's less resources, I know it's all hard to see because it's in little pages. Less resource loaded this time. All the yellow ones are the ones I was mentioning earlier. This is–when you just ping the server and it says, the resource hasn't changed, so in some ways, it's all but wasted and you can see that it actually takes quite a bit of time to do all those yellow responses. And you go through these 10 responses here. This is the after words. And if we just glance down, add some of these results, we can see that, let's say, this repeat view is much more. And you know, presumably, what we've done here is eliminate all these pings we have to make back to the server for these sub–sub-resources by extending their cache lifetimes.

And so, now you know–and you can see specifically, it's not just from the image but the actual hard numbers here. There's 42 requests made on the repeat view, after we turned on one Page Speed. And if you go back to the original one with mod pagespeed off, there's 95. So, it's less than half of the number of requests, and that can make a big difference. And you know it's not just the number of requests. If you look at the start rendered time here, it's 3.2 seconds, afterwards it's 1.2 seconds, I mean, it's even less than half the time to first, get the first paint on the screen and let your user know that something is happening. And the finish time here, afterwards is 3.6 seconds, before it was 6.1, again about half the time. So, is this you know–it's actually–it's pretty significant change in–in how much loading time if you have used, I mean, back again to your site. And so–and so, we'd love to hear, you guys telling us about how–if you–if you get a chance to install this on your site and to run through some of these tests and see how it works for you, how it improves your sites, et cetera.

And if you'd like more information, all things–kind of the center for all things, Page Speed, so the URL appears, it comes with a search for us. In addition, we'll be having sort of office hours down in Pub Lounge which is right down at the bottom of the stairs, take a left, where people were eating lunch today. We'll be there until 6:00 P.M. for one on one. And in addition, if you're interested in these topics, if you check out there is two talks tomorrow at Google IO, Josh Marantz, giving one on Mod Page Speed, tomorrow at 11:30, and Bryan McQuade is giving one on "Page Speed for Mobile Browsers," and that's going to be in the afternoon, 3:45. >> OATES: So actually, I have a second demo that we weren't going to do but we have time, more for it, we have about 20 minutes. So I'm going to show you the advanced features of the Page-Speed Online API.

READ  BREAKING NEWS !!! Blackberry KeyOne will receives Android Oreo Soon

And by advanced, I mean, everything that's left. And I'm going to attempt to build an entire Page Speed tool in the next 15 minutes and you guys can help. Yeah, whoever that was, thank you. All right, so let's take a look at–let's take a look at what the–the results look like. So, before we were just looking at the rule names, but as you can see–where is that rule thing? So, as you can see, we have a lot more than just a rule name here, right? We have a rule score, and impact, there's URL blocks, and there's header, and the format, and these args. Basically this is what we use in Page Speed Online, and Page Seed Chrome, and Page Speed Firefox to construct the actual UI. And it's really simple. How it works is this, we have, um, these format strings. The following external resources have smaller response [INDISTINCT] in line with the resources–that's a bad example.

Let's do this one, "$1 should inline the following small resources:" and then we have, oh, yeah, an argument, "type": "URL" "value" that. So, basically as a developer, you can just stick in this, this URL in the place for the dollar one. Is there are better example? And what that lets you do is–here we go. So here's the list of resources that have–that don't have–that don't have cache left times. So, I mean, $1 and a $2. $1 is the URL, Andrews vacation photos, media, photo1. That's the shells, I think. And then the duration, 10 minutes. And what–this lets you do by giving me this flexible format. It lets you format things differently. So, for instance in Page Speed Online, what we do is we take these URL arguments and we turn them into links. These are–can click on to go to a different thing. And I think we bold durations or we italicize them or something like that. So, it's a really flexible format, um, so let's extend our script to use these.

So, let's just do a–what's it called? Print–let's just do print results, so let's take in some page PrintResults and I'll print them out in a flexible format. So, and again it's what you leverage our [INDISTINCT] language support so that your users all over the world can–can see this in the language of their choice–the locale of their choice. All right, so, let's see. This is–okay, so we're going to get the rule results from, as we did before. Results equal–equals results–format results. The same thing we did up top there. And for every rule in the Rule Results–let's just print out a header. Rule Results–rule LocalizedRuleName. PrintResults, let's just print out whatever the new results are. Push and test, oops, analyzing old, analyzing new. Okay, list of rule names. Let's augment that. So, I'm actually going to just comment this out for now. We're just going to print the–the Page Speed results.

And we have–we're going to have Snippets, examples posted online for JavaScript and Pythons–some other common languages for how to–how to do these things. All right, so, if you look at–this is my save version in case the Internet broke. If you look at this Rule Result Block, we have the name of the rule there, a localized rule name in these urlBlocks thing, and when the URL block sees–it's chunks of URLs that are related. So, for instance, you might have one urlBlock per redirect chain. You would say, this redirect chain should be eliminated. This redirect chain should be eliminated and so on and so forth. So for urlBlock in Rule Results, rule urlBlocks–so let's just printout the header. Oops, this is the danger of a live demo, that has not been rehearsed.

urlBlocks header. For urlBlock, end rule, results rule, urlBlocks. Are there any Python gurus who want to pipe up and tell me what I'm doing wrong? >> [INDISTINCT]. >> OATES: Oh, yeah, there we–well, that's–that's a possibility. Well, let's test and see if urlBlocks. There we go. Thank you, Bryan. So, let's–let's do some more interesting page, actually. Let's do it on, news.google.com. And again, bear with me, [PAUSE] this is a little by the seat of my pants. Okay. [PAUSE] Bryan, this is my manager Bryan, he's helping me up. >> Actually we need [INDISTINCT]. >> Oh, yeah, yeah, yeah, yeah. Say that, again? >> [INDISTINCT] >> OATES: Bingo. "Analyzing," there we go. Okay.

So, you can see if which one of these headers we have a "format" which is the string. And we optionally have some "args." So, let's write a little function to fill that in, "FillFormatString." Let's just call it "header," "if," somebody just beeped at me. Oh, it's right on time. [PAUSE] All right otherwise, "for" each "argument" "in" the "header" and this is pretty [INDISTINCT]. We have examples of this online. [PAUSE] There we go. I already have this written. This felt familiar. Oops, all right. "FillFormatString (format_string_dictionary)." So, [INDISTINCT] instead of putting in the "header," let's print out, "FillFormatString" "header." Let's see what that looks like. Oops. "Analyzing page," "Analyzing page.

" [PAUSE] Isn't it fun watching people debug? All right. "If "args" not in format_string_dictionary: return format_string_dictionary['format']." Cross your fingers for me. Damn, "args = format_string." This is clearly buggy code. [PAUSE] "(format_string_dictionary['args']): out = sub(i+1) args[i], out) return out." Well, then this is on 108, 98, 82. [PAUSE] On hash, we'll type "dictionary." "FillFormatString(url_block), 170, thank you. [PAUSE] What was there again? The high calibrated Google Engineers illustrated in front of everyone, 170. All right, we got sub, "args," this is infuriating. Oh, right. So, we have a type in a value for each of these. This needs to be the value.

Oops, let's see if that works. And there we go. Okay, awesome. That was harder than it should have been. It's going to be so smooth now. All right, "Minifying the following JavaScripts resources could reduce their size by 2.3 kilobytes (0% reduction). So, it worked. So, let's indent that. All right, now let's look at the results and dig down a little further. So, in this URL block, we have the header. And then we also have optionally this list of URLs here. Each one of these has a result. And the result is the exact same format as the header. So, "if 'urls' in url_block: for url in url_block['urls']." There's a better way to do this on Python but I'm not going to bother with that right now, "if 'result' in url: print "1, 2, 3, 4, 5" why not?"+ FillFormatString(url['result'])" Knock on wood.

There we go. So, "The following cacheable resources have a short freshness lifetime. Specify expiration at least one week in the future for the following resources." And if we reach this, we give a URL and that. All right, there's one more step, as our indentation gets further and further, "if 'details' in url: for detail in url['details']: print "1, 2, 3, 4, 5, 6, 7" + FillFormatString(detail)," "push_and_test," "Analyzing," looks good. Let's do one more thing instead of doing that URL. Let's take it in from "argv," "(argv[1])." Because now we're going to "push_and_test," give me a URL, anyone. Let's do Android Academy, www.androidacademy.com. Drum roll, takes a while, "Analyzing," and there we go. Page speed results, I did that in 8 minutes.

You can do better, I'm sure. Thank you. >> RABBAT: Please join here back. So, we're all–so, Shawn and Andrew was showing you many simulations of what your page speed would be like webpage test is a nice simulation of what your webpage latency would be. Last week on Thursday, Google analytics announced that now if you have Google Analytics on your site and you add one line to your site, we actually collect your site speed and show it to you in the dashboard, in the Google Analytics dashboard. And that will be a great help for you as you see the real world at, you know, client side latency that you expect, that you want to see as opposed to, you know, the several size where webpage test servers are or some localized–localized pages.

So, we have a few minutes if you have any questions, please go ahead. >> Yes. >> RABBAT: Yes. >> So, we can view this online at page speed–that was page speed [INDISTINCT] in different sites which are only the way to a certain rules. And then you get [INDISTINCT] users with your page speed to work. Some elements are just [INDISTINCT]. >> OATES: So, for page speed to online specifically, we actually don't take the amount of the number or seconds that it takes to load the page into account. One for page speed online, it's Google loading in it. And Google has a lot of fast Internet connections so it wouldn't be a representative. For another thing, our focus–so, there are tools that have to do that. For instance, web page test is, sort of a full solution.

And it will give you stats for the actual page load time. But for… >> LIGOCKI: And you can, and you can go ahead and load that from trying–they have servers all over the world. >> OATES: Yes. So, for page speed itself, we're focused more on what, sort of, irrespective of this like connect–the actual connection you're on. You know, how, what kind of server you're running if you did have more boxes on the backend. What can you do on the client side for these development best practices to speed up your site? >> LIGOCKI: Although you still also have specific rules for mobile sites, fort his specific different way to weigh things. >> OATES: Yes, yes. So, one thing we launched recently with page speed online and Brian and Levo are going to talk about this at IO tomorrow is new specific new page speed rules. So, Mobile's obviously a big growing space and phone connections are really slow.

There's–and RTTs will be in the order of seconds instead of milliseconds. And so every connection you save, every request can have a huge impact on your site in terms of views, revenue, etc. And so we launched a new, some new rules in the mobile space to help people optimize with the situations. >> RABBAT: Any more questions? Yes. >> [INDISTINCT] >> LIGOCKI: Yes. So, lot of what we were looking at right now, and we're testing this is how do we choose which images we should be spreading together and how we should be doing this. And in general right now, we're focusing mostly on images that are already in the CSS, already in–written in CSS. And so what that means is you foreground images listed in the image tag, those are more likely to be probably important user experience to load early.

If you can combine a bunch of very small images that are like part of your Chrome, your rounded corners, little smiley faces, things like that, that can be helpful. And it might not even actually slow down the load of the whole thing. >> OATES: And for like a lot of these things, it's a trade off, right? >> LIGOCKI: Yes. >> OATES: If–different connection types have different characteristics, you might have a really, something like a 3G or a 4G connection on a phone, can have actually a fair amount bandwidth but really high RTTs, really high latency. In that case, if you can just dump everything down with one request, you'll save a lot of time rather than having to go back and forth to the server for each one of those small images.

And so finding where that trade off is, is sort of, an important part of the process. >> RABBAT: Okay. All right, well thank you very much. And we hope you enjoy the rest of IO Boot Camp..