>>Tom Wiltzius: Hello, everyone. I think we're ready to get started.
Welcome to Jank Busters. I'm Tom Wiltzius. I'm a PM on the Chrome graphics team.
>>Nat Duca: I'm Nat Duca. I'm a graphics hacker on the Chrome team.
>>Tom Wiltzius: And we're here today to talk about Jank on the web, what it is and how
to avoid it. >>Nat Duca: Yeah. So Jank. Everybody has a
screen in front of them, probably. Jank really begins with the monitor, right? You've got
this monitor in front of you and it's designed to sort of trick your eye into this illusion
of motion, and the way it does that is by updating a frame every couple milliseconds,
right? And the trick is, your eye wants to go at
something like 40 hertz, and if you do that, then you'll perceive motion.
And so monitors out there go anywhere from 30 to 50 to 60 to 70 hertz, right? And if
you manage to get all of your JavaScript and all your different pieces going at that rate
of the monitor, then you can present this illusion of smoothness and then people are
happy. >>Tom Wiltzius: But if you don't manage that,
then you end up with Jank. And this is what we're talking about when we're talking about
Jank. It's anytime that you don't get a new image
on the screen every time the monitor refreshes. This comes in all sorts of formats. A hitch
is when we miss a bunch of frames in a row. A low frame rate is when you're taking out
a frame every maybe fifth of a second instead of every 50th. A variable frame rate is maybe
some combination of these things. And this is particularly painful when you're trying
to interact with something. So here's a div with a bunch of Chrome logos
moving around and it scrolls sluggishly. It's what we call a Janky scroll. And the problem
here is that as I move my finger on the trackpad, I'm scrolling around in this little iframe
but the frame rate isn't matched up to the monitor's refresh rate, and as I move my finger,
I don't get the smooth motion on the screen that I sort of expect.
And so the physical metaphor is broken and it doesn't -- it doesn't feel good. It doesn't
feel fluid. >>Nat Duca: Yeah. So, you know, basically
what's going on behind the scenes when you get dropped out of your experience and you
get something like Jank is one part of the rendering pipeline is getting behind, right?
Now, if you go on line and you look at our talk from last year's I/O and also a lot of
great resources out there on Jank busting, you'll find that there's this great feature
in DevTools called the frames mode. It's in the Timeline. And you can use that to record,
basically, an interaction with your page and see, for example, "Oh, hey, this frame ran
long because of JavaScript." And there are just thousands of things that can go wrong.
CSS can run long. You can have an XHR that comes back and does some big json parse. You
can have an image decode that fires. You can -- you know, I can go on for hours on this,
you know. >>Tom Wiltzius: What Nat is trying to say
is there's a lot that gets in the way of the 16 milliseconds you have to make a new image
before the monitor refreshes. And there are, as Nat says, lots and lots of ways that this
can go poorly but today we're going to talk about one kind of specific category and that's
what are essentially the green bars in the vertical Timeline in DevTools.
This is what we call sort of rendering, but that breaks down into painting and compositing
and we're going to talk about both of those in today's talk.
>>Nat Duca: And it's good that Tom saved you from me yammering on because you'd just fall
asleep and be wasting your time. [ Laughter ]
>>Tom Wiltzius: So rendering, what are we going to talk about today? We're going to
talk about painting speed, what -- what kind of goes into it and how you can try to paint
as quickly as possible. But then even better than that, we're going to try to talk about
how you can avoid painting in the first place, either because you were doing so accidentally
and you didn't realize it -- and we're going to show you how to notice that kind of thing
-- and then better yet, we're going to talk about how to deliberately avoid paints from
the get-go when you're designing your application. >>Nat Duca: And there will not be a rocket
ship that we can give you at the end as a takeaway, so sorry.
The beginning building block of rendering in a web browser is preparing pixels to be
put up on the screen. So if you go to Google -- right? -- we've
all been there, you're presented with this, which is the nice little happy hello Google
thing, and you get a blinking cursor, right? Where the only difference between the page
over time is the cursor coming on and off. Now, what Chrome's doing behind the scenes
is it's actually filling in those black dots for the cursor itself, and what it's doing
is it's got some, you know, logic in it that says, "Ooh, this part of the page has changed.
I need to refill those pixels with black or I need to remove them."
And so you get this little update req, this painted area on the screen that we repaint
and then you see this illusion of a blinking cursor.
Now, if you think about that, that takes some time but it's probably relatively little and
if I compared the time taken to blink the cursor versus, say, if I just had the whole
Google logo blinking -- now, of course people would be upset if I did that to our home page,
but also, it would take more time to do it, okay? Because there's just -- you can sort
of think about this. This is intuitive. We have to touch more pixels, right? So that's
one dimension of rendering performance and in particular painting speed, is how many
pixels you've touched. But that's not the only dimension, of course.
The other part that matters is what you touch and what type of content is in the area that
you're updating. So if you take this white block on the upper
left, that's just white. And if you think about what Chrome has to do to make those
pixels white, it just has to sort of put RGBA for white into a bunch of parts of memory.
So that's a mem set and it's pretty darn fast. In contrast, the "I'm Feeling Lucky" button
has all sorts of nasty little details on it, and it's actually kind of fun to zoom on this
on a computer with a magnifying glass and see all the things going on there. If any
of you have actually taken like an undergrad graphics class and had to write like a line
drawing algorithm, imagine having to do that in Chrome but where you also have antialiasing
and rounded corners and blurs and text and anti-alias text. It gets really hairy and
it's sort of the thing that makes you want to jump off a, you know, cliff, but it's also
the thing that makes the CPU chug along. So painting is a slow thing and it's something
to be avoided pretty much at all costs. >>Tom Wiltzius: And you want to wonder probably
like what -- what is expensive and what isn't, right? Like Nat is just asserting that like,
oh, drawing his NTOS lines is expensive, but in an ideal world you would be able to measure
this kind of thing. And this is something that DevTools does allow you to do to a certain
extent. A good question to ask is like, "Well, which elements on the page are expensive?"
And a good way to measure that is with continuous painting mode in DevTools, which is a DevTools
setting that we're not going to talk about in great detail today but there are some really
good resources on the web about how to use it. This link -- and our slides will be linked
on the web later -- will take you to an article that explains in detail how to use continuous
painting mode to repaint the entire frame as fast as possible and tell you how long
that takes and then you can hide certain elements and see how does that affect the painting
time. Because often as not, it's a single complicated element that's taking all the
time. >>Nat Duca: When you look at your page, look
at all the pieces and keep in the back of your head that not all of them are the same
cost and you're paying for some of those effects more than others. And if you start getting
in a situation where you see painting, start figuring out which ones you're paying for
and whether you really want to be paying for that bill for that one.
>>Tom Wiltzius: That's right. Painting also, I should say, isn't -- it's not just about
the blinking cursor, right? In the blinking cursor case, it makes sense that we need to
repaint like the part of the screen that's changed because the pixel output is different.
But there are plenty of cases on the web where even if you change something that doesn't
have any sort of material impact on the final presentation of what goes up on the screen,
you can still incur a costly repaint, and we're going to show a small demo of that right
now. If I hit this button, I get elements that
are added to this screen. It's -- this is really simple. These are just gray divs. Basically
styles, right? >>Nat Duca: Winner of Web Site of the Year
for 2013. >>Tom Wiltzius: Thanks, Nat.
>>Nat Duca: Because you're good. >>Tom Wiltzius: And what we want to do here
is get some insight into what is being painted when by the browser.
So if we open up DevTools and we turn on show paint rectangles under the rendering heading
of settings, then we have -- we have the ability to really see what gets painted as the page
changes. So again, I'm going to hit this button a few
times and you can see that as I add additional elements, there's a red -- red rectangle that
flashes over the element and that red rectangle means, "This part of the screen just got repainted
by Chrome." Or really by Blink in this case. >>Nat Duca: So that's that rectangle that
I was showing you in slides but in runtime for your production site.
>>Tom Wiltzius: That's right. And I can keep adding elements, and now I'm adding elements
like way below the fold of the page and you can see that as I add more, the only thing
that gets repainted here is the button, because it ends up in this depressed state and then
comes out of it, and the scrollbar, because the scrollbar size is changing.
So this is great, right? And it makes sense in some sort of basic logic that as you're
adding elements below the fold of the page, you're not having to repaint anything that
is on the page. But it's not always that simple. If I try to do something like inspect this
container block -- and the DevTools inspection is going to drive the paint rectangles nuts
a little bit, but if I look at this block that contains all of these elements and then
I toggle, say, how much padding there is on the right side of that container block, I'm
not going to end up with any, again, visible change to what gets rendered.
These divs are sized such that even if there's an extra 10 pixels of padding on the right
side of that container, the layout is not going to change, nothing is going to look
any different. But watch what happens when I add some of that padding. You can see in
-- it's probably small text, but padding has showed up in the element style in inspector
and I got this big red rectangle that flashed over the entire container. And the reason
is that Blink, I mean, it's not that smart, right? And so when some of this padding got
added, there was a series of steps that it went through that said, "Okay, now I need
to think about do I need to recalculate the position of any of the elements inside of
this container block?" The answer ends up being "no" but in the process,
it invalidates the -- the sort of visible state of all of these elements on the screen
and then they all get repainted. >>Nat Duca: Yeah. Blink has a well-meaning
but sometimes confused brain and so, you know, in this case it's getting confused. It thinks
that maybe something bad is about to happen and it causes a repaint. And this is the sort
of thing that actually happens more often than we'd like.
When you use and write really nice modular code that's beautiful and has all sorts of
awesome design patterns in it, sometimes this sort of thing will creep in because somewhere
deep in there somebody added a class and then removed a class somewhere else and that confused
the system. So this is something to keep your eye out for when you're doing sort of day-to-day
production. Keep an eye out for these erroneous blinks where you would expect there to be
no red flash and there is. Because once they start creeping in, they're really devilishly
hard to stamp out again. >>Tom Wiltzius: Very true. So switching gears
a little bit, we've talked about painting now, but the -- the next best thing from trying
to avoid unnecessary paints is to not paint at all. And Nat's going to talk a little bit
about how we do that for common cases like scrolling.
>>Nat Duca: So like in ye old days -- right, like 1990 something, the way that we would
scroll a page in a browser was we would repaint parts of it. So we would move bits of the
pixels up using some low-level things, and then we'd do a big repaint rectangle on the
area that you'd exposed from the scroll. Now we just talked for, you know, a while
about how devilishly slow painting is and how it should be avoided. So developers in
both, you know, Webkit and Blink and Chrome and pretty much everywhere have adopted this
new notion of a layer. If you look at this picture we've got up of
Gmail, the analogy is this: If I look at Gmail, I know that there's a part of the page that's
just going to move up and down. It's not going to change visually. It's just there are going
to be new pieces shown that weren't previously visible. Right?
But the stuff on top of it, the -- the top nav and the left thing, they'll always be
there. And so there's this sort of idea of "Hey, we will detect that using semantic cues
in your thing like it being an overflow div and we will turn those into layers and each
layer becomes a picture that we upload to the GPU on your computer, store there, and
then if the thing that you're doing to your page is just moving the layers around, we
can ask the GPU to scroll it for you." Or, in fact, reposition it and then ask the GPU
to recompose them. And so it looks like you're scrolling because you're only looking down
at the layers. You just see it -- you know, it looks like you're seeing the whole Web
page. But what's happening underneath is the browser is just re-compositing, skipping that
expensive paint step, and going nice and jankfree. But this all depends -- this jankfreeness
is all predicated on you getting good layers in the first place, and if you don't get those
layers created, things can go a little bit haywire.
>>Tom Wiltzius: That's right. It's also predicated on not like the good layers. It's predicated
on the layers being set up in such a way that we don't need to paint them, right? Like if
the layer content is changing, then all bets are off on this being a good system. So I'll
open up another demo, and this one -- maybe it will load...
You want to turn off -- >>Nat Duca: I will turn off WiFi.
>>Tom Wiltzius: -- WiFi and try again? In a case where we scroll -- in this case,
a whole long list of images, we can -- we can do that pretty well, right?
Nothing on the page is changing here. This is really a simple sort of like static media
site scenario. And indeed, we can scroll this -- this quite well.
This whole sort of body of the page is in a layer. It's being re-composited every frame.
>>Nat Duca: We shall bless this jankfree. >>Tom Wiltzius: Right. But if I open up DevTools
again and I turn on show paint rectangles, as I had, then you can see that part of the
kind of jankfreeness here is that nothing is being repainted. The only thing that's
being repainted is, again, the scrollbar so we can kind of afford.
>>Nat Duca: So we're keeping that contract with the browser: I won't repaint and you'll
be jankfree. >>Tom Wiltzius: That's right. But if I hover
over this image, I've got actually kind of like a nice animation that happens. I add
a shadow, I change the opacity, I brighten the image a little bit. This is the kind of
thing that's become increasingly common. And as I do that, you can see that because it's
sort of a complicated animation that Chrome doesn't accelerate very well, I get a lot
of repaints throughout the course of the animation and that's those red rectangles flashing over
the animation again. But that animation is going to play really, really poorly with the
scroll, and you can probably guess why by now, based on everything we've just said.
The -- the browser is going to start repainting to run the animation right at the time when
it -- what it wants to be doing is re-compositing this static unchanging content over and over
again in different positions. But if the content's changed, then it can't just reposition it.
It needs to repaint it first, re-upload it to the GPU, and then re-composite it. You
lose all the benefits. And indeed, if I try to scroll with my mouse over here, the resolution
of this screen is hurting me a little bit, but it gets a lot Jankier, and you can see
that these are these big red flashes that occur all over -- all over the page and that
gets in the way of sort of a jankfree scroll. >>Nat Duca: Yeah. So these big red flashes
are your warning to -- you know, your one-way trip to Janktown, right? You've got big red
flashes and you're basically going to start repainting all the time and then on a low-end
machine -- this is a Mac Book Pro so of course it's going to be in better shape, but on a
lower-end machine especially you're going to really start paying dearly.
>>Tom Wiltzius: This is the type of thing that we see as particularly painful on like
phones or tablets. In this case, I mean, getting rid of the hover effect is a relatively simple
task, right? So if I uncheck this box, there's a scroll handler here that will disable the
hover effect when it first runs and then sets a timer and 200 milliseconds after the final
on-scroll event, it will re-enable the hover effects. This means that I can start scrolling
and the hover effects get disabled and no repaint is happening during the scroll but
then as soon as the scroll is done, I still get my sort of nice animation.
>>Nat Duca: And this is sort of your instant recipe to making it smooth, right? Is if you
are willing to compromise on some of those gorgeous hover effects or whatever it is that
is causing your repaint in the first place, if you're willing to reduce it during the
scroll or simplify your content in some way, you can go nice and fast again.
>>Tom Wiltzius: That's right. I mean, this is changing the behavior of the page, right?
And that's not always going to be acceptable to you. So it's important to understand that
there are often tradeoffs between how well something performs and what it looks -- what
it looks like, but it isn't always going to be possible to achieve whatever sort of like
crazy effect you want in a -- a totally nice performance way.
We're sort of picking on hover here, but really there are all sorts of things that can cause
this sort of problem. The -- the real thing you want to do is use
show paint reqs to sort of look for these big red flashes during your scroll or during
your animation and then try total rid of them. So hover effects are one thing to look out
for but there are a lot of others as well. Common problems come from fixed-position elements
or overflow scroll divs or touch listeners, mouse wheel events, trying to reposition things
in an on-scroll handler for like paralax effects sites. These are all things that we see that
-- >>Nat Duca: Social widgets that you position
when people hover over an article and stuff like that. Like give the pages a chance to
settle before you bring in your, you know, +1 button, right?
>>Tom Wiltzius: Right. Which is not to say that like these things are bad, right? It's
just that you need to be aware that in sort of liberally using them, you may end up in
a position where you really end up fighting with the rendering system and the performance
is going to go through the floor. There are cases where you really do need that paint,
though, you really do want something to change accident occurring a scroll, and that's fine.
If it's fast enough, you can still be Jankfree, right? But you're going to have to be very
vigilant about keeping paint as cheap as possible. For this, you want to be paying a lot of attention
to how visually complicated your CSS is and continuous painting mode that we plugged earlier
is a good way to try to reduce the cost of a lot of those paints. Image decodes and resizes
can be really painful. If you're on a media site with tons of images, you can blow the
image cache inside of Blink and that can be really painful.
>>Nat Duca: Constant vigilance. >>Tom Wiltzius: Constant vigilance is the
answer, yeah. But now Nat's going to talk about some of the other great applications
of layers. >>Nat Duca: Well, I think we've got another
demo for you which is always fun, more fun than us talking but, you know, here's the
thing. We showed you how you can use layers to scroll smoothly, right? And that's -- you
can sort of understand that, when we're moving something up and down. But people like, you
know, drawers and -- and hover effects and, you know, slides that -- that zoom in from
the left, right? And this is a really cool thing. There are
some amazing things you can do here. But the way to make it fast versus the way that you
encode it up quick are often not well aligned, so it's very important when you do sort of
animations to also think about layers and also think about how can I construct this
animation so it plays well with Chrome's layered rendering model, not fights against it.
>>Tom Wiltzius: Right. And a lot of that comes down to how can I run this animation without
incurring any paints. So here's a really simple drawer. This is styled like incredibly plainly,
but you can see that if I open up DevTools and I have show paint reqs on, that as I run
this animation, which is a simple CSS animation on the left property -- right? -- like very
basic, I get repaints of the drawer throughout the entire animation. That means every frame,
this entire part of the screen is being repainted, re-uploaded to the GPU, and re-composited.
And that's, again, relatively painful. >>Nat Duca: And if you take that to a low-end
device, it will be worse and worse and worse. Six times worse, often.
>>Tom Wiltzius: Right. So the question you want to be asking yourself is, "okay, like
how do I get around this? Like how do I avoid these red rectangles?" And it so happens that
one good way to do so for moving things like this is with transforms, through CSS 3 transforms,
rather than changing the position property. Transforms take elements out of the flow of
the page, which gives the browser some stronger guarantees about what it can move without
risking having to reflow other elements. >>Nat Duca: This is an example of not all
-- you can make the same look in CSS with different types of selectors or different
types of attributes and get the same visual look. But it is going to perform totally differently.
>>Tom Wiltzius: Chrome has all these fast pass. But you kind of need to find them, which
can be painful. If I use a Webkit transform here and a translate X, I have this comparatively
much nicer animation, right? You can see it is a little bit smoother if your eyes are
attuned to it. But the really nice thing is I'm not getting any paints, there is no red
rectangles throughout the animation. There are red rectangles at the beginning and end,
though. And we will talk about those next. >>Nat Duca: If you get somebody who stamps
out that first bit of animation and Tom comes over to me and says, I got it! I got it! We
just have red flashes getting in. It is not good enough. Never, ever paint. That's what
we are looking for. Not, oh, I reduced it a bit. It's, Don't paint.
>>Tom Wiltzius: We are standing up here stating that this thing is now fast because it is
in layer. You shouldn't take our word for it. You should want to look for this yourself.
The way to do that is to open up DevTools again, turn on show composited layer borders
in DevTools settings. And if you look really carefully -- I will zoom in here -- there
is an orange border that goes around the edge of the page and that orange border is your
cue that says, The content inside of this border is in its own layer.
You can see there is only one orange border. It is probably hard to see from the audience
on this screen. >>Nat Duca: Trust us.
>>Tom Wiltzius: There is only one orange border on this particular page because there is only
one layer. Again, look really carefully. I will zoom in again. Look really carefully
at the edge of the drawer as this animation runs. You can see that there is another orange
border that pops up along the edge of the drawer during the animation. And that's your
sign that says, Oh, this content actually got promoted to its own layer and now it is
being moved back and forth, which is great. But the question is: Why the red rectangles
at the beginning and end? And if you look carefully, maybe you can guess
why. There isn't an orange border before or after this animation runs, right? So what's
happening is that the layer that the drawer is in during the animation doesn't exist before
or after the animation, right? So the animation starts. We pop the drawer
out. Put it in its own layer. It is a new layer so we need to render its contents, right?
That's the first red flash. Then we recomposite it, recomposite it, recomposite
it, move it all the over and pop it back into the base layer. And when we pop it into the
base layer, we need to repaint that part of it. That's the second red flash.
How do we avoid this? One way is sort of incidental. If you use a translate 3D instead of a translate
X, you get a layer even when the thing isn't moving because it will be promoted to a layer
not due to the animation but due to the CSS transform itself.
If we try that and run this animation, you can see that I can now run it back and forth,
no red rectangles. >>Nat Duca: Look, Ma, no red flash, right?
>>Tom Wiltzius: That's great. That's kind of what we want. And if I open up the timeline
view, we talked about vertical timeline earlier, usually you would see all sorts of paint events
and stuff, right? But if I start a recording and run this animation, you can see that throughout
the animation, all we get are these composite layer operations over and over and over again,
which are comparatively super, super cheap. That's really good. This is the ideal timeline
case where, yes, things are moving but there is a minimum of other stuff going on. So that's
drawers. But sometimes this isn't quite enough. Sometimes
just seeing those borders isn't enough to tell you really what's going on, especially
if you have really complicated animations, et cetera. These are contrived examples. It
is easy for us to come up with a demo. You are trying to debug a site or an app on a
phone in production, there can be lots of stuff going on. There can be all sorts of
layers all over the place. And you can be trying to add more but that's only causing
you to have too many. Maybe you are running out of memory. All sorts of things can go
wrong, right? So Nat's going to talk a little bit about
what to do in those more advanced scenarios. >>Nat Duca: What we are going to do now is
we're going to take the covers off of an internal tool we have been developing in Chrome to
show the nasty innard guts of the compositing system, which is this thing that makes things
Jankfree. As you see this, keep in mind basically this
is very, very brand-new. And it is designed for developers first, but we wanted to show
it because this shows you exactly why things really are slow. The way it works is you get
a relatively current build of Chrome and that will probably be like Friday's build, not
today's. So that's how new it is. And you pop over to your site that you think is Janky.
So I'm just going to start with something really simple. This is just a tall site with
some As in it, right? Really bringing out the good content for you guys.
[ Laughter ] Remember, we showed you the picture of Gmail,
right, with it broken out in layers. You go over to tracing, this Chrome tracing thing,
and you start it recording. You go back over to here and you do your thing,
whatever that thing happens to be. Just like in Timeline.
What you are going to be presented with, once it does its thinking is something that should
actually remind some of you of Android systrace in sort of appearance.
What you are seeing here is these all the different times my finger was moving on the
track pad causing it to scroll. And the nice regularity of that that should scream out
Jankfreeness right away. Each one of these green dots are the things
you really want to click on. Everything else is sort of side show.
The green dot represents Chrome drawing one frame up onto the screen. That's kind of where
the meat is. Down here you have got -- in the center here,
you have got a list of the layers on the screen on that frame. There's two. There is this
one which is shown over here. You can see that's the really tall page. You can see that's
the whole darn page. Then you have got this thing which is tall
and narrow. What is that? That's the scroll bar. It is that little thing. Even on Mac,
we have it, even though it is transparent. That's sort of the shape of the page.
The thing you want to then look at as I go from frame to frame, see this thing over here,
this is our mini map. As you go from frame to frame, you see the green thing which is
the layer moving and that's the scroll happening. The blue represents the viewport. So just
like in the Gmail example where we showed the Gmail thing -- the mail list moving and
sort of this hole where the viewport was looking, this is the same thing but from my live site.
This is kind of -- you can sort of start thinking, this is kind of useful.
Hey, that's a big picture. I wonder how much memory it is using. We have a lot of people
who worry about that, where they say, These layer things are great but they are eating
a lot of memory. You can actually click now on this and see
the actual bytes consumed by that layer. It is like 7 megs, something like that.
And I'm beeping. That was fun. [ Laughter ]
So that's the most fun part of the talk. You can actually get the actual memory consumption
from this tool, which is super useful when you are trying to take your site which is
layer heavy, for instance, and bring it to a phone, which is constrained. Remember, we
had this demo up, right? This drawer. And Tom was saying, trust me, there is a layer
there. Don't trust, measure. So we are going to reload. I'm going to set
it to do the thing where it was popping in and out and we are going to do the effect.
Same old thing. And we wait for it to do a bit of a think. You can see again there is
two big bursts of animation which is when the rendering system was active.
I click here. Let's pick that frame. You can sort of see this, right?
There's my page as before, right? There is the drawer on the left.
And then there is this big stall here. It is Jank. When I click here, you see that it
is gone. There is a hole. where did it go, right? Now you see there are two layers instead
of one. This is the root layer, and that's this newly
created one. And that got painted. We paid to paint that and pop it out.
And we also paid to paint the other layer to create the hole.
Now you see on the left in the mini map that drawer starting to slide in under the viewport.
So now it is sliding in, sliding in and it is good and we are happy and it is 60 hertz
and it looks smooth. Toward the end, what you are going to see
is it smoosh down. So here -- from here to here, you see that we have two layers like
this still. And then in the next frame, it is smooshed down to one.
Ah, right? So then we paid yet again to paint it. We didn't pay so much of a painting penalty
this time, but maybe on a lower-end device, we would have. If you scroll down, you can
see the painting activity taking place. One other final thing to show about this tool.
A lot of people wonder when you get a big -- big site, big production site where there's
a zillion things going on, you get a ton of layers. And you are like: I didn't ask for
this. Why is this layer promoted? So if you actually look down at the bottom
of this thing, you can see this compositing reason. This so no promotion reason given.
But if I click on this one that's moving, it is using accelerated animation. That's
your key to then start understanding, Hey, maybe I should keep this promoted for some
other reason, too, so it stays promoted afterward. And so when we turn this on and do a trace
of this with the real -- that final demo that we say was Jankfree, you will see that, then,
has several promotion reasons that keep it promoted the whole time.
So this is sort of the low -- the quick glimpse into a tool that we are trying to get out
there into people's hands so when you are really under deadline and you need to make
something Jankfree that's in your available in your arsenal to help with.
>>Tom Wiltzius: It is as Nat said super, super new. We have some nascent docs up at this
link. And we do encourage you guys to maybe in the next couple weeks go try it out as
it lands and starts to stabilize. But for sort of advanced use cases, this is
-- >>Nat Duca: You can get very far with DevTools.
This is if -- if you are in a pinch, you can check this out. You will be confused, but
it will help. >>Tom Wiltzius: That's right. But for starters,
as you sort of begin down your journey towards fighting Jank, you want to use DevTools. You
want to turn on Share Paint Rectangles every time you see Jank sort of crop up in the wild.
And you want to look for what is repainting and try to figure out why.
You want to ask yourself why -- why am I repainting this? And can I either avoid it by being judicious
and not changing style when I don't have to or by using layers or some combination of
the above. And if you can't avoid it, you want to make
it as fast as possible by using continuous painting mode that we talked about earlier.
>>Nat Duca: There are a lot of great tools. The thing to keep in mind, if you walk away
with nothing else in your take-aways is this, all the browsers are basically building something
around layers. Think about doing your effects, your awesome
immersive Web experiences in terms of layers. Think about whether you're designing for that,
try to reduce paint. And if you do, the browsers will pay you back
in scores with Jankfreeness, smoothness, right? And if you don't, then you are going to be
fighting the browser. It is going to be doing its best, but you are asking it to do a hard
thing. So happy Jank busting. [ Laughter ]
>>Tom Wiltzius: I think we're going to take a few questions because we have some time
left. But if you are hungry for more, we've got sort of a collection of links and articles
and whatnot up at jankfree.org. It is just sort of a dumping ground for us. And that's
where we are going to put these slides as well.
If you take away one URL from this talk, it should be that. And you can get to everything
else from there. Html5rocks is the Chrome developer relations Website about this kind
of topic. So you should definitely go check that out.
We will continue putting up content about this topic. Go check that out.
Our contact info is up here, too. We are happy to talk about things like this if you have
interesting cases that you want to sort of bring to us. We also welcome bugs on the Chrome
bug tracker. With that, I think we will take some questions.
Thank you very much. [ Applause ]
>>> Hi. So it seems like layers are really important. But right now, it seems like you
kind of have to do a snake dance to figure out or make something into a layer.
>>Nat Duca: I like that expression. >>> Does it make sense for there to be an
explicit style declaration to say, Hey, I know how I want to composite my page?
>>Tom Wiltzius: Right. >>> Let me turn this into a layer, just like
Webkit layer, whatever, make this into a layer, yeah, almost like Z index. Is that coming?
>>Tom Wiltzius: Right. I mean, it is a good question. It actually comes up a fair amount.
It is something we've resisted because, like, in general, there is resistance to adding
APIs to this. >>Nat Duca: One of the great things about
the Web is that your content can run pretty much anywhere. And, remember I showed you
in the demo that these layers take memory? If you start telling Chrome to use a layer
for that, then you run into the situation of it might fit on your high-end computer,
say, a Pixel, but then it won't fit on an Android device.
And at which point, what are we to do? If you start making assumptions about this definitely
being in a layer and we can't fit it in memory, what are we going to do?
I totally get where you are coming from. This is something that we as a community, the Web
community, need to really tackle in the next couple of years, of how to improve the statement
of intent. But we also have to think about as we do that,
how to make it work and preserve sort of that promise of the Web where it just sort of works
everywhere. Does that -- >>Tom Wiltzius: I think the intent --
>>Nat Duca: Is that responsive? >>Tom Wiltzius: The intent point is a good
one, right, because, like, in some ways, the layer concept, like, it is kind of an implementation
detail. And that's not the kind of thing we like to codify with syntax, right?
Instead what we want to codify is stuff about intent, right? So things that, for instance,
the Chrome Compositor is good at right now is moving stuff around, changing opacity and
sort of doing this 60 times a second. And there actually are semantic ways of declaring
all of these things. If you declare them, Chrome will do the right thing. Those things
get layers and those things get hardware accelerated. I think that's probably more the direction
we want to go. Otherwise, you will try to end up in some senses abuse it, right? You
will try to trick the compositor into doing things that it is not really designed ed for.
I wonder -- I don't know. I wonder if we will end up in a worse place --
>>Nat Duca: TLDR hard problem. And if you have any brilliant observations, come grab
us. >>Tom Wiltzius: We will be in the Chrome performance
area later, too, if anyone wants to talk. In the front.
>>> I was just wondering if this tool is available on Chrome for Android?
>>Tom Wiltzius: Sorry, can you repeat the question?
>>> Is this tool available on Chrome for Android? >>Nat Duca: The last one will work on Chrome
eventually. >>Tom Wiltzius: All the DevTools stuff, yes.
The last sort of advanced tracing tool doesn't work yet.
>>Nat Duca: It will come. >>Tom Wiltzius: It should.
>>Nat Duca: It is all sort of common infrastructure. >>Tom Wiltzius: The basic tracing does work
on Android. The more advanced features to view frames doesn't work.
>>Nat Duca: Haven't tried it. It might work. We'll see. But it is all one big happy family.
We all think about all platforms. >>Tom Wiltzius: We work across.
>>Nat Duca: If it is not working today, it will be working very soon because we want
-- our whole vision here is you write your Web platform thing and we will take care of
all your OSes for you, module a few details. >>> So instead of asking for a layer, is there
a possibility of getting, like, an experimental no-paint attribute, I'm sorry, suppress paint
while we move stuff around? Because sometimes it is kind of like you have to hold the old-style
TV antenna up to get the right -- it is like: Did I do the right thing to kick the compositor
just the right way? If we had attributes that, seriously, we actually
know better than you, don't repaint this, it might help some edge cases we have.
>>Nat Duca: There is a proposal floating around for, I believe we are calling it, prepainting.
And if you look on one of chromium's graphics development mailing lists, you will find a
discussion about it. And I think we intend to broaden that discussion in the coming months.
But this is about being able to say, hey, I'm bringing -- So, think about infinite scroll.
You are adding elements to the bottom. Hey, Chrome or, hey, browser, I'm adding this image
but, like, if you can't put that up in time, no big. I'll put in a placeholder or something.
So, hey, this is optional. And please let me know when it really is there so I can get
rid of my placeholder asset. That's being discussed. I think it may be
abusable for the other things you are thinking about, too. That actually feels relatively
within scope of the platform, I think. We'll see.
>>Tom Wiltzius: I think there is also room to do that kind of thing higher up the stack
before we talk about painting. Like, really what you want to do is declare -- is sort
of make a promise to the browser that you're not going to do anything that's going to manipulate
style or layout inside of -- sort of a container block.
If you can do that, then, like, further down the stack where we are talking about, we can
do the right thing and not paint. But there is some efforts going around things
like that, too. >>Nat Duca: There is a lot of discussion here.
We're definitely -- please, come on up and we can chat if you want. There is a lot of
discussion in the team about how to basically say to the platform, Hey, I solemnly swear
I'm up to good. Now get out of my way. We know it is not good enough yet.
>>> Any love for SVG -- Jankfree SVG any time soon?
>>Nat Duca: Oh, totally. Definitely. One of the people helping build that tool that we
demoed is one of our SVG awesome peoples. >>Tom Wiltzius: Definitely important. The
summary is yes. It is a little harder because of the way SVG works. Gloss over that.
In front. >>> Jankfree is awesome especially considering
how poor performance still is six years into smartphones on smartphones.
>>Tom Wiltzius: Totally. >>> But I can't help but look at these demos
with "Oh, make this translate and then make this a 3D translate" and think about people
who used underscores for their CSS variables to make IE7 not look at that one and look
at a different one. It feels like we are introducing another Web
development snake dance. And I wonder if there is anything we can do to mitigate that to
make -- to think about our codebases as something that's going to live for longer than the six
months that I'm on this project and make it easy for people to maintain down the line.
>>Tom Wiltzius: Absolutely. That's kind of the reason that we were saying what we were
in response to the first question about, like, Oh, can we have a primitive for layer promotion?
And the reason that there is hesitancy to do that kind of thing is because again so
directly targeting implementation details of the browser, you end up in a world of pain
later where, oh, I don't care about IE7 so much anymore but now my codebase is all kind
of split up because of that. That's the kind of thing we don't want to
do. We want to stay as semantic as possible so future versions of the browser don't need
to handle these kind of weird cases that were targeted very much at implementation.
>>Nat Duca: But if there is one thing to keep in the back of your head, it's this. Probably
for the next couple of years it is going to be messy. So having your infrastructure on
your project be set up to deliver custom CSS or in some way handle special casing for different
browsers is probably the unfortunate reality of our platform at this time.
That really stinks and we all know we need to do better. But you find quirks that you
need to apply for Safari different than, say, Chrome, that are different from the old Android
Web view or something like that. I would plan for the possibility of needing
to do that. How are we doing? We got probably one more
question. >>Tom Wiltzius: One more minute.
>>Nat Duca: Especially as we are long winded. >>> Hi. You talked about permanent vigilance.
Can you tell us how Google internally spots these? Whether you have got automation tools
to assess when things have got worse so that we cannot depend on developers being vigilant
because they will be distracted by other things as well?
>>Tom Wiltzius: Yeah, sure, Nat built some of them. So I will let him --
>>Nat Duca: What we are starting to use, Go Google Chrome telemetry. It is a framework
built in Python on top of DevTools protocol. So DevTools has this fantastic JSON-level
-- or Web socket and then JSON-level protocol where you can talk to the Web page out of
process. And you can build developer tools on top of it. You can also build fantastic
profiling tools and you can get out of Timeline stream in that the painting info of what was
painting then you can build all sorts of cool stuff on that, one of which is telemetry.
>>Tom Wiltzius: That's the harness. And then we have sort of collections of Web content
that are sort of interesting cases for whatever reason that we're worried about improving
performance of or aggressing performance against. We run sort of banks of content with this
harness, and we have performance waterfalls. >>Nat Duca: Thank you.
>>Tom Wiltzius: So hopefully that is compelling. >>Nat Duca: Thanks, everybody, so much for
coming. >>Tom Wiltzius: Yeah.
>>Nat Duca: Good luck dejanking. [ Applause ]