 All right. Welcome, everybody. Thanks for sticking around during lunchtime. We're going to talk about some cool, cool stuff. Talk about Lighthouse and how you can build seaworthy progressive web apps for the web. So my name is Eric Bidelman. This is Brendan Kenney. We are both on the Develop Relations team at Google, where you focus on Chrome and web. And we basically just give presentations, help developers use web technologies, build tools, build libraries, build things like Lighthouse that hopefully will make your life easier. The fun fact about me is that I'm from Michigan. So I point to where I'm from on my hand, go blue. And Michigan actually self-proclaims to have the most number of Lighthouses of any state in the country. So you're basically never going to run into any shoreline in Michigan because we are well, well protected. Fun fact about Brendan is that he wrote this really, really cool demo back in, what, like 2010? Yeah. And it uses, what, CSS2D Transforms? 2D Transforms. Why does it use 3D? You only had 3D on the iPhone at the time. Everybody else was still stuck in the 2D version. 2010, not a lot of support for GPU and awesome stuff like that. But there's this really cool part here where you click this button, it says, don't click. And of course, when you do, there's this inception moment. We got really excited about this. And we actually hired Brendan because we saw this demo. I have done some things since 2010 right now. Well, speaking of, we both actually work on Santa Tracker every year. This is something that launches on Google.com. It's kind of fun. It uses, it's a PWA. It uses all the latest web technologies. So it's Polymer web components. It's got a service worker. There's these games that launch every kind of day. This is one of my favorites where you can actually give Santa a little shave. And he's totally cool with it. He's Santa. He's a jelly guy. That's Santa's gift to you. That's brutal. Let him give you a. But that's a fun one. And we do this because we want to not only build, like, real stuff on our team, but we also want to open source it and to have people learn from these apps that we build. But today, we're here to talk to you about Lighthouse. And so Lighthouse is a tool for web developers that helps you improve the quality of your web app, not just PWA, but general web best practices. And it's also for maintaining the quality of your app. Because I think maintenance is actually really important. You want to have the ability to take in poor requests from a community, but also ensure that your app is fast, always stays fast. And it meets the progressive web app requirements. You don't want to be this guy. This was actually me back in January, where I did a push to an App Engine app. My latency rose, like, 2 to 4x, because I was doing way too many database queries. Totally just a boo-boo. It was a mistake. But I fixed it. You can see where the graph went down. But wouldn't it be nice if there was a tool to help us prevent mistakes like this? If only there was a way to automate this. If only there was a way. You've probably also heard about progressive web apps here at I.O. and probably even before that. So let's say you want to take, go down this journey of building a progressive web app. You've probably seen our documentation over on developers.google.com. And essentially, there's just a lot of stuff you have to think about if you want to build a PWA. And it's all kind of just a manual process. You have to serve your site over SSL. You have to have a service worker for offline, and all in that entails. Responsive, add to home screen. Are you fast on 3G? If you actually just go and scroll this page, that's daunting, right? There's just a lot of things that you have to think about. Again, wouldn't it be nice if there was a tool to help us out with some of this stuff? Turns out, tools are nothing new. They've existed for thousands of years in many different industries. We have road science to help us navigate the road and give us information. We have lighthouses to help strips at sea guide and stay away from the coastline. So we said, hey, this is a great model. Why don't we take this and build a tool that does this for web developers? So we kind of reworded the definition of lighthouse for web developers. So lighthouse is a beacon of light that guides web developers. Nothing more, nothing less. It keeps you on the fast path. It allows you to know your site's accessible until you're using best practices, that you're a PWA, and that you're a performant. Last year, Paul Irish, who's sitting in the front row right here, what's up, Paul? It looks so young. Yeah. He actually introduced lighthouse. And back then, we had basically just a bunch of automated checks for progressive web apps. We had a really sweet, fancy logo done in MS Paint, as every alpha project should have at the time. But we've done a lot of work since then. Today, we're talking about Lighthouse 2.0. So a year later, the open source project is still open source, but we have a bunch of new stuff in Lighthouse. So we still have the progressive web app checks. Lighthouse will just go through your site, and we'll demo it in a little second, and tell you what you need to do to be a progressive web app. But we have a ton of other stuff, so best practices. We're already using the latest and greatest best practices on the web. So as the web continues to evolve, Lighthouse will adopt these new practices and then write audits for them. Is your site performant? It's great to have a progressive web app, but if it's not performant, no one's going to come back and use that experience. So we have a ton of new stuff for performance. And lastly, there's a whole section dedicated to accessibility. I'll be the first to admit that I often forget about accessibility when I build things, but no more Lighthouse can basically guide you through this process and tell you what you're missing. We also have a fancy new logo, which is animated, and an awesome new Twitter handle with four underscores. That's really important. Yeah, don't forget that. I don't know why we did that. Anyway, in the first day that we created it, it had more followers than me. That's not fair. Everybody go follow Brendan. But with that, I guess that's enough talk. Let's go ahead and just demo and show off Lighthouse what you get in a Lighthouse report. Yeah, let's try it out. So if we can switch to that, perfect. OK, so if you've been over to the mobile web tent and you'll have seen a giant Lighthouse, and this is the page that runs on it. It's a simple app. You put in a URL in this text box, and it goes and tests your app. So we've done a simulation here. Maybe marketing asked for some tracking scripts, and maybe business dev wanted some extra features here. And as a result, your page load has gotten a little slow. So let's load the page. And I want to use it, so I start typing in a URL. But as you can see, it's still loading, and it just erased my progress, because some JavaScript loaded and made it work. So we want to benchmark this in Lighthouse. The most popular way so far has been through the Lighthouse extension, which is in the Chrome Web Store. And we can go up here, and it's a simple click to get Lighthouse started. It'll actually clear things out, try and load this as a mobile device to the web app, and it refreshes a few times. So it can take a look, like, does it work offline? Does it work with a clear load? How does the accessibility look? And then here you can see the kind of checklist that Eric went through before. So at the top is the Progressive Web App Checklist, how your site is done as a Progressive Web App. And you can see that here's four things that we still need to do. Get a service worker is a big one. Get a service worker is a big one. And maybe work on our security. But we have seven things that we're already doing. So we're doing OK. And we weren't even trying. We're doing some stuff. Yeah. That's good. So next up is the Performance section. And here you can see a great breakdown of some really key metrics that have been talked a bit about at the show so far. And we're going to talk a little bit more about in a little while. But you can see them in context with the screenshots of the page load. And down here, Accessibility. Accessibility is a great one that a lot of people feel like they have to be experts before they even start on making their site properly accessible. But Lighthouse is a great tool to help you get started and just say, hey, make sure you do this. Make sure you do this. And you have a bunch of things you're doing great on so far. Good job. And finally, best practices. Don't use document.write. Make sure your anchors have the proper opener if they're external sites, that sort of thing. OK. So that's Lighthouse and the extension. Super easy. I don't know why anybody would want. So that's a one-button press. You get Lighthouse. You get a lot of information in that. But I'm a power user, right? Maybe I want to tweak some things. Maybe I want to change some of the default settings in Lighthouse. What do you got for us? Yeah. Well, it's funny that you asked Eric, because I have a terminal back here. Oh, why? Just for people like you. So Lighthouse is also a C Light tool. And it's as simple as MPM install, G Lighthouse. And then we can do Lighthouse, you know, test the same demo server. And then I'm going to add, you know, the pro move, adding dash dash view to open up the report. There's a bunch of options here where you can also do things like turn off network throttling, you know, emulate a different device, that sort of thing. So this is just a little note script. It's doing the exact same thing as what the extension was doing. Exact same thing. It's in the background here. You can see Chrome is loaded. And it's going, trying to load the page, running a bunch of audits and tests. And then boom, we got the exact same report. Very cool. C Light tool. Very cool. Okay. So Chrome extension. It's a one button press. I can run it on command line, use it in Node if I'm in that environment. Yeah. Programmatically too, which we'll talk about. Right. What if, you know, I don't really want to install anything. Like is there an even better way I'm working in, you know, as a web developer. Installing things is a lot of work. So if you're a web developer and you already have Chrome Canary installed, you might have heard this week already. Paul Irish covered this this morning. In Chrome Canary right now, you already have DevTools, or you already have Lighthouse in DevTools. So you open up DevTools and you go over here to the audits panel and you can see here's Lighthouse. It's already installed for you. You can do this, run an audit and boom, there you go. That logo follows you everywhere now. Yeah. That's awesome. Yeah. So same thing. Same open source project is running in all three of these different environments and baked now into the Chrome DevTools. Yeah. So if you ever felt like contributing to DevTools, just go, you know, contribute to Lighthouse and it'll get put right into DevTools. That's awesome. You too can have code running there. Yeah. Everybody can have code in DevTools now. Yeah. Awesome. Thank you, Brendan. Okay. So let's switch back over to... Switch back slides. Talk about performance metrics. Those look fancy. Yeah. So you saw some of the performance section in Lighthouse which is something we deeply, deeply care about and many of you probably care about it too. But let's face it, performance is actually really hard and it's hard to maintain performance. Someone submits for a poor requester, comes in and changes something. You don't know if your app is still going to have that level of performance that it once had. So there's some metrics out there, right? You probably have heard of things like window on load and DOM content loaded. These are performance metrics, traditional old-school metrics. Are these good things we should be thinking about in 2017, Brendan? Well, I mean, it really depends. So, you know, maybe window.onload fires about when your page is ready. But maybe, you know, you have a server-side rendered page and you bring in a bunch of JavaScript and onload is actually triggering the handlers that initialize your page and it's going to be another few seconds after that until your page is ready. So it's hard to say whether window.onload really reflects, you know, when your site loads. Again, WebVillum complex. You don't know if you should care about it. Yeah, yeah. What about, so Adios Money always tells me, like, reduce the size of your JavaScript bundle, right? Especially for mobile, you want to parse less code, you want to load less things. Is this something good or bad that we should be considering? Well, it's generally great advice. The more JavaScript you pull down, the longer it takes to parse and eval. On the other hand, sometimes it's a trade-off. Sometimes you want to go for a little size increase for, like, a much larger performance increase. Maybe you're bringing down server-side rendered assets, or maybe you're pre-computing something that would take a long time to do on a phone. So maybe a little bit size increase isn't necessarily a bad thing. It's hard to know. It's hard to make these trade-offs. It's definitely hard to know. So one thing we're focused on in Lighthouse is really raising the elevation of these user performance, user-centric metrics, such as First Paint, First Contentful Paint, First Meaningful Paint, and a new one called Time to Interactive. These are really about the user's experience, not just, like, window on load. Are your images loaded? Are your scripts loaded? It's about what the user perceives during this lifecycle page load. So let's walk through these in context. Do you want to take a shot? Sure. Yeah, so... Oh, yeah, fancy. So, sure, you press Enter, you know, you start navigating your page, and First Paint is really when the first pixel changes on the screen. That could be, you know, background color. That could be something like this, just like some vague structure. Next up is First Contentful Paint, and that's when the actual first content is drawn to screen. It might not be the most important content, but something has actually, you know, appeared in the DOM and been painted to the screen. So next up is First Meaningful Paint, and that's an attempt to actually measure what actually matters to the user. So maybe that's the content of a story. Maybe that's, you know, the search box. That's the kind of primary element of the page. Something that really captures, like, hey, as a user, I'm looking at this and saying, like, okay, this is actually what I came to the site for. So next up is Visually Ready, and then Time Interactive. So just because something's painted on the screen doesn't mean it's actually usable. So we've all been to sites where, you know, everything's ready to go, and then you try and do anything and nothing happens because JavaScript is actually spinning the background or something's still loading. You're typing the input, and then it nukes the input. Exactly, it just nukes it, and then you want to smash the screen. So Time Interactive tries to measure that. It's saying, like, okay, everything's loaded, but now I'm going to look at kind of a bunch of activity that's going on, and when that calms down, when it's actually able to respond to user input, that's when Time Interactive fires. And then finally, you know, you're finished. Fully loaded. Yeah. Ready to go. Yeah. Cool. So this puts the performance part of the Lighthouse report into a little more perspective. You can see all those metrics kind of put into context with the page load, and you can see as the page loads, you know, really early on that page has the full layout of the page, but Time Interactive doesn't fire for quite a while as it takes. A JavaScript bundle. Yeah, it's pretty rough. We also have targets for each of these where we think you should be hitting. So that's really important, too, considering what the metric is that you should be targeting. Okay. So let's say I'm a developer, right? I want to integrate with Lighthouse, right? Maybe I'm already tracking performance metrics, and I want to kind of zest in my performance metrics with those awesome metrics that we just talked about that Lighthouse is giving you. Yeah. Phil and Shibi gave a great talk yesterday. Web performance, something-something. It's a very long title. And they talked a lot about how, you know, these are great metrics. It's really useful to be user-centered. I think about the user experience, but you know your site better than, you know, any, you know, heuristic does. And so if you can go out and measure the exact moment that your hero element's ready, then you should absolutely do it. Yeah. So we can do that by writing a custom audit that plugs into Lighthouse. Okay. So before we do this, let's just, like, get this out of the way. Probably the most boring part of the presentation, which is a little bit of terminology and architecture. Is that okay, Brendan? Yeah. You get to do the boring part. Should I do the boring part? Okay. So in order to understand how Lighthouse works, you kind of have to understand how things are set up. The first is we're just a bunch of node code. And that's the Lighthouse portion at the top there. On top of that, we actually just interface with Chrome and the Chrome DevTools protocol. It's a really awesome set of APIs. Essentially anything the DevTools can do, the API can do as well. So it's super powerful. And this is how we're going to interface with Chrome and write a custom audit. Okay. So we have this Lighthouse runner. That's the kind of controller for Lighthouse. And in this, there's three different things. The first is gatherers. Gatherers are basically just things that collect information from the page. So in some cases, we actually inject JavaScript on the page to evaluate something. And that's what the gatherers are doing. And as you saw in Brendan's demo, Lighthouse actually reloads the page a couple of different times. And that's why we have a couple of different gatherer passes here, because we have to do things like cut off the network, make sure your service worker actually serves something offline, just a bunch of other stuff like that, that we need separate runs for. So gatherers interface with Chrome through this little kind of shim that we created called the driver. And that talks to DevTools protocol. So we're built on the kind of the stack of giants. Everything below us is just DevTools. DevTools protocol is pretty amazing. You can basically do anything you want in Chrome through the DevTools protocol, which means that Lighthouse can do anything you'd need it to do. Lighthouse fires up. It connects to Chrome. It opens a Chrome, and then starts running the page and testing things. So when gatherers are done, they return artifacts. Artifacts then are handed off to an audit. An audit is basically just a pass or fail check or something that applies scoring. So in the report, you see scores, and you see a check and an X if you did bad. Those are what audits are doing. They're returning and evaluating these things. That hands off just a big JSON blob of all the data. And then we go into report generation. And so report is basically just categorizing these things. Here's the progressive web app section. Here's the accessibility section, so on and so forth. So gathering, auditing, and report generation, and that gets you a Lighthouse report. All right. Pretty simple. So with that, we're all on the same page. We can write a custom audit. So yeah, this isn't something that we emphasized a lot before this, but actually since the beginning, we've written Lighthouse to be super extensible, and you could write a plug-in really easily. Because in many ways, Lighthouse is just like a really nice test runner with a bunch of functions already built for those tests to make difficult things pretty easy. So as Eric was saying, there's three steps, and we're going to do all three of these to write our own thing. So this is that demo page. We switched to the demo screen. Do you want to show the metric that we're... Oh, yeah, yeah. So let's switch over. Yeah, I'll do that. Nice. So the developer of this page is actually already thinking about performance. They already feel really guilty that it takes six seconds for that search box to start working, and so they did the basics that they could start with, and they're logging how long it takes to do that, and so we can actually open up DevTools here and go over to the console, and you can see that they're logging this in the console. Five seconds. Just so they can feel guilt every time the page loads. Five seconds? Not very fast for a search box. And they're also saving it to a global variable. They could send this anywhere. They could send it to analytics or something like that. We're going to do the simplest possible thing and just set it to a global variable named site metrics, and in-site metrics is a property named searchable time. So it's the time it takes to get to searchable state. It's about 5,000 milliseconds. Okay, so we know that that global variable is in the page, and we want to use Lighthouse to retrieve that. So let's switch back over to the slides. And so step one, we need to gather that global variable. So in Lighthouse, every gather extends from a gatherer base class, and that just sets things up for you. And then there's several lifecycle methods, which correspond to, during a page load, when you want to run gatherer code. So the first stage is called beforepass, and that's before the page loads. It runs, and it can set things up or set some sort of throttling up or something like that. But in this case, we don't care, we just want that global variable. So instead, we go to afterpass. So afterpass fires, after the page is fully loaded, everything's settled down, nothing seems to be loading anymore. Lighthouse calls afterpass from us. And in this case, all we're going to do is get the driver, which talks to the debugger protocol. And then there's a bunch of helper methods on there to make a lot of things easy. And one of them is evaluateAsync. And evaluateAsync just runs this JavaScript snippet in the context of the page and returns whatever that result is. So that's that same variable that we saw in the console? It's the same exact variable. In fact, it's exactly the string that we ran in the DevTools console, window.siteMetrics. And just like in the console, it's going to return that object with property searchable time. So in this case, we're just going to return the results of that. And Lighthouse will take that and bundle it up as our artifact from this gatherer. And it'll just use the same name as the gatherer, siteMetricsGatherer. That'll be the name of the artifact. So let's go on to the next stage and actually audit our result. Okay, so just like gathers, every audit extends from the audit base class. And then audit needs a little more bookkeeping. They have this meta object, which tells Lighthouse kind of what to do with this, how to categorize it. When it puts into a report, it tells, like, what help text, what description to use to tell your users, like, you know, how to fix this or something like that. But the most important thing is this required artifacts there. And that tells Lighthouse, hey, I'm going to need an artifact from the gatherer stage named siteMetricsGatherer. So every audit has an audit method. And that's called with our artifacts. And in the artifacts is our siteMetricsGatherer artifact. And just like in the DevTools console, there's a property named searchableTime. So we're going to get that searchableTime. And then our audit there at the bottom is just, is it less than four seconds? And if it's below four seconds, we pass. If it's above four seconds, we fail to get a big red X in our Lighthouse report. And that's an audit. Super simple. And you just chose four seconds because, hey, why not? Well, it seems like a, you know, reasonable thing. Like, come on. You should have an input before four seconds. Yeah. So the last thing we need to do is make a configuration file for Lighthouse to tell it how to find the gatherer, how to find the audit and how to run them. So just like something like ESLint, you can extend from the default Lighthouse run and that just tells it, hey, run all the normal passes and audits and gathers that you normally do so that my gatherer, my audit can be in the same context, the same report as all the rest. So as Eric was saying, we have this concept of passes. This is the number of times that we reload the page. And we want to say, let's put our gatherer, our site metrics gatherer into the default pass, the first pass of Lighthouse. Let's add our load audit to the list of audits that Lighthouse runs in the default configuration. And then finally, let's make a category in the report just for our site. We're going to call it my site metrics because that's the best name we apparently can come up with for our presentation. Very descriptive. Very descriptive. And we're going to say, hey, have this audit in there and if there was more audits, they would be averaged together and you can add a nice weighted average. Okay, so we have a pre-recorded video. So we just, for this thing, you can do yarn start. You can see what it's running. It's Lighthouse. It passes the config path to it and the URL. It's running. It's running. So this is running Lighthouse with all the stuff that's default. But then if you scroll all the way down to the bottom, you can see my site metrics. Amazing. And you can see that six seconds for this run and it totally failed. Failed it. We got a zero on my site metrics. And now you can say, like, oh, well, that's awesome. We really need to do better. So this is great. We can run any audit we want. We can write and have it available for our site, particularly for our site. And so we can know when we're doing terrible. But if only there was a way, oh, wait. Oh, yeah. There's a nice slide for you. This is the command. Yeah. But if only there was a way that we could automate it so that I don't have to run Lighthouse every time, I could just have a machine check it for me. That would be the ideal. We can do that. Oh, we can do that. Oh, thank you. Yeah, we can do that. That's not a problem. All right. So you can use Lighthouse programmatically. And people often kind of forget about this. They come to us and they say, hey, can you add this feature to Lighthouse? Or can you add this audit? And we're like, well, we're just no. You can write a program that uses Lighthouse any way you want. So Lighthouse is just one required statement away. Always. Keep that in mind. So a cool example of this. We'll just write a couple lines of code and show you how to use Lighthouse from Node or some JavaScript. The first thing you do is require Lighthouse. That's no big deal. We have this Chrome launcher that's part of Lighthouse's code base. And that basically just is the thing that launches Chrome with a debugger port open. It does things like find Chrome on your machine, selects Canary or stable channel. It turns off some background processes so that it traces a little cleaner. It's not trying to download dictionary items or something. It's just trying to run some Chrome features that you don't need when you're running Lighthouse. So we're just using that. We're just going to import that and launch Chrome that way. So I'm going to write a little helper method called launch Chrome and run Lighthouse. And I'm going to use async and await. But you can totally use promises if you want. Async. Yeah. Wow. You're like from the future. The future. Yeah. But it keeps the code a little cleaner. So this method is just going to take the URL that we want to test. This is the page we want to test. We're going to run Lighthouse and also a placeholder for the configuration file if we have the custom config that Brendan just showed you how to write. So in this method, the first thing you do, no surprise, is just launch Chrome. Chrome launcher.launch is the method you call. And that returns a promise. And then when Chrome selects the port, we basically just stash that port. And we're going to forward that onto Lighthouse. So Chrome is launched. It's found it, set it up for us. And then we actually just run Lighthouse. And this is also going to return a promise. And when Lighthouse returns, we give it the URL. And it's going to give us a bunch of JSON. So we'll just forward on the URL the flags and the config right to Lighthouse. Once we have the results, we're good to go. We can kill Chrome. And that will basically shut Chrome down using Chrome.kill. And then we'll return the results to the caller. The way you use this method, you just call launch Chrome and run Lighthouse. You give it the URL you want to test. For example, .com in this case. And we're specifying that we want the results in JSON rather than the default HTML file you get. And then you can use the results any way you want. So... Yeah, that way you can test against it. Use it on your CI or whatever you want. So all in all, like 12 lines of code, not too hard to use Lighthouse programmatically. And that's exactly what we're doing. If you've joined us over at the mobile web sandbox during the show and apologize for the live streamers who haven't had that, we do have a nice little video of the big Lighthouse over in the sandbox area. It's just using Lighthouse in Node and it's using the Hue Lights API to control the lights based on the score you get when you run a URL. So a quick demo of this. This is the big Lighthouse where I put in a URL. I think it was like chromestatus.com or something. And Chrome Status is a PWA. It does pretty well and it changes the color of the lights green. Come over and try your site and you can get a very satisfying green glow or, you know... Or red or... A little fog horn to show you. There are some surprises. To improve. So if you want to check out the code that's on GitHub under that URL there for the big Lighthouse. Another thing people often want to do is, you know, integrate with GitHub and pull requests in Travis, right? A lot of us are doing development work on there. And so you can do that as well using Lighthouse. You basically want this little beacon of light following you wherever you go, right? Yeah, you want Lighthouse watching in your back. Watching your back. Little Lighthouse telling you, good job, or... You want to know if somebody sends you a pull request if your performance or your Lighthouse score is going to drop. And so we have a demo of this as a proof of concept. This is totally doable. What I have here is a pull request on the left. I don't know what it does. Don't care because Lighthouse is going to help me. On the right, Travis is just going to do its normal thing. It's going to build this pull request, run my linting scripts, run my gulp stuff. So as that's happening, we'll just see that log output go through. We'll check out and see what this pull request does. We'll look at the changes. Let's pop over and see. So there's a script tag. It's like loading jQuery, which... That's okay, yes. But there's this delay thing and the seconds thing. It looks scary. It looks questionable. So let's let Lighthouse decide. I don't know if it's good or bad, but let's determine that through magic. So we're building the PR. And what's going to happen here is that after this is done, our little helper script is basically going to send these changes, the pull request changes, to my staging server and deploy it to a staging URL. And then Lighthouse is going to go test that URL, return the results, and then modify the pull request. So if we do that, you can see this little helper script called runLighthouse is testing the URL and I've set a minimum score of 96. I want to get a 96 or above in order to pass this pull request. And eventually, when all this stuff comes back, Lighthouse will finish auditing the pull request changes and tell me that, uh-oh, this is not a good change. Hashtag I promise this is not going to hurt your performance was not true. Turns out. So I've got a 93 out of 96 and I wanted a 96. Thanks Lighthouse. Thanks Lighthouse, yeah. So this is really kind of very simple to set up. We have some example code if you want to check that out at the top there. Again, it's just normal Travis. So do everything you're normally doing, like building your scripts and linting and all that good stuff. And then the magic comes in after a success. And so I have a little shell script that deploys the pull request to App Engine. If you're using Firebase or some other server, then you can choose how to deploy your own stuff. And then there's this example runLighthouse JavaScript file. And that basically just fires off Lighthouse, test it on a headless version of Chrome in the cloud, and then returns the score. I'm passing two environment variables here, the score that I want to achieve, and the URL that I want to test. And in this case, it's that staging server URL on App Engine. So that's how you use Lighthouse and get that little light everywhere on GitHub and Travis. Another thing that just actually happened was Chrome launched headless mode in Chrome 59. So brand new stuff, very cool for automated testing. If you fire up Chrome from the command line, you can pass the dash dash headless flag. And that'll start Chrome essentially without Chrome. So it's great for headless testing, Travis, automated environments where you don't need a full UI of Chrome. You just want to do some browser testing. You can do some cool stuff from the command line. You can take a screenshot. You can create a PDF if that's your cup of tea. You can dump the DOM, so essentially just kind of curl the page and get the HTML of the page. There's also a command line flag for setting the window size, which is kind of convenient if you want to scale down to a mobile device, for instance. So if you want to use headless Chrome with Lighthouse, you can totally do that. We talked about the Chrome launcher module that we have in the Lighthouse source. You basically just create the launcher, and when you launch it, you pass in an additional flag called Chrome Flags. And these are just normal Chrome flags. So anything you need to launch Chrome with, you can pass it there. And we'll just pass the dash dash headless flag. So really easy to use Lighthouse with headless Chrome. Yeah. Yeah. All right. So that's a lot of stuff. I'm kind of tired. I'm a little sleepy from lunch. My line is yawning. It's not roaring. Yeah. He's not scared. He's yawning. Yeah. So with that, let's just kind of recap what we talked about before we close out here. Basically, if you're building on the web, this is your web app. OK. You don't want to be that guy. You definitely want to use Lighthouse, continuously test, integrate. It's really, really awesome. And we're trying to make Lighthouse as friendly and user-friendly as possible. Don't forget about this useful tool that could have helped you not do that. You want to remind us? Sure. Yeah. So everywhere that you can run Lighthouse, Lighthouse is available as a Chrome extension. You can go install it at Chrome Web Store. Super easy. Easy to use. Easy to just drop in any time. Lighthouse is available as a Node module and CLI tool. We just shipped the newest version of Lighthouse to MPM. So if you want to try out the newest version and file out some bugs for us, that'd be great. And there's a bunch of command line flags here that we didn't talk about that you can use to tweak. Yeah. So if you want to walk specific resources, you can change the throttling. You can do all sorts of customization that you wouldn't be able to do with extension. One thing we didn't talk about is web page test. So web page test is obviously a super popular tool that people use to test the websites. It has a great way to share reports after you're done with them. So web page test actually is Lighthouse integrated into it. If you go down, you can see there's a Lighthouse check box there. You click that. Your Lighthouse report score will appear, and you can click that and see the full Lighthouse report available. Super easy to share. It's available right now, actually. And then as a couple of people have mentioned throughout I.O., it's available now in Chrome DevTools in Canary right now. You can go try it out and see what your score is anytime, as long as you have Canary installed. OK, so that's where we are right now. Eric, what's next? I don't know. What is next? What? What is next? There are some slides. There are some slides. So one thing we want to do is kind of be wherever developers are. So another place that you often go to is HTTP Archive, and they have a slew of data on the web. They run against like, I don't know, tens of thousands, hundreds of thousands of URLs, and basically have all this interesting data and surface that publicly. They're considering integrating with Lighthouse. So pretty soon, hopefully, you'll be able to see how many URLs out there are progressive web apps. What are their accessibility scores, and their performance scores, and best practice scores? And so that's something we're pretty excited about, because then you can see kind of the shape of the web over time. Another one that I want to give a shout out to is Caliber, which is an awesome online performance testing tool. And they're integrating with Lighthouse. You can actually get Lighthouse results in this tool. And you can see their scores, PWA, best practices, same Lighthouse stuff. So they're consuming Lighthouse, and then you can actually track your performance over time, which is a really awesome UI for that. On the roadmap for Lighthouse itself, there's just a ton of stuff we want to do that we haven't had time to do yet. A lot of new audits. We could test anything, really. And we'd love to have your help actually contribute some of those audits. JS code coverage, whether you're not using CSS selectors or not. SEO best practices. There are a lot of things you have to think about in order to work with crawlers. UX, right? Are you popping up an interstitial? Can you scroll the page at 60 FPS? These are really good things that we can just automate using Lighthouse and tell you if you're doing them well or telling you if you can improve. Security and some other ones. And there's also a bunch of stuff we want to do on the core team as well. So what happens after a page load for single page apps? Maybe you have an app behind a login screen. Maybe there's some things you want to test after the page loads and use Lighthouse for that. Faster auditing, just make the whole process faster. As we add more stuff, obviously it's going to get slower, so we want to make it as fast as possible. More integrations and also making it a lot easier for folks to contribute. Brendan showed you today how to create a custom audit, but we can make that probably even easier. So the good stuff is, I'm going to throw this up for just a brief moment. If you want to get Lighthouse on MPM, you can MPM install Lighthouse. We have extensive documentation for reference material for all of the audits that we have up on developers.google.com. And if you want to write your own audit to work with Lighthouse, you can check out the DevTools protocol reference, which is really good. It's got all the APIs there that you can learn how to actually use the DevTools protocol. Crazy amount of information you can do, get from the browser, and a crazy number of things you can't do to the browser. We also have some in the GitHub repo, if the custom audit thing went too fast, we have some great recipes in there that you can copy and paste to get started with scripting Lighthouse and doing your own thing. Very cool. Brandon and I are the ones talking today about Lighthouse, but I do want to give a quick shout-out to the rest of the Lighthouse keepers. We have some people that are working internally at Google on this, on the DevTools team, on develop relations, but also we have some folks in the community that are helping us build Lighthouse. So it's not just a Google project, we have a ton of help from the outside, too. So hopefully you can come in and help us out build some stuff. So a shout-out to the Lighthouse keepers. And with that, my name is Eric Bidelman. This is Brandon Kenney, and don't forget that it's really important. Thanks, guys.