 Hi everyone, my name is Paul Irish I am a performance engineer working on developer tooling for Chrome, and I'm Elizabeth Sweeney I'm a product manager working on developer insights products on the web platform in Chrome So today our goal is to make sure that we can all measure optimize and monitor our site speed like pros Yep And we're not here to espouse best practices just for the sake of it, right? But we know you know performance sites are profitable sites and that's the core of it So we know it can be difficult to know where to start and there are a lot of things that can torpedo your ability to make your sites fast That's right. So we came up with a blueprint for your performance success And before we dive in let's remind ourselves just how important site speed is Yeah, I love this no, I do not like this. No, this is terrible, but I know something even worse Yeah, like hello like web page. Just give me a paint. Please. Yeah, show me something. We know it's bad But just how bad is this? The impact on user experience is not minimal But in fact the speed that it takes for a page to load is revealed to be the most important factor in a user's mobile experience It's more important than how easy it is to find what they want It's more important than the simplicity of using the site and interestingly enough It is three times more important than what a site looks like. So the takeaway is performance is critical. Yeah And we know that's hard to believe but we actually are that impatient I promise when overall page load time goes from one to three seconds The probability of bounce increases by 32% and when you go from one to ten seconds Then that nine second Delta increases your chance of bounce by a hundred and twenty three percent Wow So yeah, like Elizabeth said this isn't just about speed for the sake of speed although like you know as developers It does feel really good to get a nice TTI or a nice FCP feels good But that investment that we make as developers on site speed can have direct impacts on business success That's absolutely right and we've seen these investments pay off time and time again for our partners when Pinterest revamped their mobile web experience to focus on performance they saw an uplift in both user and send user sentiment and Engagement and that net effect was a 44% increase in their revenue Their website is now their top platform for signups tinder at their implementing and enforcing an aggressive performance budget Now sees more swipes on the web than they do on their mobile app So we'll be yes, we'll be talking more about how performance budgets come into the equation a little bit later But over and over again, we see the exact same pattern those who know how to design and implement fast sites Get more Satisfaction from their users higher conversion rates more time spent on pages and more higher revenue Okay, so all this is great But it is difficult to know like where to start and how to prioritize when you're trying to improve your site speed So we created this blueprint to set up teams for performance success. So within this blueprint. We have 15 Recommended actions for you starting from kind of the very basics scaling up to what we would consider to be a very mature web performance culture So let's make sure that we all start on even footing What are the things that absolutely everybody should feel comfortable about these are the table stakes for performance? We start with wanting to know the current status of our page Are we doing well? Are we doing poorly and you can get this snapshot by using the page speed insights web app You can run any url through the tool and it'll provide you with both the lab and field data Necessary to benchmark your pages speed and I want to take a minute to break down the elements of what you get back in that report First you see the score gauge at the very top of the report And this is a high-level indication of how your page is doing It's the same score as you'd find in lighthouse and the score is calculated with weighted performance metrics that lighthouse measures Including things like first contentful paint and time to interactive What's really special about the PSI tool is that it provides you with both lab and field data in one fell swoop The field data is sourced from the chrome user experience report or crux Which I'll be talking about a little bit more later and the lab data Including both the performance metrics as well as the opportunities and diagnostics that you see beneath it Those are all powered by lighthouse so You get the same results that you would from lighthouse within the dev tools audit panel for instance But it's running on our servers instead of your local machine So action to is okay I saw what page speed insights told me about and gave me some suggestions and I want to go try those out Implement those suggestions on my machine. So I'm gonna need to kind of like iterate a little bit So now it makes sense to kind of go to your local hosts your development environment open up dev tools and here you open up the audits panel So you're faced with something like this and then you can get off to the races and try it out And actually since it's well since it's the IO talk We did have some changes some new stuff. So we actually shipped a brand new version of lighthouse version 5.0 today And there's some new features That we're gonna talk about Yeah, one of those was mentioned actually yesterday in the keynote. It's called lighthouse stack packs Stack packs are really cool. It's a feature that allows Lighthouse to include specific recommendations based on the stack that you're using so lighthouse detects What kind of platform what software your site is built on and instead of just surfacing just the generalized recommendation? We add additional messages that are just for you in that platform We're working closely with the community to make sure that all the Recommendations are coming from experts that know this stuff and make sure that the advice is tailored to the platform The first stack back is for WordPress. That's available today. You'll see that in page speed insights You'll see that in crump canary and as new ones are created by community experts. We'll be getting those in So hold on a minute. Can we go back because that looks new with the logo the report? Yeah, that's true. Yeah, some new stuff Okay, so I'll get into that. All right, so some of the new stuff. We got a new kind of refresh lighthouse UI We want to make sure with the report that it's clear and actionable So we've done a UX and visual refresh just to prioritize the right data So you'll see this new design on page speed insights. You'll see in crump canary next week It's good stuff Also, we okay, we had to kind of like hop on the hype train for one feature I mean it is arguably the must-have feature of any modern UI in 2019 Dark mode. Oh, yeah. Oh, yeah, we just had to oh Thank you. Oh Yeah, dark mode. It's good. It's good. It's nice You can flip it on in the menu in the top right and also we do that cool thing with like you set the Operating system preferences and that media query and it you know had to do it. So Okay, anyways, sorry, you can go back. So you're telling me we get stack packs and a new UI with dark mode Yeah, okay, so that's all great, but on to action 3 It's great to get a snapshot of your field data in PSI But you want to see how your site actually evolves over time So as we mentioned before briefly before the chrome user experience report provides user experience metrics for how real-world chrome users Experience popular destinations on the web It is a data set that is powered by real users and the metrics collected are aggregated anonymously from users who have opted in as of this past month the data set coverage has expanded over five million Origins and if you don't see field data for an origin yet Just know that it's it's coming because we're always working to expand our origin coverage and the crux dashboard built by this fine gentleman over here Rick Viskomi allows you to better understand how an origins performance evolves It's built on data studio and it automatically syncs with the latest data sets and can be easily customized and customized and shared with your Team online. So right now you're seeing FCP being drilled down into but you can easily go more in depth into other field metrics Or things like proportion of device usage and network connection types All right action for is we want to quantify The experience that users are having on our site for this is we're just going to dig into the metrics and understanding What's going on these definitions of these metrics? Loading is well actually comes right from the W3C spec for paint timing load is not a single moment in time It's an experience that no one metric can fully capture So there's multiple moments that really contribute to Quantifying what that experience is like. We've talked about some of these metrics previously Things like first content full paint time to interactive the first input delay These are great metrics and really do a good job of capturing capturing some things But we wanted to introduce you to kind of the new kids on the block There's a few metrics that are in development and I wanted to introduce them to you today So the first one is layout stability And to explain this Yeah, best to start with the example now Elizabeth and I we made this made this website It's a cute cat and wants to be clicked on Good, and I certainly can but the other day I actually had to add some monetization to the site But I did and unfortunately I didn't do it in a nice way And so you might try and click on it and but like an ad and then it shifts it down and you know when this happens It's so annoying So like it might be ads but it might just be you know an image lots of things can kind of move things around as the page loads And it's frustrating, you know as users when it moves around Layout stability is a metric that's all about quantifying this experience taking a look at the elements their dimensions and their movements And putting that into a score There's a bunch more details, but you can read about read about them in this explainer here The second metric that I want to introduce you to is not first contentful paint, but largest So the largest contentful paint here. Well, you know in this load we start out blank Just the text and then finally this image finish is downloading. That's good. Usually if it's like the big image We call it the hero image the hero content, right? And so in this case we're interested in this moment in time when the big Content is done now. This content may be an image. It may be text And there's a few things to figure out there So in the explainer for this one you can see a little bit some of the details there So there's a big section on what is largest how do we quantify that? Figuring out what contentful means figuring out paint so for instance figuring out the details with Foreground images versus background images with text handling web fonts things like that So the details are in there. You can you can dig into that again These are metrics that are still in development, but you'll be seen more and be more about these soon All right. Wow. Okay So before we go any further when we want to take a brief respite and examine a Taxonomy of speed tooling Yes, that's nice So we're gonna cover a few talks a few tools turn this talk and all these tools make sense For different situations, but one thing I just want to make clear is that they're all based on the same core engine and using the same data Sources so in particular most lab Most lab tools are powered by lighthouse At the base whereas web perf API's and Chrome usage statistics are what powers pretty much all field data Rum solutions things like that All right, so that captures kind of the performance basics Let's move on to the good stuff some of the more intermediate Items, so we're getting to these third. Sorry the the second of three blueprints the plumbing These are professional performance techniques And actually for step five I'd like to do some more hold hold on you skipped a step Step five we just did four. No, there's there's one in between There's a Yeah, it's four and three quarters, and it's one of the most important three quarters obvious So if you don't have buy-in from all of your stakeholders that the speed is important and that it's not just your best friend But it's everybody's best friend Everything else in the blueprint kind of becomes a moot point and people get excited about the shiniest new feature and Performance gets put on the back burner. We've all been there So this means that you want to make sure that you have support from all ports of parts of your organization to execute against the performance that Blueprint that we're sharing with you today There's nothing more painful than having to layer performance on top of a fundamentally non-performance site That's just it's it's painful But this can be seen in how organizations often design their web apps performance is not their thought and often it only becomes a priority in the heat of an emergency so Users are complaining businesses are losing money and then panic ensues But like we said earlier performance at the end of the day is about solving business problems and Understanding that the conversations we need to increase conversions and we need to lower our FCP are effectively the same Conversation is a really good way to get both business and engineering stakeholders excited about solving problems that lend themselves towards increasing quality for your users Okay, now you can introduce Amir. Oh great. All right, everyone. Please welcome Amir Rahm engineer on the Google search console Thanks Paul Hi, everyone. My name is Amir and for those of you who don't know Search console is a tool that gives you insight into how your website is performing on Google search What queries being users to a site how many users see your website in the search results? How many click-through and so on? It also provides reports on your website's coverage on the Google search index as well as help you fix any issues You might have relating to search features like AMP or structured data But getting users to a site is not enough like you've just heard faster means more conversions So with search console we want to help website owners provide users with an amazing experience that loads fast and keeps the bounce rate slow That's why I'm happy to announce that we've been working on a new speed report for search console Still in beta, but today we'll take a sneak peek at the new report Now this report is pivoted around field metrics So that's first content for paint and first input delay based on the core user experience report data And the goal here is to get an overview of how all the pages in your website are doing based on real user measurements then zooming in on a particular metric and device that's problematic and Getting example pages for me's getting examples from misbehaving pages and then taking those examples Fixing them iterating on them with developer tools like light house and paid speed insights. So let's take a look So what you see here is the breakdown for the Google developer website based on actual user measurements aggregated over the last 28 days and The first thing you see here is that we classify all the URLs into three buckets slow average and fast So right off the top you can get an overview of how your site is doing on a per URL basis So for developer site, we have about 4,000 slow URLs about 33,000 average pages and 800 fast pages and We classify you a page as slow if it's considered slow on any metric on either desktop or mobile So if you have a page that has slow first input delay, for example on mobile It'll come stores a slow bucket even if the other metrics are doing well. So that's kind of a stick definition Fast URLs are fast on all metrics across all devices. So that's a really good place to be and The rest of your pages are labeled average and that's usually the biggest bucket as you can see here Now under the summary account, you can see an overtime graph of these performance buckets So you can get a feel of the trend of you the trend of your speed performance over the last three months This is where you'll see the effects of any performance fixes you implement as they reach actual users so now that you know how your website is doing we can drill down to a specific issue and Because we know it's unrealistic to fix an entire website in one go We really wanted to help website owners figure out where to spend the resources when fixing speed issues So with the speed report, we're also introducing page grouping Instead of just a list of URLs We take all the pages in your site and group them with pages that have a similar experience and that we think will have the same underlying technical issues This way if your issue is caused by a common template or a slow resource you can fix them all at once You can see that each URL here actually represents a bunch of similar URLs and we aggregate the performance metric for the entire group So in this example for the first page group It has about a 1000 URLs and an aggregated first content for pain value of 3.2 seconds And if you click on one of those you can see more examples of pages in that group this allows you to focus on the pages you care about the most and For a developer site we have for example a page group for all the pages describing structured data items you can implement on your site and All of these pages they have a similar structure And it's very likely that the technical issues will be the same with the same or similar on all of these to config them all in one go and After you decide on what effects it's time to take the examples here back to developer tools like paid-speed insights And you can see there's like a direct link to paid-speed insights in the panel for the URL you selected and either in on a fix using a lab data and When you're done you can come back to search console and see the effects of your fix on you see the effects of your fix on your website as a whole And that's it so as I've said this report is still being better tested But you can but you can help you can sign up to register and for the beta in this link We'll be adding more participants over the next few weeks and As always we appreciate any feedback you have and if you've never used search console of any questions We should have visited us in the sandbox area to get a demo of search console in action And with that I'll bring it back to Elizabeth and Paul. Thank you. All right. Thank you, Amir So we are so excited by the speed report and new features like being able to dissect the crux data by page groupings Like that's super cool And what's great is that by step six we are comfortable with what we want to be measuring We know what speed metrics we want to be tracking both in the lab and in the field And what tools we want to use to do so but we still haven't defined success So my TTI is seven seconds. Am I happy about this? I don't really know because we haven't set our goals yet So it's time to define a performance budget And you are in control and able to define what budget feels reasonable for your team However setting reasonably aggressive goals will allow you to maintain optimal performance When new features are introduced as the team changes and when day-to-day priorities Devour your bandwidth, which we know happens all the time So there are three kinds of budgets that you can set including resource quantity like the weight of your JavaScript or the number of network requests Milestone or metric budgets like a maximum threshold for your interactivity or load metrics or score budgets based on lighthouse and Just for the record if you set a score budget that is a hundred for all of your audit categories I bow to you and more power to you Just know that there's an awesome Easter egg in there somewhere, but you didn't hear it from me Don't tell them about the fireworks. I made him say it They look cool So just an hour ago during the speed at scale talk Katie and addy went into depth about incorporating performance budgets into your workflow And we're so excited to have lighthouse's new performance budgeting feature light wallet announced this IO Lighthouse now supports your resource quantity budgets within the report UI itself So that you and your team can evaluate how well your site is performing against the goals that you've set To get started you define a budget file this example sets a budget of a hundred and twenty five kilobytes For all scripts 50 for all style sheets and 35 network requests total Then you use your budget in lighthouse by passing the budget path flag followed by the path to your budget file in order to Calculate whenever categories over budget, and if you're not sure where to start you can check out Katie's performance budget Calculator to give you a good sense of what a good default budget is for you and your team based on your goals All right action seven you want to diagnose Specific aspects of what in particular is affecting page load, and I think I remember this is the Dev tools performance panel Yeah, my buddy. I like performance panel. There's some good stuff I mean in the performance panel we're all about getting into the details and really in order to show kind of what this is about You should do a demo do do I have to yeah? Okay, I'll do a demo All right Cool, so what we're gonna look at is the wiki pt page for cat great little page, and I want to understand How it loads So what we're gonna do is first? It's gonna start it off from about blank and hit record. This is a non-throttle run by the way But we'll just keep it easy All right, I navigate I hit stop That seems good. All right, so a lot of things going on here, right? We got all this stuff down here But really I'm just interested in when we get that content on the top of the screen So I'm just gonna kind of scrub in the top and see okay. Yeah, well the Looks like The icons on the top and the logo were a little late to come in we have the content pretty early So I'll just select that area. Oh wow, okay in this case like none of that stuff on the main thread was even there So what we have is we have this network track and then the main thread one thing that kind of I notice is This little gap In the middle and what what happens is we have the HTML downloading over here And then our endpoint is actually here It's that first paint first contentful paint first meaningful paint all on the exact same point in time And in fact we can open up frames just to see exactly what the screen looked like at that point All right So Why did we have this gap here on the main thread? Well, I don't know it's kind of interesting. So we finish the HTML download, right? They were parsing the HTML here. We parse again over here, but here main threads not doing really anything Looks like we're downloading some images Downloading a script, but the priority is low. So that means it's not render blocking So that shouldn't be a problem But the purple is style sheet priority of highest and highest indicates that it's render blocking And so what happened is we download the HTML But then we find a render blocking style sheet. So we got to go fetch that Then we once that finishes Then you see we come down here and we finish parsing the rest of the HTML We recalculate style layout paint and then pretty soon we finish it off So this is kind of cool and in fact it's interesting because Wikipedia has one of the best web performance teams that there is But still like even they have an opportunity They could take the styles that are in this style sheet kind of critical CSS thing Take them and inline them in the HTML would win them, you know in this case Something around 30 milliseconds is on my unthrottled run But there's a lot of opportunities That's probably where I'd start and then afterwards I'd start to get into what is happening in the main thread over here Because it looks like there might be some opportunities for improvement So that's what we can do with the DevTools Perf panel Back to our slides I guess And as much as we'd all like to we can't sit our entire lives in front of DevTools Rerunning lighthouse over and over again as ideal as a scenario as that sounds So we're at the point where we need to automate as much of our performance story as possible And that's where production monitoring comes in There are a lot of third-party production monitoring solutions that are built on top of Lighthouse's engine As Paul mentioned earlier a lot of the web performance tools that you see are based on the same core technologies and data And I really like that production monitoring can be done with web.dev's measure tool and the API that it runs on PageSpeed Insights v5 API with web.dev You're able to run Lighthouse and track your pages performance over time as well as other audit categories like accessibility and search engine Optimization when you run Lighthouse within web.dev you can easily find the guidance that you need to optimize your site's performance That's one of the joys of it is that it marries documentation with tooling so stay tuned for more feature buildouts there If you plan on using the PSI API in an automated way with regularly scheduled queries You can get an API key at the URL here And it's a great way to scale your monitoring over multiple pages or origins and by default The API runs just the performance category and on desktop But you can adjust it for mobile and expand it to include the other Lighthouse categories as well And you can get crux data from the API to so if you're looking to build out your own production monitoring solution This is a really great place to start So at this point we need some more details on the user behavior that's on the site And there's a lot of great solutions for this, but I wanted to call out one in particular It was launched just yesterday And that is the new web performance monitoring solution from Firebase There's some really good stuff in there and since there weren't so many details yesterday I want to show a little bit of what it looks like in the real experience So this is what you'll see in kind of the dashboard that welcomes you We see a bunch of key performance metrics in the full distribution of those measurements from all of your users And that's really nice because in other tools like Google Analytics, you only get like that one average number And it's not very indicative of what is happening to all of your users So it's great to get the full picture here You also see metrics like first content full paint and first input delay in there too And then you can also dig into some of these metrics look at what in particular one See how they change over time and then pivot the data based on a few different variables. It's cool That is really cool But now you know how to and where to collect field and lab data in aggregate and on a page level And how to compare how you've performed over time against your benchmarks But how are you doing in relationship to your competition? Here we recommend that you leverage the full power of crux with big query to dig really deeply into the data sets Not only can you compare one competitors metrics, but you can compare all competitors across the board within an industry to see where you fall And you can visit the crux github repo to discover useful recipes for extracting insights And also if you have a recipe that you like submit a pr and share it with everybody So you have your foundation and now you have your plumbing, but there's something missing I can take a shower, but I can't turn on the lights Showing the dark Obviously Got to do that. Okay. So now for the stuff that can really light up your world. Okay. I can't help myself so This part of the blueprint for performance success is one of the most valuable things that you can do Being able to correlate the speed with which your users interact With your site and your conversion bounce and engagement rates is a goldmine of insight There are a few steps to get started with this drawing this graph is the one first one But step one actually is to choose representative pages that you can track and compare over time And this is between both your business and your performance metrics with this in place Then you can reasonably evaluate the correlations of your top performance and business metrics to one another over time This will eventually allow you to estimate the impact of a new feature prior to deployment and this is on your revenue and Quote the cost of a feature implementation during design So by now at this point, you've surely noticed that the third parties on your site are bringing you some performance pain So we need to sort that out There's a few tools here. I wanted to shout out request map Gives you a nice view of your third party situation their network costs their dependencies And if you're interested in the web skill impact of third parties check out third party web This was actually built by one of the core lighthouse engineers patrick hulse, and it summarizes the runtime cost The javascript cost of third parties across the web It's really helpful for just like comparing different competitors in a space Based on what sort of impact they're going to have to your web pages performance And it's also cool because the data behind it is all completely open source In addition, uh, ultimately solving your third party situation requires working as a team So one recommendation is bringing together representatives from different parts of the company and kind of establishing Uh a shared goal. We are going to make Faster web pages at that point you can then review, you know all the third party tags together Understand what their perf impact is and evaluate, you know, what's absolutely required and and what we can do about things All right action 13 Your site you may feel is not like other sites and you might want to define performance success That is completely custom to you for example on um on me and elizabeth's Cat site. Well, what is success? Uh Time to first cat time to first cat. Yeah We want this kitty cat in front of the user as soon as possible. So let's create a custom metric for that all right cool This is a new api, uh, just kind of on the way out But you can put on an element timing attribute on the image tag And then you'll set up a performance observer, uh, which down at the last line you observe element entry types Uh, and then inside the callback you get data and you get a timestamp that represents not when that image was Finished downloading but when it was rendered to the screen With that difference can be significant and important. So now we have yeah our time to first cat pretty cool Uh element element timing is currently in an origin trial. So this is kind of cool. You just go It looks kind of scary, but it's it's really straightforward sign up the form say which origins you want to use it on and You put in like a header or a meta tag and you're good to go All right, and with a custom perf metric, you know what you want to measure That's awesome time to first cat fantastic But we're on action 14 and this is a mere one step away from being like performance pros So we need to automate the measurement of your custom kpis and in lighthouse We just kind of taking a step back and taking stock of this We really try to make sure that the audits we incorporate into the core report itself are universally actionable and impactful for all developers Regardless of their tech stack what browser they're in or their industry So we know there are valuable audits though that are entirely valid for use cases that don't necessarily meet the criteria for universal applicability And we want to leverage the power of lighthouse as a platform to measure what you care most about And that's why i'm happy to announce for the first time lighthouse plugins It's a brand new feature that allows domain experts like yourselves to extend the functionality of lighthouse for your specific needs At its core a lighthouse plugin is a node module that implements a set of checks That will be run by lighthouse and added to the report as a new category The google ad speed team created lighthouse's first plugin which is already available for cli users And this plugin seeks to provide ad managers with detailed actionable recommendations to improve ads loading on their web pages Soon we will be supporting selecting which plugins you want to run via our ui itself So that you can easily share the functionality that you've built with other lighthouse users To learn more about lighthouse plugins check out our plugin handbook in the lighthouse github repo And okay i'm excited. Yeah, we're almost there And we're what's the last action to becoming a master of performance Well, i'm glad you asked so When you're developing at least when i'm developing i want to know for each and every pull request If that's going to impact my tti if that's going to make things two seconds slower or two seconds faster I want to know that before the pull request is merged into master and then deployed out live, right? So implementing performance measurement in continuous integration is one of the most robust methods that you can employ To defend against regressions uh in fact The fantastic web performance team at wikipedia recently blogged about their success using a combination of both rum data and lab performance tooling in ci Here they were seeing their first paint numbers Rising in their rum data and they didn't have a good explanation for it But they have a really robust ci setup and they were able to see what was actually happening in fact As users were switching over to chrome 69 the numbers went up quite a bit They investigated this uh and filed some bugs with chromium team and we also were like Yeah, we also noticed this too and there was a change in how things were measured But this gave a lot more confidence as far as what is happening in the performance so that they know in this case They weren't at fault. It was a change on our side Um We're excited. We want to make sure that you have the confidence to know how each and every change that you make Impacts your web performance. So we're working on a new project. It's called lighthouse ci And lighthouse ci is going to be really cool, but it is early. It's all open source though It's on github. You can look it up the curious people can certainly take a look And we're excited about making sure that you have some of this more control and data to understand how things move And you're telling me now that I can get lighthouse pre-prod and posts. Yep. That's cool. That's good All right. So that takes care of the last blueprint. So All right, so I'm going to recommend the next few slides our phones out slides If you would like to get summaries of stuff. It's the full summary. Yeah, that's nice. I can do better than that one Oh, yeah I can give you the tools. Yeah, that's good. That's a good one. I I I'd totally photo snap that So we know it's hard to know which tools to use when and for what purpose but as paul said earlier You know, most of them are built on the same foundation So each one brings its own valley proposition But remember you're kind of all building off the same same thing So this toolbox can be seen as everything you need in order to implement your blueprint for performance success We really want to have your step your back every step of the way But do you know unfortunately for uh step four and a half? Oh four and a half. Can we go back a second? Yeah, because you are gonna have to bring your own whiskey But can I just get some whiskey you can help me out with maybe I'd be great. I would love it. All right Here are all of the links that we shared over the course of the entire presentation just curated for ease of reference good stuff And uh, that's it Thank you