[MUSIC PLAYING] ERIC BIDELMAN: Hello. Hello, hello, hello. All right, so we got
a lot to talk about. We should probably just jump in. PAUL IRISH: Yeah, we do. ERIC BIDELMAN: Modern
tools, testing, automation, Headless Chrome, Puppeteer. Sound good? PAUL IRISH: a lot of stuff. All right. Guys, we're going to cover
quite a few things today. We're starting off
with the dev tools. Now, in the DevTools,
there's a lot of things that we've been working
on in the last couple months since last
Chrome Dev summit even, since last
Google I/O. So we're going to show a few
of those things now. We're gonna start
off in Authoring. When we talk about
Authoring, I'm talking about the
experience of us as developers handcrafting
that user interface and delivering that awesome
user experience for our users. And so, there's a lot
of things going on here. And the first thing I want
to call out is grid layout. Is implemented across browsers. It's awesome. In fact the new
slack.com homepage, they're using grid
in production. It's awesome. This monopoly experiment was
on CodePen the other day. It's using grid too. And so, let's take
a look and see what it looks like with DevTools. So we can open this
up and inspect, and so you'll see everything
laid out here with grid. The grid column, grid row,
if we select the parent, our little highlight
overlay will be showing all the
little cells of the grid. And so, we can
change the grid gap and see even that
little highlight overlay change real-time. So it's giving you a
lot better understanding of how the grid is being
laid out on the page. It's worth giving a
shout-out here to Firefox, as they kind of blazed the
trail on their DevTools, but we hope you're
going to like this one. Now, next up, we
have a new experiment about to ship for
color contrast. The line in the swatch here
is coming down and giving you an idea of, on one side of the
line, the contrast is good. On the other side, it's bad. As you move around
and select colors, is going to give you feedback
and tell you if you're hitting certain thresholds. You can select the background
color and get kind of a preview right there. So please do give this a shot. Give us your feedback. Now, Eric, have you
ever been in a situation where you need to change
something about a site, but it's not your site. You're not running the
dev server, for instance. ERIC BIDELMAN: Yeah. PAUL IRISH: But you want
to change something, and now you open up
DevTools, of course you could change anything. But you know that if you
have to reload the page-- ERIC BIDELMAN: --I lose
those all the time. PAUL IRISH: It's gone, right? ERIC BIDELMAN: Those critical
changes I make in the DevTool. PAUL IRISH: But you want it to
add something, change something about the JavaScript in
the way that it starts. And you're like, OK,
but how do I do that? It's painful. So I want to show you a
brand-new feature that we're calling local overrides. You can think about this
as kind of offline storage for your tweaks. So, first I want to show
you how we set this up. So, take for instance the
website for this event. We're going to make
some changes to this. Why not? I don't have the
dev server for this, but I want to make some changes. In the sources panel,
we go to overrides and we're going to set this up. Now, first thing
that we do, we're going to create just a folder. And this is a folder on disk
that we're going to use, and it's going to store
all of our changes, and DevTools needs access to it. So this point, cool. It's an empty folder. It's on disk. This folder is going to hold
everything that we change. CSS files, they're
just going to be here and I can open these
up with a text editor and save them to disk. DevTools is now
going to use this. But let's make some
changes inside of DevTools and see how that works. So, now, let's change JavaScript
is what I wanted to do. So we'll open up the one
JavaScript file on this page It's just some minified script
but we'll add a console log at the top just to make sure. Get myself a little hello,
and we hit Control S. Now at this point, you see
this little purple icon right on the top, and
this is indicating that we are now overriding
the site's version of this. And when I reload the page,
we see the console log, which is pretty rad. [CHEERING] PAUL IRISH: Now, we'll
do the exact same thing with JavaScript, so, here's
the production JavaScript. We'll pretty-print it so
we can see what's going on. We'll hit Control S,
and now that one is also saved to that little
folder that we made. I'm going to come back
to [INAUDIBLE] panel and we'll make the change over
there improve the font color, I think. ERIC BIDELMAN: Love it. PAUL IRISH: Maybe some-- ERIC BIDELMAN: Magenta. PAUL IRISH: Yeah. Ooh. ERIC BIDELMAN:
Never hurt anybody. PAUL IRISH: It's an upgrade. For sure. All right. That's good. There's one more change. Let's change the title
of our talk just for fun. So, changing HTML, always
the tricky one, right? So here's the HTML. We'll just go down
into the sources panel, find the title of the
talk, and just give it a little bit of an upgrade. Sounds totes profesh. [LAUGHTER] PAUL IRISH: All right. Now, we're going to reload
the page, hope everything-- Aw, yeah. Nice. [CHEERING] PAUL IRISH: So even
now, everything's coming over the network, but the
CSS, the JavaScript, the HTML's being updated. Even if I go to another
page on the site, the JavaScript and
CSS changes will still be applying to those. So, I'm really
excited about this. This is a feature that
we've long kind of wanted the capability for, and
now, in DevTools, we can deliver that to you. I should also point out, it's
a great feature for pranks. Did you know that you're
on "The Verge" homepage. ERIC BIDELMAN:
That looks amazing PAUL IRISH: Yeah. ERIC BIDELMAN: That today? That's today? PAUL IRISH: Yeah, yeah. That's today. ERIC BIDELMAN: Wow. PAUL IRISH: And
it's totally real. [LAUGHTER] PAUL IRISH: Because
I'm reloading the page, and it's definitely like, I'll
do the hard reload empty cache. It's still there. [LAUGHTER] PAUL IRISH: Really good. [CHEERING] PAUL IRISH: I mean, it's
definitely [INAUDIBLE] ERIC BIDELMAN: think
it's an improvement. PAUL IRISH: Yeah. Yeah, That's pretty good. Yeah. Clutch. So, many of you here
need a little bit more of the DevTools, you're
going a little bit farther, and so we have some
new stuff here. First thing I want to show
is the performance monitor. Now, performance
monitor is a little different than some of our
performance tools in the past, because it shows live
streaming metrics. So, we can open this up in
the drawer in the bottom, and as I load a page I'm getting
all sorts of new metrics. So, the CPU usage
broken down by category. The memory usage. We have the JavaScript
heap, and other counters like the count of
event listeners, and documents and frames. And even how many
layouts and style recalcs per second that are happening. This is giving me a
really good understanding of what's happening in
the page as it happens, and I can correlate a lot
better around my actions as I click around on the
page and the kind of metrics that I see there. So we're really excited to
see what this unlocks for you and what you're able
to learn from it. The next thing up
is the console. We spend a lot of time in the
console, and on some sites, it gets really busy in there. This is a news
site that I go to. I open up the console,
there's a lot in there. Especially if I turn on verbose. Just a lot of stuff. And dealing with this kind
of load in the console is tough because there might
be some messages that you're looking for that you don't see. So now, you can open
up this sidebar panel. We're breaking down
things for you by file, so these are all the messages
coming from the HTML page itself. Or, we can kind of view
by error, by warning. This is user messages. Everything used with console
log and console warning, console error. And this allows
you to understand which file everything
is coming from and just focus on only
what you care about. Hopefully reducing,
hopefully improving, the signal to noise ratio. And another thing
that you'll notice is, sometimes when there's
a lot of these things on the console many of
them look the same, right? Things about parser
blocking scripts and you don't need to
read this, but you see that there's things repeating. So, in Canary now,
there's a new feature, which is actually on by default,
called the group similar. [INAUDIBLE] turn on right here. So, reload the exact same
page, and this time, with group similar, we just say,
Hey, you know what? That looks very similar
to a previous thing. We're just going to kind
of group it together. And now, you can still
open up these groups and inspect and see the
individual messages, but we just wanted to clean
that up for you by default so that you don't need
to go hunt and reduce the console spam there. [APPLAUSE] ERIC BIDELMAN: So good. PAUL IRISH: All right. Rock and roll. So, Eric, you use Promises? ERIC BIDELMAN: Occasionally. PAUL IRISH: Occasionally? ERIC BIDELMAN: Like every day. PAUL IRISH: You
guys use Promises? ERIC BIDELMAN:
Literally every day. PAUL IRISH: Yeah. Yeah, yeah. How about in the console. This is an interesting thing. You evaluate
something that returns a promise in the console,
and so you'll see this thing. Promise pending. And you're like,
yeah, but I wanted to know what happens
from the fetch. Now it is true that if
you just kind of wait until you think that
this promise has resolved and then you kind of click
that arrow and open it up, then it will be resolved and
you can inspect the value. That's kind of cool. But you have to guess
as to when it resolves. ERIC BIDELMAN: Wait, how
many people knew that? I didn't. PAUL IRISH: Yeah, yeah. ERIC BIDELMAN: It-- PAUL IRISH: You can, but
I wouldn't recommend it. I mean, slightly better is this. You could just do it then,
and send it to console log, and it'll just print
when it gets there. But typing that is
kind of annoying. So, we figured we would make
us a bit easier for you, and now, just throw the await
key word in the front of it, and then easily just get the
results printed the second it happens. Now-- ERIC BIDELMAN: Can I do
that in any JavaScript file? PAUL IRISH: You do always
have to be wrapped around in an [INAUDIBLE] function. ERIC BIDELMAN: OK. PAUL IRISH: But in
the console, we just kind of took care of the
complications for you, and just made it easy, so you
don't need to worry about that. So, I'm going to wait right
here for any asynchronous stuff, just get to the value, the
results value, really easily. Now, at this event we've been
talking about progressive web apps, and on DevTools,
we want to make sure that you're able
to not only build your first progressive
web app, but scale that up to world-class
progressive web app. And so we have some new upgrades
in the DevTools for this. Over in the application
panel, you'll now see a graph
that represents how the storage is allocated
across various different types of storage. Here this is the
Twitter PWA, you can see they're
using quite a bit of cache storage, a little
bit of index DB, and so on. Now, in cache storage
there's some upgrades too. First up, on the left,
where we have the listings of which caches are there. This is now live updating,
which is a nice little bug fix that has really given
people some headaches before. So I'm happy to say that if you
add a new cache or anything, you don't need to
closed DevTools, reopen it it'll
just come in there. But now that you're
inspecting a specific cache, there's a lot more detail
in here than there was. So, in addition to what
files are in each cache, you'll see the
size and when they were placed there, their MIME
type, and their full network headers. And you can also just click
over and see the actual asset itself. In this case, an image, but this
is really nice with JavaScript files and being able
to see exactly which version of this asset is sitting
on the cache at any time, really helps a lot. Somewhat similar upgrades over
in the service workers panel, which clean this up, gotten
rid of the messy errors and old dead service workers,
and there's two new features at the bottom of
the screenshot here. The first helps with
push notifications. So, you can define
a custom payload that will be coming over a push
event inside the event data. So, this can be
text, it could be JSON, going to be whatever
you need it to be, and just push this down, will emulate
a push event into your service worker and you can
handle it there. The second, the sync, is great
for working with background sync, and allows
you to push down custom sync tags that your
service worker can respond to. OK, so-- ERIC BIDELMAN: That's awesome. PAUL IRISH: With
progressive web apps, you've heard a bit
about Lighthouse. And Lighthouse works
fantastic for evaluating your progressive web app and
finding the sorts of things that you still can improve on. And there's been a lot of
stuff that we've been doing. And, in general, I just
want to back up and say, Lighthouse, our goal is really
to analyze your web site and web app, and
diagnose the situation, and provide concrete
recommendations for how you can improve things. And our goal, really,
with Lighthouse is just to make the web better. And we want to do that by
shifting the mental load of all the details of web development,
shift that away from your brain and into a tool that can
keep track of things for you. So, there's been a
lot happening there. We're happy that
DevTools is available-- sorry, that Lighthouse
is available in Dev Tools on the CLI as a Node module. And even last year,
we were on a stage, we were talking
about Lighthouse. And then last year,
Lighthouse diagnosed about 50 different issues around
progressive web apps and performance. And now, a year later,
we've doubled that. So we're checking a lot more
things inside of Lighthouse and improved the
implementation of many. A few of the key highlights
that I'm really keen on: some new stuff around
loading performance, identifying what percentage of
your job script was executed, identifying slow
server response times, and identifying when when your
image aspect ratio has issues. Also, some nice things around
SEO and your user experience. And one of my favorites now is,
if your page has a JavaScript library, which has a known
security vulnerability, we'll flag that for you too. Calibre is available in
a lot of different tools, including some of
these tools, which allow you to understand
your Lighthouse score and as it changes over time,
and take care of that monitoring side of things for you. And it's worth pointing
out that Lighthouse works great in a
continuous environment. Build, pipeline, this is
just all the packages on NPM that depend on Lighthouse. It's very enjoyable times
to just browse these and see what people are building, and
you'll get some inspiration for the ways that you can use
Lighthouse in your development workflow. There's some exciting
things coming up. We've been working on a
project called Lantern, which provides critical path analysis
and models what is happening inside the browser. This allows us to
do a few things. One, we can run Lighthouse
about five times faster than it currently takes
right now, and two, it allows us to make much more
accurate calculations when it comes to the
performance, so we can be very precise around
how much each performance opportunity is
going to save you. We're also going to be
improving the alignment of how the story is told
between PageSpeed Insights, Webpagetest,
and Lighthouse, so you're not seeing conflicting
results from these tools. You heard yesterday about the
Chrome user experience report, and understanding what is
happening in the real world around a few points metrics,
we're going to be incorporating this data into Lighthouse too,
so that from the Lighthouse report, you're seeing a snapshot
of, this is what just happened, but given the
context of, this is what's happening to all
your users in the wild. And lastly, we're always
going to be continuing to surface more performance
improvements that are available to you, and
best practices that that can be improved on. I do just want to take a
moment to thank everyone who's contributed to Lighthouse. The Lighthouse community
has been fantastic. We've had over 100
contributors, and really appreciate all the investment of
people's time and conversations around issues, and making
sure that it's representing web developers as a whole. So, I really appreciate that. ERIC BIDELMAN: Yes, thank you. PAUL IRISH: Eric, we're
going to go back to you. It's almost Halloween. I have a joke for you. ERIC BIDELMAN: Wow,
what's your joke? Let's hear it PAUL IRISH: All right. Why did the Headless
Horseman go into business? ERIC BIDELMAN: I see
what you're doing here. OK. I don't know. PAUL IRISH: He wanted
to get ahead in life. [LAUGHTER] ERIC BIDELMAN: That was good. That was really good. PAUL IRISH: It's not that good. ERIC BIDELMAN: But,
speaking of headless, let's talk about Headless
Chrome and Puppeteer. So, Paul kind of
covered the manual side of things, some
really awesome things you can do now in the DevTools. Let's switch gears a
little bit and start automating some of that,
and writing programs that talk to the browser. Some really cool stuff. So what is a headless browser? Well, normally you
open Chrome, right? You click a button or you
launch it from the command line, and you get a nice window. There's a URL bar,
there's DevTools you can play with, and
interact with the page. But, of course, with a headless
browser, you get none of that. There's literally no
Chrome for Chrome. You take the reins,
you take the controls, and you tell Chrome where
to go, what pages to go to, how to interact
with those pages, and there's no UI to deal with. You have to write a
program to control Chrome. And the way you launch Headless
Chrome is really simple. You can launch it
from the command line and pass it the dash
dash headless flag. Pretty easy. There's a whole
article that I wrote that covers Headless Chrome. There's some pretty
useful things you can do with
it just by itself. You don't even have
to write any code. You can take screenshots
and generate PDFs from the command line. You can set up
testing [INAUDIBLE] like Karma or something. All this is in this article. So, if you want
to check that out, go ahead and visit us on
developers.google.com. But the really
interesting thing, and the thing I want
to focus on today, is talking to Chrome
using node JS. So we're going to
launch Headless Chrome, but we're also going to include
this remote debugging port. This is really key. This is how we're
going to actually use the DevTools protocol and
its APIs to control Chrome, to make it navigate
to pages, to make it do things we want it to do. So that's where the
magic comes in, Now, if you want to just work
with Headless Chrome, there's a really awesome,
very small little launcher, npm module that we
created for Lighthouse. We've taken that out and
made it a separate thing, because it's so useful
in and of itself. Chrome launcher basically just
finds Chrome on your system, you can give it
different Chromes too. Canary, dev, stable channel. And, just with
one command, it'll launch Chrome on any platform. You can pass in that
remote debugging port and pass it any flags that
you want to give Chrome. So, in our case, we want
to launch Headless Chrome. We pass it, dash dash headless. So, super useful, easy
to use node module. And then from there, you can use
Chrome however you want inside of your scripts. Another way you can
use Headless Chrome is through one of these
automation testing libraries and frameworks. And some of these already
have been around forever. Phantom JS, industry standard. Selenium, you can use any
browser and test in your code. A lot of these, for some
reason, are like ghosts. PAUL IRISH: They're getting
into the Halloween spirit. ERIC BIDELMAN: It's
Halloween, that's true. That's very good. I don't know why, but
when I got in this space I was pretty daunted. I didn't know what
each of these did, and what browsers they support. Are they using the headless
version of a browser? So, this is what the Chrome
team saw, and we said, hey let's make at least
testing and controlling Headless Chrome really,
really easy for developers. So no frills, no configuration. And so, this is where
Puppeteer comes in. So, at high, high
level, Puppeteer is just a Node JS library useful
for using Headless Chrome. And by modern,
what I really mean is that we're using some of
these latest new JavaScript features. So, if you check out Puppeteer's
source code, our examples, you're going to see
async/await everywhere. And there's two
reasons for that. The first is, Promises
are actually really nice. So the communicating
with Chrome all happens asynchronously from
Node to Chrome and back again. So, Promises are
crucial for that. And async and await just
cleans all of that up. Makes things a
little nicer for us. But, if you want to,
you can use Node 6, so a really good example
here is if you're in AWS Lambda
functions, or you go on Google Cloud, that doesn't
have the latest Node 8 version installed,
you can actually use Puppeteer with Node
6 without transpiling. No frills, zero config. We actually bundle
Chrome, so we'll pull down Chrome when you NPM
install Puppeteer, this is really nice
because you don't have to deal with those details. You can just write your
code and have it run, and Chrome just
be there for you. It's Chrome's reference
implementation of the DevTools protocol. For anyone that's looked
at the protocol before, it's really big. It's very robust. You can do a lot of
interesting things with it. But we wanted to highlight the
best practices and the really, really, really common things. So, we have high
level APIs for most of the common very
interesting things you can do. So, we are working on this
project throughout the summer, and actually today, or
in the very near future, we're going to be
launching a 1.0. So, if you haven't checked out
Puppeteer, do check it out. This is a great time
to look into it. So, we've got Chrome. We've got Headless Chrome. We've got Puppeteer
now in the mix. DevTools protocol. All these things happening. This is the pyramid
of Puppeteer. How do these things all
line up with each other? So, at the very bottom,
we have Headless Chrome. The browser. A modern evergreen browser. Latest web platform features,
you can test service worker, now you can test
push notifications. That's at our base. On top of that is the
Chrome DevTools protocol. We're not going to interact
with that directly, but that is the
thing that's going to be talking to the
browser and doing things that we want it to do, Puppeteer
is this little library that wraps the Chrome
DevTools protocol and sits on top of everything
below us, and at the very top, that is your unit test or smoke
test, your automation scripts. The scripts you're going
to write in Node JS. So I just want to show
a quick comparison. Don't worry about
this code too much. On the left, you're
going to see how to use the DevTools
protocol, and on the right is the Puppeteer version. We're just navigating to a
page and printing the HTML. It's very simple to do, but
actually pretty complex to do in the DevTools protocol. And this is even a little
bit shorter, I'd say, than it would be if I didn't
use the Chrome remote interface library. So, a couple of
things here, I have to use a couple libraries
to launch Chrome to wrap the DevTools protocol. I have to enable some things in
the DevTools protocol to say, hey Chrome, I'm going to use the
page domain and the run runtime domain. Wait for those Promises,
navigate to the page, wait for the load event,
and evaluate some script. And on Puppeteer's side, that's
just a couple of lines of code. Literally, you can follow
it line by line just to curl the page. All right. Let's see some cool examples. So first, the screenshots. Really, really common
case: first thing you going to do, obviously,
is grab Puppeteer off NPM and require it in your scripts. First thing you do is, you're
going to launch the browser, and Puppeteer has
an API for that. Puppeteer.launch. This is going to return
a Promise that gives you a browser instance to talk to. And, by default, it
launches Headless Chrome, so you don't have to configure
or use any flags here. We're just going to
get Headless Chrome. Next up is, we're going
to create a new page using that browser instance. And, again, everything
is a Promise, so you're going to
see async and await. These are just Promises. If you're not familiar
with async and await. We're going to navigate
to example.com, and then call page.screenshot. That's going to actually
create a screenshot and save it to disk
as example.png. Last but not least,
close the browser. We're done with it,
we've ran our script, we've generated the screenshot. And in literally
five lines of code, we've opened Chrome on any
platform, generated screenshot, and boom, we're
off to the races. So, literally, line by line,
you can tell what's going on, You're not impressed. Just screenshots? Not very cool? PAUL IRISH: I need more. ERIC BIDELMAN: You need more? I have more. So, what else can you do? Well, there's actually
really, really interesting use cases when we have
headless browsing and libraries like Puppeteer. It's not just about testing,
it's about automation, it's about use cases. So, you can generate
screenshots. You can create PDFs. That's pretty cool and useful. But maybe you want
to do something like crawl your single
page application, and render it server side in
the cloud for SEO purposes. You can do that with
Puppeteer and Headless Chrome. Scrape content from sites and
we'll show an example of that, if you just want to
interact with the page. You can automate
form submission, maybe test your accessibility
or keyboard handling using Puppeteer's APIs
in Headless Chrome. I'm excited about
end to end testing, and having the latest JavaScript
and web platform features. So, we can test service worker. Really, really handy if
you're building a PWA. Click page metrics. Paul showed you
that in the DevTools you can do that
programmatically in Puppeteer, Hey, maybe you want to take
another tool, like Lighthouse. You can use Puppeteer
to change a page, modify it, test some
changes, and then run it through Lighthouse andto
see how those changes affect performance. One of the best features is
actually not a feature at all. This is it. Does anybody know
what this means? PAUL IRISH: Purse
foot recycle Chrome. [LAUGHTER] ERIC BIDELMAN: Puppeteer's
logo does look like a purse, doesn't it? That's OK. So, this is my interpretation of
being in lockstep with Chrome. PAUL IRISH: That makes sense. ERIC BIDELMAN: With Chrome. PAUL IRISH: Yeah. [LAUGHTER] ERIC BIDELMAN: So, what
does this actually mean? It's really nice to have the
DevTools team, the people that are building the browser
and the DevTools, be the ones that are
creating this Node library. So, they work really,
really well together. An example, a very common
example actually, someone came to us on the
Puppeteer issue tracker. They said, hey can
I emulate offline? Can I test my service
worker offline? We said no. That's actually a
bug in Chromium. So, we go over the
Chromium issue tracker, file that bug, work
with the Chrome team that was working on Headless. Literally a couple of days
later, the CL goes in, the commit goes into Chrome to
fix this and add this new API and capability to
Headless Chrome. And then, in Puppeteer we
come back, notice that change, and then a couple of days later
we have a new version of Chrome that we pull in, and everybody
gets offline in Puppeteer. So, very, very fast
feedback loop now that we have all these teams
kind of working together. All right. So that's enough talk. Let's see some cool examples and
some of the API in Puppeteer. So, similar to screenshots,
hey, you can create PDFs. I don't know why people
want to create PDFs, but a lot of people want to
create PDFs for their site. PAUL IRISH: It's
so hot right now. ERIC BIDELMAN: So, you
can do that with two, three lines of code. Have at it. Who cares? Create a PDF, emulate a
screen, do whatever you want. The world is your oyster. Some more interesting things,
I think, are emulating devices. So, maybe you want to test the
mobile version of your site. Using Puppeteer's
APIs, you might not know the viewport settings
or the emulation settings for that. We have pre-canned
device descriptors that have all those settings
and widths and everything. Here, I'm just
emulating an iPhone 6 and navigating to google.com. So, maybe I can
screenshot that page, or do whatever I want with it. One really powerful thing
is, you can run code inside, run JavaScript code
inside, of the page itself. So, in this example,
I'm going to navigate to my Twitter stream. Just create a launch command,
get a browser instance, create a new page,
navigate to that page. And what we're
going to do is use page.eval to grab the
first tweet on the page, and then click that tweet. So, this code here,
this callback, this tweet.click is actually
going to get run in the page. It's not in my note code. Next is that we're going
to wait for this overlay, the pop up that Twitter
shows me the full tweet. We're just going to wait
for that DOM element become visible. And then, lastly,
we'll just screenshot. We'll take a screenshot
of that DOM element. So that's pretty cool. You can screenshot a page, you
can screenshot a full page, and you can also
screenshot a DOM element. So, all in all, it
looks like this. We'll navigate to the page. Eventually get to Twitter. We'll open the tweet,
click the first tweet, and eventually, we'll
get a screenshot. So this is the screenshot
that's produced. This is Chewy, by the way. PAUL IRISH: Aww. ERIC BIDELMAN: So cute. PAUL IRISH: Chewy. [APPLAUSE] ERIC BIDELMAN: So, despite
his name he's not seven foot six and 250 pounds. He's very small and very timid. He's learning how
to use a lightsaber, so that's important. So, I don't know if you guys
just saw what we did there, but we actually just
wrote an integration test. A smoke test. For opening a tweet
on twitter.com. You can insert your
favorite framework here. But the fact that we have a real
browser with a real JavaScript engine, a real DOM to test
against, it's pretty powerful. Means we can write some
tests and have them work really quickly. Interception of network requests
is really, really common, a really cool feature of
Headless Chrome and Puppeteer. So using request,
what was it, sent request interception
enabled, we can actually intercept any requests
Chrome makes before it ever makes that request,
and decide what to do based on the
resource type or that URL. In this example, I'm
actually just aborting any requests for images, saying,
hey, I want to test my page, see if the layout looks
good without images. See if the images fail. It's a common thing. I want to know what
it's going to look like. So, I could write a test
for that using Puppeteer. Keyboard input. I can navigate to google.com. I can pull off the
DOM element, then search input, type in the word
Puppeteer using page.type. Click Google search. Wait for the search
results to come. Each of those search results
is an h3 with an anchor tag. I'll just wait for that
selector to just be visible. And then, just run
over those links and print those to console. I'm just scraping content
here from google.com using Puppeteer's APIs. Paul showed you some
really cool things with page metrics
in the DevTools. We can get that information
in Puppeteer as well, just with an API call. So, same stuff is in
both place, if you want to do some
performance analysis. If you're getting
started, Puppeteer, there's a couple of really,
really helpful debugging tips that I just want to
quickly touch upon. Invaluable stuff. So, let's talk about this
launch command one more time. Now, the first
thing is, you don't have to use Headless Chrome. You can just use
"headful" Chrome. Full Chrome. So if you want to, pop on
the headless false flag, and that'll actually show
you the browser window, so if you're writing a script,
this is really, really useful to see what's going on. We have another flag to open
the DevTools automatically. So, that's kind of
useful if you want to poke around in the DevTools
as your scripts are running. Kind of de-bug things
as they happen. Speaking of debugging,
there's two more things. Slow-mo and dump
I/O. Now, slow-mo is something I've been showing
this entire time through all these screenshots. It actually slows down all
the operations Puppeteer does. So it'll slow down typing
as if it were a user. It will slow down navigation
and kind of mimic user behavior. And dump I/O is really
nice because it'll give you extra information from Chrome. Chrome logs a bunch of
stuff, and if your scripts are crashing, that's a
good one to throw on. You don't have to
use the Chromium that Puppeteer brings in. You can use Canary or
dev channel if you want. You can launch your
own version of Chrome, and just do that by
passing in the executable you want to launch. So, a bunch of stuff. Do check out the documentation. There is just an
amazing amount of really easy to use APIs,
offline support, turn off JavaScript, setting view port. A lot of really handy things
you can do in Puppeteer. If you want to check it out
we threw up a site called try-puppeteer.appspot.com. I hacked this together in
a weekend, so if it breaks, please don't yell at me. But this just allows you to go
in, play around with some code, try out our samples. You can see any console
output at the top. And, actually, if you're
generating a PDF or screenshot, it'll show you that at the
bottom to get the preview. Really easy just to try. Not even have to
install anything. So, yesterday, at the
keynote, Ben actually proposed the challenge. And he didn't know he was
proposing a challenge to me, but I went home and
I built this demo. So, this is going to
be Puppeteer Inception. Where you can use Puppeteer
to open the Try Puppeteer site, which is running
Headless Chrome in the Cloud, that runs Puppeteer. PAUL IRISH: Nice. ERIC BIDELMAN: There's
a lot of stuff going on. PAUL IRISH: Love it. ERIC BIDELMAN: So,
let's see that. It's just using Docker
and Headless Chrome. So, I'm going to navigate
to the site using Puppeteer. I'm going to inject
my code, and you see I'm going to navigate
to the site itself and take a screenshot
of what happens. So, eventually, when we hit
the Run button using Puppeteer, we'll get the screenshot
within the screenshot. PAUL IRISH: Pretty cool. ERIC BIDELMAN: And you
can see my arrow there. It didn't move the entire time. That was Puppeteer
doing its stuff. It wasn't me clicking around. PAUL IRISH: So good. ERIC BIDELMAN: So-- PAUL IRISH: Actually,
Eric, can I-- ERIC BIDELMAN: What's this? PAUL IRISH: Yes, please. ERIC BIDELMAN: Yeah, thank you. Thank you PAUL IRISH: I love it. [APPLAUSE] I'm going to say I
wanted to interrupt you for just a second. You were talking about the
DevTools protocol a second ago. ERIC BIDELMAN: Yeah. PAUL IRISH: And it
reminds me, there's something about the protocol. If you've ever attached
something else to Chrome, like VS Code or
WebStorm, or Selenium, and you've been working with
it, and then you open DevTools, you've seen that other
tool kind of disconnect. Right? Like you can only have
one connected at a time? This is admittedly a bug. Actually, it's our
number one bug. And, so, it's a
little interesting. So, I'm just going
to go and actually just take a look right now. OK. So, so we have 124,
1200 stars on this. It's a lot more than-- PAUL IRISH: Very
disproportionate. PAUL IRISH: In, fact all of
Chrome bugs, It's number three. The worst part about this
is that it's assigned to me. Yeah. ERIC BIDELMAN: Since 2012? What have you been doing? PAUL IRISH: Not ideal. ERIC BIDELMAN: What? What? PAUL IRISH: Yeah. But-- ERIC BIDELMAN: Shameful. PAUL IRISH: We got good news ERIC BIDELMAN: Yes. PAUL IRISH: Good news is,
multi-client remote debugging support is now fixed. [APPLAUSE] PAUL IRISH: This is so good. ERIC BIDELMAN: That's cool. The great thing
here is that nothing to configure on your side. Everything just
works automatically. Having DevTools open,
plus any of these things or even two of these
tools together, two different things that
connect to the protocol, all good, all works. It's awesome. And so, now that
that's done, actually we have something
to take care of. Let's see. We're just going to-- ERIC BIDELMAN: Yeah. PAUL IRISH: It's probably
time that we close this bug, mark it as fixed. And hit it. Yes. Go! Go! ERIC BIDELMAN: Thanks,
Paul and DevTools team. [LAUGHTER] [APPLAUSE] PAUL IRISH: Yes. [APPLAUSE] ERIC BIDELMAN: That's awesome. PAUL IRISH: Feels good. All right. ERIC BIDELMAN:
What's the next bug? Now on to the next one. [LAUGHTER] ERIC BIDELMAN: Job well done. So, with that, sorry
for going over. Hope you guys
learned a lot today. We did cover a lot in
a short period of time. Here's all the resources: the
GitHub report for Lighthouse and Puppeteer, Headless
Chrome article, DevTools protocol if you
really want to get low-level. That Chrome launcher module. I think that's it, right? PAUL IRISH: Thank you all. [MUSIC PLAYING]
