Staying off the Rocks: Using Lighthouse to Build Seaworthy Progressive Web Apps (Google I/O ’17)

Articles, Blog

Staying off the Rocks: Using Lighthouse to Build Seaworthy Progressive Web Apps (Google I/O ’17)

Staying off the Rocks: Using Lighthouse to Build Seaworthy Progressive Web Apps (Google I/O ’17)


[MUSIC PLAYING] ERIC BIDELMAN: All right. Welcome, everybody. Thanks for sticking
around during lunch time. 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. [APPLAUSE] So my name is Eric Bidelman. This is Brendan Kenny. We are both on the Developer
Relations team at Google. We 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. 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, 2010? BRENDAN KENNY: Yeah. ERIC BIDELMAN: And it uses,
what, CSS 2D transforms? BRENDAN KENNY: 2D transforms. ERIC BIDELMAN: Why does it– BRENDAN KENNY: We only had 3D
on the iPhone, at the time. Everybody else was
still stuck in the– ERIC BIDELMAN: So 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 that 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. BRENDAN KENNY: I have done
some things since 2010– ERIC BIDELMAN: That’s right. BRENDAN KENNY: –until now. ERIC BIDELMAN: 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’s a PWA. It uses all the latest
web technologies. So it’s Polymer web components. It’s got a service worker. There are these games
that launch every 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 jolly guy. BRENDAN KENNY: It’s
Santa’s gift to you. ERIC BIDELMAN: That’s brutal. BRENDAN KENNY: Let
him give you a– ERIC BIDELMAN: But
that’s a fun one. And we do this because
we want to not only build real stuff on our team, but
we also want open source it and 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 pull 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, 2x 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. BRENDAN KENNY: Yeah. ERIC BIDELMAN: But
wouldn’t it be nice if there was a tool to help
us prevent mistakes like this? BRENDAN KENNY: If
only there was a way to automate this whole thing. ERIC BIDELMAN: If
only there was a way. BRENDAN KENNY: Yeah. ERIC BIDELMAN: 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 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 a manual process. You have to serve
your site over SSL. You have to have a
service worker for offline and all that entails. Responsive, Add to Home
Screen, are you fast on 3G? If you actually just go
and scroll this page, that’s daunting. 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 signs to
help us navigate the road and to give us information. We have lighthouses to
help ships 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 and that you’re using best
practices, that you’re PWA, and that you’re performant. Last year, Paul Irish, who’s
sitting in the front row right here– what’s up, Paul? BRENDAN KENNY: He
looks pretty young. ERIC BIDELMAN: Yeah. He actually
introduced Lighthouse. And back then, we were
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. Are you 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– four underscores. That’s really important. BRENDAN KENNY: Yeah,
don’t forget that. ERIC BIDELMAN: I don’t
know why we did that. But anyway. BRENDAN KENNY: And yet, on the
first day that we created it, it had more followers than me. That’s not fair. ERIC BIDELMAN: 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. BRENDAN KENNY: Yeah. Let’s try it out. So if we can switch
to the– perfect. OK. So if you’ve been over
to the Mobile Web tent, 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, I don’t
know, 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, oh, 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 would,
throttling network, even throttling the CPU to
try and simulate that. 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 checklist that Eric went through before. So at the top is the
Progressive Web App checklist, how your site has
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 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. ERIC BIDELMAN: We’re
doing some stuff, yeah. BRENDAN KENNY: Yeah, yeah. ERIC BIDELMAN: It’s good. BRENDAN KENNY: 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– ERIC BIDELMAN: So that’s
a one-button press? BRENDAN KENNY: Yeah. ERIC BIDELMAN: You
get Lighthouse. You get a lot of
information in that. But what if– like 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? BRENDAN KENNY: Yeah. Well, it’s funny
that you ask, Eric, because I have a
terminal back here– ERIC BIDELMAN: Oh, wow. BRENDAN KENNY: –just
for people like you. So Lighthouse is
also a CLI tool. And it’s as simple as npm
install -g Lighthouse. And then we could
do Lighthouse– test the same demo server. And then I’m going to add the
pro move of adding dash dash view to open up the report. But there’s a bunch
of options here where you can also
do things like turn off network throttling,
emulate a different device, that sort of thing. ERIC BIDELMAN: So this is
just a little Node script. It’s doing the exact
same thing as what the extension was doing. BRENDAN KENNY: Exact same thing. In the background here, you
can see Chrome is loaded and it’s going, trying
to load the page. It’s running a bunch
of audits and tests. And then boom, boom, you’ve
got the exact same report– ERIC BIDELMAN: Hey, cool. BRENDAN KENNY: –for a CLI tool. ERIC BIDELMAN: Very cool. OK. So Chrome extension,
that’s a one-button press. I can run it on Command
Line, use it in Node if I’m in that environment– BRENDAN KENNY: Yeah. ERIC BIDELMAN:
–programmatically too, which we’ll talk about. BRENDAN KENNY: Right. ERIC BIDELMAN: What
if I don’t really want to install anything? BRENDAN KENNY: Yes. ERIC BIDELMAN: Is there
an even better way? I’m working in, you know– BRENDAN KENNY: 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 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. ERIC BIDELMAN: That logo
follows you everywhere now. BRENDAN KENNY: Yeah. ERIC BIDELMAN: That’s awesome. BRENDAN KENNY: Yeah. ERIC BIDELMAN: So same thing. Same open source project
is running in all three of these different
environments and baked now into the Chrome DevTools. BRENDAN KENNY: Yeah. So if you’ve ever felt like
contributing to DevTools, but it’s a little
intimidating, just go contribute to
Lighthouse, and it’ll get put right into DevTools. ERIC BIDELMAN: That’s awesome. BRENDAN KENNY: And you too
can have code running there. Yeah. ERIC BIDELMAN: Everybody can
have code in DevTools now. BRENDAN KENNY: Yeah. ERIC BIDELMAN: Awesome. Thank you, Brendan. BRENDAN KENNY: OK. So let’s switch back over to– ERIC BIDELMAN: Switch back
slides to talk about– BRENDAN KENNY:
Performance metrics. Those look fancy. ERIC BIDELMAN: 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 a pull
request or a developer 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.onload and DOMContentLoaded. These are performance metrics,
traditional old-school metrics. Are these good things
we should be thinking about in 2017, Brendan? BRENDAN KENNY: Well,
it really depends. So maybe window.onload fires
about when your page is ready. But maybe you have a
server side render 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 when your site loads. ERIC BIDELMAN: So, again,
web development is complex. You don’t know if you
should care about it or not. BRENDAN KENNY: Yeah. Right. ERIC BIDELMAN: What about– so
Addy Osmani always tells me, reduce the size of
your JavaScript bundle. 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? BRENDAN KENNY: 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 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. ERIC BIDELMAN: 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.onload. Are your images loaded? Are your scripts loaded? It’s about what the user
perceives during this lifecycle of page load. So let’s walk through
these in context. Do you want to take
a shot at these? BRENDAN KENNY: Sure. Yeah. Oh, yeah, fancy. Sure. You press Enter. You start navigating your page. And First Paint is really
when the first pixel changes on the screen. That could be a
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
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 the
search box that’s the primary element of the page. Something that really
captures like, hey, as a user, I’m looking at this and
saying, OK, this is actually what I came to this site for. So next up is Visually Ready
and then Time to Interactive. So just because something
is painted on the screen doesn’t mean it’s
actually usable. So we’ve all been to sites
where everything is ready to go, and then you try
and do anything, and nothing happens because
the JavaScript is actually spinning in the background or
something is still loading. ERIC BIDELMAN: Or
you’re typing the input and then it nukes the input. BRENDAN KENNY: Exactly. It just nukes it and then
you want to smash the screen. So Time to Interactive
tries to measure that. It’s saying, OK,
everything’s loaded. But now I’m going to look at
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 to Interactive fires. And then finally,
you’re finished. ERIC BIDELMAN: Fully loaded. BRENDAN KENNY: Yeah. ERIC BIDELMAN: Ready to go. BRENDAN KENNY: Yeah. ERIC BIDELMAN: Cool. BRENDAN KENNY: And 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, really early on, that page has
the full layout of the page. But Time to Interactive
doesn’t fire for quite a while. ERIC BIDELMAN: That
JavaScript bundle. BRENDAN KENNY: Yeah. ERIC BIDELMAN: It’s too big. BRENDAN KENNY:
It’s pretty rough. ERIC BIDELMAN: We
also have targets for each of these, where we
think you should be hitting. So that’s really
important, too– BRENDAN KENNY: Yeah. ERIC BIDELMAN: –considering
what the metric is that you should be targeting. OK. So let’s say I’m a developer. I want to integrate
with Lighthouse. Maybe I’m already tracking
performance metrics and I want to zest in
my performance metrics with those awesome metrics
that we just talked about that Lighthouse is giving you. BRENDAN KENNY: Yeah. Phil and [INAUDIBLE] gave
a great talk yesterday, web performance
something something. ERIC BIDELMAN: It’s
a very long title. BRENDAN KENNY: And they
talked a lot about how these are great metrics. It’s really useful to be
user-centered and think about the user experience,
but you know your site better than any 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. ERIC BIDELMAN: So we can do that
by writing a custom audit that plugs into Lighthouse. OK. So before we do this, let’s
just 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 OK, Brendan? BRENDAN KENNY: Yeah. You get to do the boring part. ERIC BIDELMAN: Should
I do the boring part? OK. 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. Its a really
awesome set of APIs. Essentially, anything
that DevTools can do, the API can do, as well. So its super
powerful, and this is how we’re going to
interface with Chrome and write a custom audit. So we have this
Lighthouse runner. That’s the 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 shim that we created
called the driver. And that talks to
DevTools Protocol. So we’re built on
the stack of giants. Everything below us is
just DevTools in Chrome. BRENDAN KENNY: Yeah. 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. ERIC BIDELMAN:
Lighthouse fires up, it connects to Chrome,
it opens in 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
WebEx section. Here is the Accessibility
section, so on and so forth. So gathering, auditing, and
report generation, and that gets you a Lighthouse report. BRENDAN KENNY: All right. ERIC BIDELMAN: Pretty simple. So with that, we’re
all on the same page. BRENDAN KENNY: Yeah. ERIC BIDELMAN: We could
write a custom audit. BRENDAN KENNY: 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
plugin really easily because, in many
ways, Lighthouse is just 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. ERIC BIDELMAN: Do you want me
to switch to the demo screen? Do you want to show
the metric that we’re– BRENDAN KENNY: Oh, yeah, yeah. So yeah, so let’s switch over. ERIC BIDELMAN: So the
developer of this page is actually already
thinking about performance. BRENDAN KENNY: Yeah. 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 are
logging this in the console. ERIC BIDELMAN: Five seconds. BRENDAN KENNY: 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. But we’re going to do the
simplest possible thing and just set it to a global
variable name, Site Metrics. And in Site Metrics is a
property named Searchable Time. So it’s the time it takes to
get to a searchable state. It’s about 5,000 milliseconds. OK. 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 1, we need to
gather that global variable. So in Lighthouse, every gatherer
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, gather, or code. So the first stage is
called before pass, 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 after pass. So after pass fires. After the page is fully loaded,
everything’s settled down, nothing seems to
be loading anymore, Lighthouse calls
after pass 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 then returns whatever that result is. ERIC BIDELMAN: So that’s
that same variable that we saw in the console. BRENDAN KENNY: It’s the
same exact variable. In fact, it’s exactly the
string that we ran in DevTools Console, window.sitemetrics. And just like in
the console, it’s going to return that object
with property searchable time. ERIC BIDELMAN: Cool. BRENDAN KENNY: 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– site metrics gatherer. That will be the
name of the artifact. So now let’s go on
to the next stage and actually audit our results. So just like
gatherers, every audit extends from the
audit base class. And then audit needs a
little more bookkeeping. They have this
meta object, which tells Lighthouse what to do
with this, how to categorize it. When it puts it
into a report, it tells what help text,
what description to use, to tell your users,
like 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 the 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 and we get a big red x
in our Lighthouse report. And that’s an audit. Super simple. ERIC BIDELMAN: And you
just chose four seconds because, hey, why not? BRENDAN KENNY: Well, it seems
like a reasonable thing. Come on, it should
work in four seconds. ERIC BIDELMAN: It should have
an input before four seconds. BRENDAN KENNY: Yeah. So the last thing we need to
do is make a configuration file for Lighthouse to tell it
how to find a gatherer, how to find an 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 gatherers
that you normally do so that my
gatherer or my audit can be in the same context
and 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. ERIC BIDELMAN: Very descriptive. BRENDAN KENNY: Yeah. ERIC BIDELMAN: Very descriptive. BRENDAN KENNY: And
we’re going to say, hey, have this audit in there. And if there were
more audits, they would be averaged
together, and you can add a nice weight so you
get a nice weighted average. OK. So we have a pre-recorded video. So 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. ERIC BIDELMAN: So this
is running Lighthouse with all the stuff that– BRENDAN KENNY:
Normal Lighthouse. ERIC BIDELMAN:
–comes by default. BRENDAN KENNY: But then,
if we 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. ERIC BIDELMAN: We failed it. BRENDAN KENNY: We got a
zero on My Site Metrics. And now you can say
like, oh, well– ERIC BIDELMAN: That’s awesome. BRENDAN KENNY: –we
really need to do better. So this is great. We can run any audit
we want that we can write and have it
available for our site, particularly for our site. ERIC BIDELMAN: Yep. BRENDAN KENNY: 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– ERIC BIDELMAN: This
is the command, yeah. BRENDAN KENNY: 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. ERIC BIDELMAN: We can do that. BRENDAN KENNY: Oh,
we can do that. Oh, thank you. ERIC BIDELMAN: Yeah,
we can do that. That’s not a problem. BRENDAN KENNY: OK. ERIC BIDELMAN: 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 Node. You can write a program
that uses Lighthouse any way you want. So Lighthouse is just one
require statement away always. Keep that in mind. So a cool example
of this, we’ll just write a couple of lines
of code and show you how to use Lighthouse from
Node or for some JavaScript. The first thing you do
is require Lighthouse. That’s no big deal. We have this
ChromeLauncher that’s part of Lighthouse’s codebase. 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. BRENDAN KENNY: It turns off some
background processes so that it traces a little cleaner. It’s not trying to download
dictionary items or something. ERIC BIDELMAN: Yeah. It turns off 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 launchChromeAndRunLighthouse. And I’m going to
use async and await. But you can totally use
promises if you want. I just wanted– BRENDAN KENNY: Async. Yeah, wow. You’re like from the future. ERIC BIDELMAN: 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. It’s going to take a
flags object, if we want to pass any
flags to 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. ChromeLauncher.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 on to 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 now basically just shut
Chrome down using chrome.kill, and then we’ll return the
results to the caller. And the way you use
this method, you just call
launchChromeAndRunLighthouse. You give it the URL
you want to test. So 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. BRENDAN KENNY: Yeah, that
way you can test against it. ERIC BIDELMAN: Use any of
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 it to light green. BRENDAN KENNY: Come
over and try your site, and you can get a very
satisfying green glow or, you know. ERIC BIDELMAN: Or red or– BRENDAN KENNY: Yeah, with
that little foghorn– ERIC BIDELMAN: –orange. BRENDAN KENNY: –to show you. ERIC BIDELMAN: There
are some surprises. BRENDAN KENNY: Could improve. ERIC BIDELMAN: So if you
want to check out the code, that’s on GitHub under that URL
there for the big Lighthouse. Another other thing
people often want to do is 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. BRENDAN KENNY: Yeah, you want
Lighthouse watching your back. ERIC BIDELMAN:
Watching your back. BRENDAN KENNY: A little
Lighthouse telling you good job or– ERIC BIDELMAN: So 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 loading JQuery,
which that’s OK, I guess. But there’s like this delay
thing and this seconds thing and it looks scary. BRENDAN KENNY: It
wastes seven seconds. Yeah, it seems
like an odd choice. ERIC BIDELMAN: It
looks questionable. BRENDAN KENNY: Yeah. ERIC BIDELMAN: 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 run Lighthouse
is testing the URL, and I have 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, it turns out. BRENDAN KENNY: It’s a lot. ERIC BIDELMAN: So I’ve got a 93
out of 96, and I wanted a 96. BRENDAN KENNY:
Thanks Lighthouse. ERIC BIDELMAN: Thanks
Lighthouse, yeah. So this is really
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 success. And so I have a
little shell script that deploys the pull
request to App Engine. But 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,
run Lighthouse JavaScript file. And that basically just
fires off Lighthouse, tests 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–
that guy likes it– in Chrome 59. So brand-new stuff and very
cool for automated testing. If you fire up Chrome
from the Command Line, you can pass the
–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
ChromeLauncher 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 chromeFlags. And these are just
normal Chrome flags. So anything you want
to launch Chrome with, you can pass it there. And we’ll just pass
the –headless flag. So really easy to use
Lighthouse with headless Chrome. BRENDAN KENNY: Yeah. ERIC BIDELMAN: Yeah. All right. So that’s a lot of stuff. I’m kind of tired. I’m a little sleepy from lunch. BRENDAN KENNY: Oh, that lion
is yawning, it’s not roaring? ERIC BIDELMAN: Yeah,
he’s not scared. BRENDAN KENNY: I see. ERIC BIDELMAN: 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. Test, 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. Do you want to remind– BRENDAN KENNY: Oh, sure, yeah. So everywhere that you
can run Lighthouse. Lighthouse is available
as a Chrome extension. You can go install
it from Web Store. Super easy. Easy to use, easy
to drop in anytime. Lighthouse is available as
a node module and CLI tool. We just shipped the newest
version of Lighthouse to NPM. So if you want to try
out the newest version and find lots of bugs for
us, that would be great. ERIC BIDELMAN: And there’s a
bunch of Command Line flags here that we didn’t
talk about that you can use to tweak Lighthouse. BRENDAN KENNY: Yeah, you can
block specific resources, you can change the throttling. You can do all sorts
of customization that you wouldn’t be able
to do with the 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 their websites. It has a great way
to share reports after you’re done with them. So Web Page Test actually has
Lighthouse integrated into it. If you go down,
you can see there’s a Lighthouse checkbox there. You click that, and then
at the top of your report, 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? ERIC BIDELMAN: I don’t know. What is next? What is next? BRENDAN KENNY: There
are some slides. They’ll help. ERIC BIDELMAN: 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 HTTPArchive, and they have a slew
of data on the web. They run against, I don’t
know, tens of thousands, hundreds of thousands
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 what they
were pretty excited about, because then you can see the
shape of the web over time. Another one that I
want give a shoutout to is Calibre, 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
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. Are you popping up
in 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
tell 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 page
load for single-page apps? Maybe you have an app
behind a login screen, maybe there are
some things you want to test after the
page loads, and you 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 NPM, you can NPM 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. BRENDAN KENNY: Crazy
amount of information you can get from the browser
and a crazy number of things you can do to the browser. We also have something
in the GitHub repo, if the custom [? model ?]
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. ERIC BIDELMAN: Yeah. Very cool. So Brendan and I are the
ones talking to you today about Lighthouse,
but I do want to give a quick shoutout to the rest
of the Lighthouse keepers. We have some people that
are working internally at Google on this,
on the DevTools team on Developer 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 shoutout to the
Lighthouse keepers. And with that, my
name is Eric Bidelman, this is Brendan Kenny, and don’t
forget about four underscores. That’s really important. Thanks, guys. [APPLAUSE] [MUSIC PLAYING]

Leave a Reply

Your email address will not be published. Required fields are marked *