Tip:
Highlight text to annotate it
X
COLT MCANLIS: Good.
Test.
Can everybody hear me?
Can everyone see how bald I am from where you're sitting?
Hands up if you can see your reflection in my head.
So I have a really tough job tonight.
My job is to try to keep you entertained and awake
at this time of night, after you've been fed and alcoholed.
So I'm going to try to do that as best I can.
Let me introduce myself really quickly.
My name is Colt McAnlis.
I'm actually the team lead for Chrome Developer Relations
Performance.
About a year ago, in January, we actually
identified that the web performance community was
good and doing well, but we didn't
have someone focused on bringing the message to people
constantly.
As talked about in the previous talks tonight,
it's really easy to do dumb, slow things on the web.
And one of the first things we need to do with that
is fix it with education.
So we kind of defined from the beginning
that after looking at all the education
and looking at everything out there,
there's really three pillars of web performance.
Up until now, the web as a whole has really
only focused on one of them.
All you've heard from most performance experts
is, how fast does your website load.
We've all seen the studies that show
that one millisecond of time actually related to $10 million
of lost revenue for site X, Y, and Z.
And they only really talk about network.
But in the modern age of web applications,
we often tend to neglect the other two
pillars of web performance, rendering and compute.
A great part of the forecast-- Forecastio?
Forecast-- I wanted to see.
He was listening.
That was good.
I wanted to test.
See, I've got to keep you awake, too.
One of the great parts of the forecast talk, I believe,
was when he really said, we have to actually solve
this problem of rendering because it
doesn't happen for free.
I think the existence of the previous type of web,
where CSS animations weren't something you even
had availability to, allowed us to do really stupid things,
and the browser kept us really fast.
But now, because we kind of can tend our own yard,
we're running into some problems there.
So when you think about performance,
you should know that network, render,
and compute-- you can have problems in all three of these.
And much like Jake said earlier, a huge problem
in one of these portions can actually
cloud out issues that are happening in the other two.
So as you're going through your process of finding performance
issues in your website, you need to make sure
that you're evaluating all three of these
with the right tools at the right time.
And what I'm going to do tonight is I'm going to try to walk you
through some of the sites that you've submitted--
ha-ha-ha-ha-ha-- and hopefully bruise your ego a little bit.
No offense.
It's what we all have to do.
Quite frankly, I think one of the big things we've
been trying to do with the web performance
movement over the past year is actually bruise a lot of egos,
in a way.
Because we're all programmers.
We're all smart.
We're too smart, quite frankly.
And we've got to be taken down a peg.
Because we all know in here-- everyone in here,
think about your coworkers.
And think about what really motivates them.
99% of the time, if you can bruise their ego
or challenge them or tell them they're not good enough,
or the problem's too hard, that's
what actually gets them to move, right?
AUDIENCE: Or if you pay them more.
COLT MCANLIS: OK, maybe, maybe.
If you've got Yankees money, I guess so.
So this is the loop.
So this is what you should all be thinking of.
Now I've got about 10 years of game development background
under my belt.
I'm a C++ programmer at heart.
And I'm trying to apply a lot of the lessons we're
using in game development to web development.
Because in reality, we're both dealing with real time media
interfaces.
So when you guys say, how fast can something load off
an internet site, I'm thinking, how fast
can that stuff be streamed off a DVD.
It's the same problem we've had, just 10 years later.
So when you're doing your performance,
the main thing that you have to do is follow these three steps.
The first thing is you need to gather information.
You go open up Chrome DevTools.
You open up WebPagetest.org.
This gives you information about what is going on in your page.
From that, you actually need insight.
Because really, what's a whole sheet
of floating point numbers mean to you?
Nothing.
You need to know what those floating point numbers mean.
And your tooling system needs to be
able to infer what those floating point numbers mean.
And then once you have that insight,
you need to be able to actually plan an action.
You have this data.
You have to then go to your manager
and justify, please, let me spend two weeks fixing
seven milliseconds of load time from our website
because it matters.
And then you need to be able to repeat this constantly,
constantly, constantly.
You need continuous integration tools.
You need the ability to actually track down who's check-in
broke the build.
Quick show of hands.
How many of you in here actually have
some continuous integration for performance
in your suite right now?
One, two, three, four, five.
Wait.
Were you just showing me your Pepsi can?
AUDIENCE: [INAUDIBLE].
COLT MCANLIS: OK.
It's a cool can.
Bravo?
So maybe four, maybe five, out of an entire room.
I've asked this question to probably about 3,000 developers
this week while I've been in New York
and meeting and giving talks, and the total number of people
is close to about 15, with the five in this room.
This shows there's a huge problem in the web community
is that we're not actually testing for performance
and giving it the gravitas that we are our features and our CSS
and those pretty little bubbly items
everywhere else on our pages.
And this is why we actually moved forward
with trying to build a better community about this.
So for you in the audience, this is the only slide
I want you to take away from today.
Burn this into your retina.
Tweet it.
Blog it.
Get a tattoo of it.
Get it tattooed, tweet me, and I'll send you some swag.
Please don't get a tattoo.
Anything I say is not representative
of any organization or Google or the lawyers that
are affiliated with me.
All comments are my own.
Please do not get a tattoo.
First off, if you're doing performance,
go to HTML5Rocks.com.
There's a landing page.
It's called Performance.
You click on the button.
I'm actually the guy that maintains that page.
If you start there, it's going to walk you
through the three pillars of web performance.
You're going to be able to go step by step on how
to find and address the largest problems
on each one of these three pillars.
Next is you need to be following and using
the #perfmatters hashtag.
We actually started this hashtag just earlier this year.
And we really wanted to use #webperf.
We really did.
We wanted to use that hashtag.
It was out there.
But we didn't feel like it bruised enough egos.
We wanted #perfmatters to be this name, this brand,
this answer to a question.
And what we saw was that very quickly, people
started posting links to their friends' websites
and being like, yo, dude.
Why does it take 15 seconds to load your site? #perfmatters.
Right?
We wanted it to be something you could take to your manager
and say, hey, it takes 15 seconds
for our site to load on mobile.
#perfmatters.
We want this to be a badge.
We are all egotistical programmers.
Wear the badge.
Own the sticker.
Make it a part of your culture.
Make it a part of your environment.
That's what we want.
We want attitude.
That's why you should follow that hashtag.
Finally, check out the G+ Web Performance community,
if you're in Google+.
It's a cool place.
A lot of cool people hang out there.
Some of them are bald.
Some of them post content.
I'm not saying who.
But you need to follow that because really, if you combine
#perfmatters with the Google Web Performance communities
and the articles coming through HTML5 Rocks,
you're actually going to find an overflow of information.
I bet most of you in here haven't actually
dived into-- here, we'll do this.
We'll do this.
Put your hand up if you've read more than five articles
about performance.
OK.
Keep your hands up.
Keep your hands up.
More than 10 articles.
OK.
Let's ramp this exponentially.
20.
28.
Ah.
Let's go 40 articles on performance.
OK.
For those of you who have had your hands up,
of those 40 articles, how many of those
things did you implement?
Maybe 5, 6, 20?
No fair if you actually did a talk earlier tonight.
I'm not taking your input.
So the point that we're getting at, though,
is that for those of you who haven't been reading
a lot of this content, this is actually
going to be an overflow of information.
Hopefully, you can find it, you can guide it,
you can move through it.
What's the next one?
Yeah.
So what I'm going to do now is with the rest of the time--
Pete, how much time do we have?
40, 60?
As much as I want.
Keep talking until people fall asleep.
Good.
I can do that.
So what we're going to do is I'm actually only going
to load these websites on mobile.
Quite frankly, I ran through these earlier today.
And most of your sites actually fell over dead on mobile.
There were some interesting use cases on desktop,
but quite frankly, desktop's dead.
If you're not making your site mobile and friendly
and fast there, you're doing it wrong, period.
Period, period, period.
Mobile is all that matters right now-- #perfmatters.
You can tweet that.
I'll give you a second.
No, go ahead.
It's OK.
#perfmatters, [INAUDIBLE], OK.
So we're going to take a look at a couple of these really quick.
And I'm going to try to organize these in terms of discussion
and pointing out a couple things.
So if we don't get to all of them, I apologize.
Please feel free to email me later and curse at me.
Or do it on social media.
That's always fun too.
So what I've got here is a little setup,
and you can actually see my little phone,
so I can click on some stuff.
And what I'm using over here is the Chrome Developer Tools ADB
extension.
So this is a fantastic little-- who's using this?
Anyone using this?
No?
No fair if you're hosting the event, dude.
You guys are cheating.
So this is a fantastic Chrome extension.
You go to the Chrome Web Store.
You can actually download and install this extension.
Basically, what it allows you to do
is interface with the Android Developer Tools
very easily and quickly.
So I can actually click on this and go View inspection targets,
and you'll actually see that it loads and shows me this Galaxy
Nexus phone that's actually plugged in right here.
And I can actually click-- well, I'll
close this so you can actually see what this looks like.
I can click the Inspect button.
And what this Inspect button shows is
it actually shows me what's on my phone right now.
So this is one of the sites, and I'll get to it
a little bit deeper here in a minute.
But this is actually what's on the phone.
You can see it's moving, it's scrolling, it's doing stuff.
We go over here, and you can actually see the network.
So if I hit Reload on my phone-- and you can actually
see the network request coming through.
This is not a desktop site.
This is actually a mobile site.
This is really good because I'm actually testing on the device
that my users are using.
Wow, great comment-- #perfmatters.
One of you will tweet it tonight.
It will happen.
I'll keep drilling it into you.
But the cool thing is, you can actually
see what's going on here.
And notice, for this particular website,
that it's actually not done loading yet.
You can still see the bar moving on the side over there.
And the funny thing is, if you load this site in desktop,
you don't see that same problem.
So obviously, there's an issue on the mobile
that is not showing up on the desktop.
Again, we need to make sure that we're testing things properly.
But the cool thing is, we can actually
see all of the same events, use the DevTools in the same way,
minus everything crashing because of memory issues, which
might happen tonight.
I apologize for the live feed.
But we can actually go through here and just record memory
and see what's going on in memory.
And so let me show you over here.
I can go through and actually scroll and go back and actually
see how memory is adjusting based on this stuff.
So if you haven't adopted this Chrome ADB extension
into your tooling and your testing,
you need to definitely do this.
Definitely get this in your stuff
because no other tool allows you this sort of integration.
And Chrome DevTools are already top of the line.
This should be part of it.
So anyhow, enough of me babbling.
So let's start with one of the first sites here.
Come on, clicky clicky.
Now there's a native app for you, slow when loading.
Right, Forecastio?
Aw, I'll get it right.
Sorry.
So we're going to try this first one here, allout.org.
This was submitted.
Someone in the room submitted this.
I don't know who it is.
Doesn't matter.
But we're going to take a look at your site,
and hopefully, we're going to make you upset.
So this is loading.
I'm going to show you what the page looks like first.
So first off, we all just watched it load.
This is on a 4G connection.
I'm not on the local Wi-Fi.
We can see that this actually is not a mobile site.
I mean, I shouldn't have to scroll.
Oh, I can zoom.
Yay.
But most of the site is actually eclipsed.
We've got some sort of spinner here at the top,
but it's a marquee movement.
We've got some other items down here on the bottom.
Some stuff's going on.
So let's take a look at what that
looks like in Chrome DevTools.
So I can go here, click Inspect.
Again, native applications, they're slow.
So let's go to the Network tab.
And I want to take a look at how this thing loads.
So I'm going to hit Reload again,
and we're going to watch all the assets come through.
And notice here, on the bottom here,
you can see six requests, 12 requests.
I'll keep scrolling down to the bottom
so you can kind of see that.
Seven seconds worth of load time before it's actually loaded.
So this down here on the bottom tells us
that it took about six seconds before content complete was
actually kind of issued, before the page load event occurred,
and 7.9 seconds total.
8K actually came-- oh, no, we're still not done.
9K came through, pardon me.
And so 34 requests.
We can actually see the health of this object
and the health of this site.
Now 34 requests, that's actually nothing.
9K, that's a drop in the bucket.
The Robitussin-laced grandmother picture from earlier
could easily load 9K very quickly.
What's important here, though, and I want to show you this,
is when we go up here and actually sort by size,
we actually get a different sort of sense
of the content that's being sent around.
So we can see-- let me not do that.
There we go.
So we can actually see the images loaded.
We can actually see that most of the large assets here, 6.4K,
512 bytes.
We can see that the large images here-- this
is actually interesting to me.
So this is a 1,024 by 576.
It's 213K.
Quick round of applause.
Who thinks that's too large for a mobile site?
[APPLAUSE]
COLT MCANLIS: Yeah.
OK, here's another one.
Here's 109K, a little bit better.
Same resolution, though.
Anyone notice that?
Same resolution, half the size.
Now if anyone in here-- a quick other round of applause.
Who's written a JPEG compressor?
One guy, two guys, three guys.
All right.
We'll get some beers later, and we'll
talk about DCT coefficients.
I've had this really cool idea that you can actually--
you know what, never mind.
So notice, though, that this image actually
has a lot more data to it.
There's a lot more edges.
There's a lot more noise to the image.
Yet it's smaller than this one here.
This is actually mostly pink.
There's no reason that the image with more detail
should be less size than the one with less detail in it.
What this tells me-- I know nothing about these developers.
I know nothing about the site.
But this tells me that they're not actually
exporting this particular image with the right compression
settings.
So another-- I like doing these polls because it's late,
and I need you all entertained.
So how many of you actually just export
your images at some constant format.
Like when you do an export from a JPEG, it's like on 12 or 80,
depending on what you're doing.
So no-- everyone else hand-optimizes exactly
your exact, perfect PSNR relationship for your JPEG.
Yes?
Is that what I'm hearing?
Because I saw like three hands.
So either you're all lying to each other,
or you have no idea the way that your images are compressed.
OK, round of applause for no idea the compression quality.
[APPLAUSE]
COLT MCANLIS: OK, fantastic.
So seeing this site actually tells us
that this is a systemic problem.
And again, the 3,000 developers I've
talked to over the past week all see this problem.
In a couple of the other websites
I'm going to load tonight, you're
going to see this show up very prevalently that in general, we
as a web community do a horrible, horrible job
of optimizing images for quality against size.
Now in reality, this isn't something
that's that difficult.
Most of us consider a single way pipe.
We have artists or designers that are working in a vacuum.
They're trying to optimize for the visual quality
of the image.
Meanwhile, there's bald engineers
in a corner somewhere going, why is my site slow?
And there's this constant back and forth between these two
camps about size of images versus quality
of images and load times and all this stuff.
Let me give you a little word of advice.
If any of you are able to implement something like this,
it's very simple to spin up an Amazon EC2 instance
or even do this at your desk and actually
run a compressor, a command line compressor,
like libjpeg or jpeg-turbo-- by the way,
jpeg-turbo is the actual codec that we use inside
of Chrome for JPEGs-- and actually compress it
at various quality settings and test the PSNR of the images.
PSNR, for those of you who don't know,
is Peak Signal-to-Noise Ratio.
This is actually a measurement of the amount
of noise and error that's introduced
to an image, the blockiness that actually
comes from the compression format.
We actually have a standardization process.
We call it PSNR, and that's how we compare image compressors
to each other.
So you could actually take your image, compress it at level 90,
see what the PSNR is, compress it at 80, see what the PSNR is.
70, 60, 50, 40, 30.
If you get below 30, you've gone too far.
Just stop at 30.
But the cool thing about this is that you can actually
run 10,000, 20,000, 30,000 images through this process,
and for each one find the exact right compression
value to give you a PSNR of around 38 to 45.
So you're not actually just exporting
to a single compression number, a slider
that your artists have no idea what it does.
You can actually programmatically
find this value by implementing a simple iterative process
against the command line compressor.
That's kind of cool.
Round of applause for cool.
[APPLAUSE]
COLT MCANLIS: I saw some of you begrudgingly
go, that's not cool.
Let's save the questions for the end,
if that's OK, because otherwise I'm going to stare at Putin,
and he kind of scares me.
So let's take a look at some other things here.
So I want to go over timelines.
So that was load time.
Everyone knows the network stuff.
If you're not using WebPagetest.org or ModPagespeed
or PageSpeed Insights and all that stuff,
you need to be using all that.
So let's just take a look at what this site's
doing while I'm doing nothing.
So now I haven't touched this site.
To be clear, my phone almost actually
went locked because I haven't touched it.
I'm still not touching it, but I want
you to notice what the memory is doing on the top.
Now I'm a C++ game developer.
To me, the only thing that matters for performance
is follow the memory.
I actually give a talk at Velocity
yesterday where I, in a very heretic fashion,
suggested that web developers were really bad developers
because we're not controlling our memory.
We're actually letting JavaScript do it for us.
And because of this, we have no idea
what's going on under the hood.
How many of you know what your heap size is?
How many of you care?
That's another question.
I like that.
I like your outfit.
Is that like a ***-- What is that?
Is that like a real [INAUDIBLE]?
Yeah, I like that.
That's cool.
I might have to get me one of those. #perfmatters, I
got to get me one of those.
So again, I've touched nothing.
But notice this here on the top.
I don't know if you guys can see it.
It's allocating between 7.5 megs and 9 megs.
I'm touching nothing.
Nothing's occurring on the screen.
Yet two megabytes of data are being allocated and cleared
in this environment.
Now I can actually figure out what's
going on with this-- if I stop my recording,
too much information.
Let me just do a quick record real quick
so I can clear all that.
So we can see something on the timeline here.
So it looks like, first off, they've
got two different timers firing.
So we've got widgets.js and Chartbeat.
Chartbeat, I'm guessing, is like an analytics thing.
I see this on a bunch of sites you guys gave me.
And then widgets seems like their thing.
So I'm guessing this is that marquee scroll at the top.
They've got some timer that's actually
moving those images around.
What I don't like-- pardon?
AUDIENCE: [INAUDIBLE]
COLT MCANLIS: For widgets.js?
Oh, cool.
Oh, nice.
Widgets.js, Twitter.
Oh, cool.
So Twitter is actually screwing this page up.
Go Twitter.
Is anyone here from Twitter?
Boo, Twitter.
So what we see down here, though,
is we see recalculate and paint and what not.
For our memory, this view doesn't actually
tell us what's being allocated.
We can see where the events are occurring and whatnot.
I can actually mouse over the GCs when they actually happen.
More importantly, though, I can actually
go over here to the Profiles page.
Because I don't like seeing that kind of memory.
And I can actually do a record of heap applications.
So I can just hit start and let this thing run.
And basically, what you're seeing here is on this top,
you're kind of seeing timeline view plus memory profiling
at the same time.
In the top, any of these blue lines
is when memory allocations occur.
Now when you see a grey line, what the grey line means is
that memory has been freed by a garbage collection process
somewhere.
So you can actually see a new set that just happened,
and some of the grey lines happened.
But these blues tend to kind of pop up
in a very regular fashion.
Now in this, I can actually go through here
and change the size of my window and actually
see exactly what was allocated.
So in this single event, at about eight seconds
in in my capture, about 3K worth of data was allocated.
And we can see a similar pattern over here.
I can highlight this window, and we see another,
about almost 3K.
And over here, a similar window.
There's about 3K, plus a lot of extra change
there that hasn't been freed up yet.
But let me focus on this guy really quick.
So here I can actually see that 3K came from compiled code.
So somewhere in this system, deoptimization code came from.
Now for those of you who are not versed
in fast path and slow path JavaScript,
effectively what this little block of data
you're seeing here-- see that optimization data?
The way that V8 and most modern JavaScript VMs work
is they will actually try to optimize
your code on your behalf because, I mean, come on.
You're a stupid programmer.
You don't know how to write code.
Obviously, the VM knows better than you
because it's a machine, and it's fast, and it's smart.
So what it'll actually do is take a code path
that you've written, and it'll actually optimize it.
It'll manage the memory.
It'll make some fast path optimizations,
and it'll put it out there and start running it.
Well, the problem is that it does this
with some assumptions about the state of the environment
that it's in.
And it'll do this, and oftentime, it'll break.
And it'll go, whoa, we actually cause an exception
somewhere in the stack due to our optimization,
because we're just a stupid robot,
and we actually don't know what we're doing either.
When this happens, basically Chrome
has to create this new block of code that's parallel
to the block of code you had, delete your block of code,
put your new block of code in the stack, and have it execute.
When that deoptimization occurs, because the optimization
failed, it has to take your old block of code,
put it back in, and delete the block of code
that it just created.
So there are specific code paths that
generally cause this to happen.
Closures are one of them.
How many of you are using closures in your timers?
Don't applaud.
I don't want you to applaud that.
Closures are one of these things.
If you actually have a closure running--
so it's very common for people to do
set interval closure comma 1,000, right?
That closure in that set interval
is actually causing these sorts of memory leaks to occur.
It's a deoptimization path that V8 can't optimize around.
And so basically, every single time you're doing this,
you're running into this situation.
So let's look at something else really quick.
So I want to go over here and show you
what I'm seeing on the screen.
Now I've turned on a couple modes on the developer tools.
So first off, you'll see this beautiful little--
you can't see it too well.
I wonder if I can tilt my phone just a little bit.
You can see up at the top that I actually
have a little graph showing me frame rate
as well as how much GPU memory is being used.
So that's actually-- quick show of hands,
who understands how a web page is painted?
It's like the same guys that wrote JPEG compilers.
OK.
So for everyone else, let me do this really quick.
How your page is rasterized is a delicate ballet.
Really, it's more like boxing.
It's basically two people smashing each other's faces
in for about six milliseconds a frame.
Effectively, what happens is Chrome will take your web page,
and it will dice it up.
It'll create square regions of 256 by 256 tiles.
For each one of these tiles, it'll actually spin up a thread
and actually rasterize all of the pixels in that tile,
all of the WebKit-- well, Blink now.
Sorry, I've got to get my terminology right--
all of the page elements, and actually composite that
to a CPU chunk of memory, 32 bits per pixel,
256 by 256 tile.
And it'll rasterize all that data in there.
Once that data is rasterized, it'll
then upload it to the GPU.
When you scroll a page, the GPU is actually
the thing that's moving your page.
Now for those of you-- some of you in here
are young, much younger than me.
You may not know this, but back before "Quake III"
was hardware accelerated, we had something
called software rasterization.
Yeah?
Software rasterization?
"Heretic," "Doom," "Quake," anybody?
Any other professional gamers in the house?
Yeah.
So back then, we used a term called software rasterization.
This was generally OK, but once we invented GPUs,
GPUs are basically hardware rasterization.
They're built to take pixels and put them on the screen.
They're dedicated silicon for this.
But Chrome is actually still using software rasterization
to paint the pixels on the screen.
This means that this is a slow path.
This also means that every one of you,
right now, should be really, really scared,
because how many of you have actually tested whether or not
those rounded corners and drop shadows affect your render
time?
They do, actually, quite frankly.
If you go to "HTML5 Rocks," I actually did a study on this.
Ha ha.
I'm sorry, that was a leading question.
That was mean.
I knew that you didn't know that answer.
But basically what happens is your CSS effects actually
cause-- it has to be software rasterized, which
means we have to actually go and draw rounded rectangles
and then actually add a drop shadow to the side of it.
And this actually takes more time.
In fact, if you have those two combinations
of things together, it actually takes 4x
as long as each one of them individually.
Which means that there's combinations of CSS properties
that hurt your rendering performance more than others.
Hopefully all of you are going, dear god,
I have to test this right now.
And how you can test this, as you can actually see up here
in this GPU, this frame rate meter,
is that as you're scrolling, you can actually
see the milliseconds taken to render that part of your page.
Now what you're also seeing here is
notice this big red box that keeps popping up?
This is actually a mode in Chrome DevTools.
Let me show you this.
And I know I'm spending more time on this site.
As we go to the other sites, you'll
actually see this stuff play out.
But I need to kind of test the groundwork here.
Is that in or left?
AUDIENCE: Left.
COLT MCANLIS: Left.
Oh, wow, OK.
I'll keep working.
So anyhow, I have show paint rectangles on.
Basically, what this does is when I turn this on,
it's going to show a red rectangle
for every part of the page that actually gets repainted.
So this actually tells me what part of the page
is being rerasterized.
Which is really cool to know because I'm
pretty sure all of you will look at your site
and find that you've got some little square icon like this,
but for some reason, it's rasterizing like a 6x size
window of that, that all has to be processed on the CPU.
This slows down your page.
It creates jank.
I hate that word.
Hitching, by the way, hitching is the right term.
Every other medium, video games, AV, movies,
it's called hitching.
Just, can we all agree to use hitching?
No?
I'll get hitchfree.org later.
Anyhow, let me move on to the next site
because I want to make sure that we talk about some more stuff.
But basically, you can see that on this site,
there there's a couple things.
First off, they're sending two large images
to a mobile device.
They don't have a mobile view.
They don't have a mindset of a viewport
for these mobile environments.
Plus it seems like their marquee is actually
rendering and updating different parts of the page
at different frequencies.
They're allocating about a meg of memory per minute
or so when no one's touching anything.
So if this is your site, fix those things
because you need to.
And also, your load time is pretty harsh, too.
So let's do this next one.
So this next one should be pretty quick.
I just want to highlight something really,
really poignant here.
So I'm going to close this.
Which view are you on?
OK.
So let's show you.
So this is DoSomething.org, a cool little website.
It kind of just encourages everyone
to do something interesting in small, little-- small butterfly
wings change the course of tides in Africa and all that stuff.
But we see it's a pretty simple website, just kind
of a little strata of images and whatnot.
When we go over here to Chrome DevTools,
let's inspect this information here.
And I'm going to put this back on the Network tab,
and we're going to go ahead and reload this.
So we can actually see that the page loaded pretty quickly.
We got a lot of information really quick.
About 2.9 seconds, so this is a lot better
than the previous website.
We're right around that three second load time.
And again, this is on my 4G.
I'm not on the wireless.
So that's pretty good.
10K transferred, that's all right.
21 requests, not that bad at all.
So let's again sort by size.
Let's see if anything's coming up here.
I got a couple not founds.
That's not necessarily a good idea.
A couple images here.
So this is interesting.
Again, another 106K image that's being delivered
to a mobile screen that obviously does not need 106K.
That one's a little bit better.
Well, not better.
I mean, that's a very depressing image.
I didn't mean that that was-- again,
my opinions are my own and not that
of any organization or secret service
that I'm influenced with.
So we can actually see some of these images
may be a little bit larger than others.
But for the most part, this is actually nice.
Where did-- what happened here?
Did I-- this technology, isn't it great?
So we can actually see, though, that this page is actually
a pretty good example of what to do on a website.
If you load this on the desktop, what you'll actually see
is that there's larger versions of these images.
They're tiled differently with a different layout.
There's a different scheme.
But in the mobile version, they really only
have one or two images that are probably
too large for the mobile device.
But in the most part, this actually
scrolls pretty quickly.
I know you can't see it up in the top, here
but this is actually about three milliseconds to five
milliseconds to actually draw the part of the page.
And you can actually see that as I'm scrolling,
notice that there's no red tiles.
You don't see those big red flashes.
What that means is that this entire page has actually
been rasterized on the CPU and uploaded to the GPU,
and it's been cached in the GPU.
And so as you're scrolling up and down,
the CPU doesn't have to do any work.
So this is what you want.
You want no red blocks going on in your page.
All right.
So let's do another site here really quick.
Because now I'm freaking out that I only got 30 minutes.
AUDIENCE: [INAUDIBLE].
COLT MCANLIS: Yes.
Oh, we're going all night.
Let's just open up every website.
OK, so this is the one we saw a little bit earlier.
Sorry, I don't know if my antics distracted you all.
Let's reload this again.
Let's see how the load time is.
So notice on the top here that it's about halfway.
So this page hasn't unloaded yet.
Let's just be clear about what we're looking at.
This is an instant load.
Now we've actually gotten to the loading part.
If this is your website, I'm sorry.
Hopefully, you understand there's work that needs to do.
AUDIENCE: [INAUDIBLE]
COLT MCANLIS: It might be.
Let's find out.
So again, over here, let's go to Inspect.
I wonder if I can just catch this midstream,
if it'll just tell me what that image is,
or if I have to hit reload.
It's still loading.
OK, here, I'll hit Reload, see what goes on here.
Ooh.
Oh, web fonts.
OK, we'll take a look at that in a second.
OK, so I hit Reload.
This is waiting to reload.
So obviously, there's already some problems with this site.
Hopefully, someone in here is going like,
uh, please stop clicking buttons.
Please take my website off of your screen, you angry,
bald man.
OK.
Let's let see how this is going here.
So you can't see the screen.
It's still loading.
The font's just now appeared.
Let's take a look at what's going on here
and see whether or not we can discuss some of these items.
So let's sort by size here.
This is something I want to let everybody know.
This is the first thing I want to point out on this site.
This is a WOFF file.
It's a web font.
Round of applause if you're using web fonts in your site.
[APPLAUSE]
COLT MCANLIS: Good.
Please stop.
Please, please stop.
This is a-- I don't know if you saw this.
Yeah, web fonts look great.
They're awesome.
This is 38K for that web font.
And unfortunately, some of these have been cached,
so you can't actually see the true size of a lot of these.
But there's actually like five or six web fonts on this page.
So you guys are kind of getting a bum deal.
You're not seeing how horrible this is.
But basically, here's what happens
is when you've got five web fonts,
each one can be somewhere between the range of 40K
and like 90K for a font.
That font is required before text can actually
be drawn to your screen.
So pop quiz.
What happens if you're ready to draw text,
and your CSS is down, and your JavaScript is down,
and your images are down, but your WOFF isn't down yet?
Good answer.
I don't know.
No one said anything.
Good answer, nothing.
Nothing happens.
Chrome will do nothing.
Chrome will block.
Chrome will wait.
Chrome will wait for every single one of your WOFFs
to come down before a single character of text
is drawn on your screen.
AUDIENCE: Uh, it will point at one WOFF.
It will render all the text that uses that WOFF.
COLT MCANLIS: Jake Archibald says I'm dumb.
If that single WOFF is visible, it'll render that one.
Now Firefox will do it a little bit differently.
Basically, what it'll do is it'll
wait three seconds, right, Jake?
AUDIENCE: Yeah.
COLT MCANLIS: Yeah.
It'll wait three seconds.
Maybe you should continue.
AUDIENCE: Yeah. [INAUDIBLE].
COLT MCANLIS: I'm having an awkward mic moment.
Basically, what'll happen with Firefox
is it'll start the request for the WOFF.
If it hasn't been downloaded in three seconds,
it'll actually keep allowing that to download,
but it'll actually display the font with a default.
Like it'll just see Arial.
So if you're actually seeing this on Firefox,
you'll see like three seconds of nothing,
and then you'll see Arial, and then when the font comes in,
you'll see it pop to whatever the font's supposed to be.
And so you see this flicker.
I see it.
You see it a lot on mobile, because these mobile devices
are actually 6x slower in hardware, just
across the board-- probably for at least another two years,
depending on which hardware manufacturer you're trending--
than what you're seeing on desktops.
Not only is it slower to download these things,
but these WOFFs are actually very complex spline paths
that have to be interpreted by these underpowered ARM chips
as well.
Anyone in here written a software rasterizer?
Cool.
Spline paths are slow.
Anyhow, WOFFs are bad, and you should feel bad
if you're using them in your websites right now.
Now, things are happening that are trying to optimize this.
I know that there's people talking
about different ways to compress WOFFs and different ways
to use these type of fonts in different ways.
But please note that you have them as part of your site,
you should feel bad.
Now let me see if I can-- can I Shift-Reload this?
I don't know.
I can't get the data from cache.
But we also see in here a couple of these things,
and I can't show you this.
But these images are actually a little bit larger
than they should be as well.
These are OK.
Was that Willie Nelson?
I don't know.
Again, there's another WOFF.
This PNG, where was its header on that?
This one's a WebP.
Ooh, fantastic.
So this guy's actually using a WebP.
Interesting.
I don't know what that's doing.
AUDIENCE: That was the accept header.
COLT MCANLIS: That was the accept header, yeah.
So at least a WebP did come down.
However, we see that-- let's go down here-- again, 124K.
So again, you guys are getting the bad rap
because I'm not doing a cached fresh reload on this.
But basically, this site is using--
it's actually passing full megabyte, two megabyte images
down.
It's got the WOFFs in the direct path to rendering,
and so that's going to take a long time
before text will show up.
In fact, the image will try to progressively load in
before all the text does.
And this will annoy your users a lot more.
So let's try to avoid that.
All right.
Let's try another website here really quick.
Let me go over to this.
Is anyone sad yet about the state of things?
Is anyone going like, wow, I wonder
how my site does under this type of scrutiny?
If so, then yay, I'm doing my job.
I can get paid this week.
Cool.
That was actually pretty quick.
That actually wasn't that bad.
Let me do that again.
Yeah, that actually wasn't that bad.
Here, let me see if I can hard-- load, load, load.
Good.
Cool, OK.
So this might be a good site.
Let's take a look at this one.
So we'll hit Inspect again.
We'll load it up.
Let's see here.
Scrolling actually seems pretty smooth on this site.
Doesn't seem that bad.
We can move stuff around pretty easily.
Let's take a look at the Network tab.
Let'*** Reload again.
Again, unfortunately, all of this stuff
is coming from the cache now.
I should've used my other tablet.
Dot com, CSS, not that bad.
22K CSS, 27K CSS, 200K.
I don't like this 192K JPEG that's only 920 by 300.
Notice this.
So this is 192K for an image that
is a quarter of the size of Putin.
Show of hands, who knows what that means?
Yeah, not optimizing your JPEGs.
I think there's actually some other bad examples here.
Here's another one, 240K.
Oh, oh, 240K, 920 by 300.
Does anyone off the back of your hand
know what this is if it were a raw image size?
So it's 920 times 300 times 24 bits per pixel?
Get back to me.
Jake'll give you some swag.
Oh, there's a Facebook icon.
Only 9K, yay.
Well, OK.
100 by 100 is 9K.
That seems a little bit excessive, right?
That seems like there's actually some bloat going on there.
I wonder if there's like a negative JPEG encoder.
Make it larger.
By the way, if any of you are going to be in San Francisco
next week or have a chance or have the internet,
I think, definitely tune into my talk I'm giving on compression
on the web.
And hopefully, if you've seen my talk yesterday
about being scared of closures, if you see my talk next week
on compression on the web, hopefully compression
will scare you after that, and you'll
trudge toward that monster with a wary eye.
But anyhow, 100K, 100K pixels, 3.9K in size.
So that actually seems a little bit excessive there too.
Here's, again-- those are the same images.
Here's another one.
These are really large.
180K being sent to my mobile device.
Now the reason this loaded-- again,
this loaded a little fast.
This is a bias because I've been testing these things all day,
and this is coming from cache.
So you're not really feeling as much pain as you should be.
AUDIENCE: If you go to the bottom of the [INAUDIBLE],
you should be able to disable the cache.
COLT MCANLIS: Beautiful.
All right, Jake Archibald for the win.
Here, let'*** Reload now.
There we go.
Oh yeah.
Oh, feel it.
Feel it!
So awkward right now.
AUDIENCE: [INAUDIBLE] JPEGs.
COLT MCANLIS: They kind of should be, yeah.
Oh, so-- no one's hiding their face right now,
so maybe the guy who put this site in isn't here,
or you've got a great poker face.
I will not bet money against you.
OK.
AUDIENCE: Oh, then they shrink.
COLT MCANLIS: And then they shrink, right?
So that's actually a great point.
I'll bring this up really quick, too.
How many of you have responsive websites?
OK, you're doing it wrong.
Let me ask that in a better way.
How many of your responsive websites
will actually resize the image that you've been given?
Jake.
AUDIENCE: What do you mean by resizing it?
COLT MCANLIS: You got a CSS resize.
Are you changing the properties of it?
If it comes down as 1024 by pixels by 1024 pixels,
and you display it as 900 pixels by 900 pixels,
or something like that, anybody resizing?
You're telling me every single one of you
gives exactly the right pixel ratio for every single device
that loads your website.
Is that what I'm hearing?
All right, that guy's hiding his face,
so I know he's doing it wrong.
You know what?
At least you're honest, brother.
I got some swag for you after this.
So here's something a lot of you don't know.
Decoding a JPEG or a PNG or a WebP file actually
takes time from your CPU.
And in fact, you know how I was talking
about those tiles getting rasterized?
What happens is before a tile can be rasterized,
Chrome actually has to go decompress
all the images that are in that tile.
Now when that tile is evicted from the cache,
we're going to have to repaint it again sometime later.
Well, lo and behold, there's actually
a texture decompression cache as well.
So there's a chance, a very high, high, high chance
on mobile devices, that we'll actually decompress a JPEG file
and then have to resize the uncompressed version of it.
So you're actually getting full 32-bit pixels actually being
resized from 1024 to 512.
And then the next time you have to render that image,
you have to decompress it and resize it again.
So if an image is split between two tiles,
you can run into a very awkward situation
where you have to decode and resize that image for each tile
that it's split in.
So if you're resizing your images dynamically right now,
this could be a problem for your site.
Hopefully, some of you--
AUDIENCE: [INAUDIBLE], should we not do dynamic websites?
COLT MCANLIS: Save the questions for the end.
AUDIENCE: OK, sorry.
COLT MCANLIS: I said it to that guy.
I gotta say it to you, too.
Was that because I called you Forecastio?
OK.
That's all right.
Much love.
Anyhow, so I think we kind of see
that this website has some issues.
And most of it is on the Network tab.
Let me go ahead and turn on continuous show paint
rectangles as well, because I want to show this off too.
So see that red rectangle?
So you can kind of see this little one.
Let me show it on the screen here.
You can see this will pop it up.
But watch this red rectangle happen full screen.
Did you
See that?
See that again?
Poom, poom, poomp.
Poom, poom, poom.
I see this almost on every single site on this list.
Basically, they've got a marquee on top.
And that marquee, for some reason,
is actually invalidating the entire page below it as well.
So the actual div that's expanding this thing that's
getting repainted is touching every single pixel on the page.
Which means that even sitting here doing nothing, actually
the CPUs just sitting here spinning and spinning
and spinning and spinning and working and working.
And that's actually going to make scrolling not as smooth
as possible.
And you can't see it.
I can feel it a little bit here.
This is actually a pretty janky website.
Up at the top, it says that our average frame rate right now
is about 18 frames a second, 17 frames a second.
I can actually really feel this on mobile.
Now I have 30 minutes.
Yes.
15 minutes of filler.
So obviously, this is a problem.
And because when I see something dynamic like this,
I generally think that memory is going wonky as well.
So let's go ahead and do a timeline and hit Record again.
Let's see what's going on.
We've seen this before, right?
Same pattern we saw with the other site.
We see just kind of memory, just being allocated and allocated
and allocated and allocated.
Let'*** Stop and see if we can drill in and see
what the culprit is.
Again, I know nothing of these websites.
I'm just a primitive C++ developer.
Your web development scares and confuses me.
So let's go to Profile, and let's do a record heap
allocation.
So we can see that memory's a problem.
Now let's dig in a little bit deeper.
Let's record a heap allocation.
OK.
Again, I'm not touching anything on the website,
and memory, 10K, 5K, 10K, 5K.
Let'*** Stop.
Let's try to drill in here on one of these guys.
Let's just look at this one.
Compiled code.
Looks familiar again.
Oh, wow.
It's almost like we've seen this exact three lines of code
before.
So again, I know nothing of this website.
I haven't even looked at the source code yet.
But something in here is already passing a closure
to a set timeout-- or a set interval, sorry.
Set timeout is a different operating system.
But there's some other stuff going on in here, too.
It looks like some other relocation info is going on.
I don't see any injections, which is good.
So no one's calling eval, because otherwise we'd probably
see this 6K worth of information-- someone laughed.
That's probably good.
Eval is bad, and you should feel bad.
So if you're using closures and eval, just get out.
Just get out, dude.
I'm going to see a tweet.
Colt says, use set interval with closure and eval #permatters.
Yeah, with a WOFF, inside of a WOFF.
By the way, I saw someone the other day
that actually had a WOFF embedded inside of a CSS.
And I was like, OK.
That's just a bad idea from all principles.
So the CSS gets bloated, and then the WOFF has to be--
Anyhow, we see that this other part is an array.
Now this is interesting.
So when you see this array object,
this means this is an actual JavaScript array that
is allocated somewhere on the page.
And you can see some of it is coming
from internal with V8, the code deopt data.
But otherwise, the relocation info, here's like a null.
A null array is just being created for no reason,
and no items are being added to it.
We can go down here to string, and we
can see a GM string has been created somewhere.
Let's scroll this up.
Do we have any information?
AUDIENCE: [INAUDIBLE]
COLT MCANLIS: Yeah.
Yeah, that's what's going on right here.
So there's regex occurring somewhere.
A GM is being created.
And then there's some system level stuff.
This is mostly dragons and krakens
and other things going on under the hood.
If we expand this a little bit, we
can actually slide over and see, again, compiled code.
There's another relocation info.
Let's see if there's a deopt this time.
No?
That makes sense because the spike's not as high.
See around this guy.
Compiled code, relocation.
Yep, spike's not as high again.
So again, deopt is actually what's
causing the memory spike here.
And then of course, that's causing inflation in our heap.
So we can actually see there's a couple problems.
Obviously, they're sending too much data down the pipe.
This page is loading slowly.
The person should feel bad.
They've also got some timers and some closures
and some memory leak issues that are causing
some friction with their users.
Let's load another site.
Here we go.
Try this one.
Chrome always, thank you.
All right, So let's see this one.
Who thinks this is going to be a fast site?
Show of hands.
No hands.
Good job.
You win.
I like the spinner.
We're trying to load.
We're letting you know that we don't know how to do this.
Oh, sorry.
That was below the belt.
Oh, I'm sorry.
I'm sorry.
[LAUGHTER]
COLT MCANLIS: I'm sorry.
I thought it was a good idea.
We see it in Gmail.
I don't know.
It's kind of like, hey, we're not
ready to figure out how to stream content yet.
We saw load.
That was good.
So let's do this again.
Or actually, let me show-- scrolling
doesn't seem that bad.
Let's click on something.
That was actually pretty fast.
That was actually a little too fast.
Hold on.
Wait a minute.
Let me go back.
OK, I'm back [INAUDIBLE].
Let me click on something else.
Like, trust no one.
I don't trust anybody.
Wow, that actually loaded a lot faster on the main site.
Let's drill in here.
Hold on.
AUDIENCE: [INAUDIBLE].
COLT MCANLIS: No, no.
Dude, you're messing it up.
Jake, who's got the microphone?
AUDIENCE: I'm sorry.
COLT MCANLIS: I didn't interrupt your talk.
So let's take a look at this here.
So I'm going to go to Network tab,
and I'm going to hit Reload again here.
Boom.
We're going to take a look at this.
Let's see what's going on.
So it was really weird.
The main page loaded slow.
That was awkward.
But then all subsequent clicks loaded actually really,
really, really fast, which tells us
if you can't get the main page right,
why are you getting the sub clicks right?
That's kind of awkward.
So we're still loading.
We're still loading.
We're still loading.
Again, I always sort by size, right?
Because I'm a big dude who says that memory
is where the performance problems are.
We can actually see that they're loading--
and I'll kind of give away the punch line here.
But these images were on the sub pages, not the main page.
But they're being loaded on the main page.
Anyone figure it out yet?
Basically, what they're doing is they're
loading all of the images for all of the articles
that you would click to before the main page is loaded.
So they're basically trading off.
They're saying, your initial load time
is going to be really crummy, but every click
after that's going to be golden.
So they're kind of giving up that initial three second load
time to get one second load times later.
I don't know how that-- maybe that's a discussion.
Again, here's a WOFF.
Anyone like WOFFs now?
Answer should be no.
But yeah, this is really interesting
that we're seeing some of these images.
Let me see if I can sort this again
and see if we can't get better-- here's another PNG.
Again, this is not on the main page.
So let me hit Back here.
And let me, again, let's show you the main page here.
Even clicking Back takes some time.
No?
Backie?
No, I guess not.
AUDIENCE: You can't go there.
COLT MCANLIS: We're stuck now.
There we go.
So yeah, notice this right here.
So this was one of the last things I clicked on,
and they have a little drop down.
So basically each one of these items, the images
and the extra content is loaded in the main page, not
the subsequent page.
We're kind of seeing that break down in a lot of these charts
here.
So they have a couple lower res versions here, too.
So remember when that 100 pixel by 100 pixel Facebook icon
was 9K?
Here's a 320 by 180 that's 10K.
So again, don't trust your Facebook icons.
I would like to say, don't trust Facebook,
but I'm not allowed to say that on camera.
***.
Sorry.
Again, perfect.
Here's a 320 by 180 that's exactly 9.1K.
So again, I think all of you should be questioning
how big your images are, but I think
this Quartz site is actually kind of an interesting case
study because they've definitely traded off
one type of load time for another type of load time.
And I'm not really sure why or where
the justifications of that are.
But I think we can definitely all
agree that the 20 years that we've had on the web
have all kind of accumulated that the initial load time is
pretty much the most important thing because that's
the first thing your user feels.
None of you have seen this site except for the one guy who
submitted it, and all of you felt the pain of this site
loading for me hitting a button.
And it doesn't matter how much the clicks after that are.
Most of us would have left the site before we got to that.
Let me go over here, too.
I want to show this.
So notice this-- oh, I moved now.
But this YouTube image here.
So if I click this button, you'll
see the red boxes again kind of show up here.
So we can actually see that the video-- that part of the page
is being re-rendered.
So you can see again that it's showing that the--
[VIDEO PLAYBACK]
COLT MCANLIS: Nope.
Don't care.
Don't care.
Nope, done.
Stop.
Stop.
Let me click.
Done.
What I'd really like to show here,
and this isn't really showing up on the main screen,
and I'm sorry.
But can anyone see this orange line
right here, this orange line?
So one of the other interesting things,
there's a talk that I gave at Google I/O this year on this.
It's called "Web Page Design with the GPU in Mind."
So what happens is certain elements on a page
are kind of-- imagine your page is a plane,
and all of your images and all of your text
exist on this plane.
Some of those things are actually
propagated to its own plane so that the web page can actually
scroll in the background, and this other plane
can actually scroll relative to it.
So this is relative scrolling concept.
Let me actually show you this on a big screen here.
Let me load up HTML5 Rocks.
And let's-- nope, I typed in the wrong thing.
Because I can type.
Who's on my internet?
Watch my Wi-Fi go down now.
We'll try that.
There we go.
So I'm going to pick this, just a random article
with some random guy on it.
Some random, good-looking guy.
I think he's pretty good-looking.
Bald is beautiful, I hear.
So let's go ahead and turn on-- this
is Chrome DevTools on a desktop site.
I know I wasn't going to talk about this,
but let's do force accelerated and show composite layer
borders.
So turning on layer borders here shows us
what we're seeing normally.
The first thing you see is that the blue lines here
actually represent the tiling of the page.
And this orange line actually represents
something that's been promoted to its own layer.
So how many of you are using translateZ?
TranslateZ, translate3d, this is the hardware
accelerated fast path, the silver bullet that
makes your web fast because you're suddenly
using the GPU on the web.
It's so amazing.
Actually, that's not how it works.
What happens is when you use translateZ or translate3d,
you're actually promoting these pieces of content
to its own plane.
And this is actually a separate set of tiles.
So remember how I said the GPU will actually
scroll your tiles on the screen?
When you actually use translateZ,
you get another layer that the GPU also controls.
Now I'm going to see if I can do this because for some reason,
we get paused in the debug-- too much clicking.
So as I scroll here, notice how these objects on the side--
watch this.
The table of contents has not orange, right?
And so once it gets to a certain part,
it actually gets promoted to its own layer.
The orange border represents different layers in GPU memory.
And then as I scroll down the page,
they actually stay static.
Any time you have relative scrolling content on your page,
you're actually going to want to promote it
with this translateZ or translate3d.
Now beware that this actually puts a lot of pressure
on your GPU.
So for all of you who are just going
to start putting translateZ on every part of your pagee--
we saw this happen a lot because it
was supposed to be a silver bullet--
every one of these tiles, every one of these layers,
is actually contending for residency inside of your GPU
cache.
Which means the more of these separate layers
that you've actually promoted, the slower your website
is going to be.
So you get an inverse effect with it.
Because basically, your GPU is getting overtaxed.
More tiles are being evicted from your cache,
because more things are fighting for residency.
It's actually going to slow down your site
because your CPU is spinning up more.
Anyhow, enough with the desktop stuff.
Desktop's dead.
No one wants desktop.
OK, let's go back over here to this thing
because the mobile web is sexy.
What was I showing off?
Yeah.
So Quartz, this QZ site, this is actually a little bit
interesting because we see mostly that as we're scrolling,
notice the big red spots that keep popping up.
Let me see if I can get it to do that again.
Yep, see it?
So something's going on.
It turns out-- I'll spare you the punchline here.
What's actually occurring is that these guys
are doing something with a scroll handler in here
where they're actually trying to catch what I'm doing.
They're trying to catch my little scroll.
They're trying to reposition things.
And as soon as they touch the DOM,
the whole DOM has to be recalculated.
As soon as the whole DOM has to be recalculated,
all of the tiles have to be redrawn.
So as soon as they try to catch what I'm scrolling
and reposition things manually, they're actually
invalidating the hardware compositing
and the GPU scrolling that we're trying to do on their behalf
and actually messing up their entire frame rate.
How many of your mobile sites are catching a user input
like this?
Yeah.
I saw that.
I saw that.
At least you're honest with it.
Forecast.io, they know what's going, guys.
I got it right.
I got it right.
He didn't-- no, he still hates me.
That's OK.
All right.
Let's do some other websites.
Pete, how are we doing on time?
15 minutes?
I can load all the websites in 15 minutes.
So let's look at a couple other ones here.
Let's see.
Let's take a look at something good so
that everyone walks away from here
with feelings of happy bunny times.
Sorry, I just called somebody.
So this is Meetup.com.
OK.
So we didn't see a loading spinner.
That was kind of nice.
But it did take a little bit long to load.
In general, though, let's see how it scrolls.
That's actually pretty fast.
Notice-- let me turn the show-- let's
open the DevTools again and see what kind of red things
are occurring and what kind of load times
we're experiencing here.
So turn on DevTools.
Let'*** Reload and see how the network performs.
Not that bad, not that bad.
On the device, I'm actually seeing
things starting to pop up already.
I notice no WOFFs in the code.
That's really good.
Oh, there is one.
Son of a ***.
Where did that come from?
Oh, bogus.
Well, maybe they're not using that on something critical.
Let's sort by content here.
This is really cool to see.
We've actually got-- a 44K JavaScript is actually
the biggest part of the page.
I'm surprised that's not jQuery at 191K.
How many of you are using j-- you know what, never mind.
Just never mind.
OK, actually, this image is popping up to the top.
60K JPEG, 320 by 226.
That's maybe a little large.
Another 60K JPEG, another 50K JPEG.
This is really interesting, too, because we just saw 340 by 226s
on the previous site that were about 10K, right?
So again, someone's not optimizing JPEGs the right way.
In fact, there's actually, on the article
that I put on HTML5 Rocks about image compression--
let me see if I can tab over there really quick.
So this article that I did was actually
"Image Compression for Web Developers."
The entire point of this article was to talk to all of you
in a very frank way and kind of discuss
the back story of where image compression works.
Plus I'm a really big fan of parrots.
They're kind of cool, especially the digitally pixelated ones.
Anyhow, there's some great content down here
about JPEG information.
And it actually shows that-- here it is, right here.
Let me see if I can zoom this in.
No, too far.
OK, so this is actually-- I feel it's important to kind of break
away from our regularly scheduled bashing
of these websites-- because that's
getting a little depressing, right?
Everyone's getting depressed?
So this is actually a test that an external person
did on the compression quality of the images that
are being served by the top websites in the world.
And what you're actually seeing here is most of them
actually just use a standard value.
So all Window Live background images are exactly 82.
Regardless of what the PSNR is, they choose 82.
It's hard coded.
So they might be able, on some of the images,
to use a level 64 and actually reduce the size more
because they use 82.
Wikipedia are all 80 for every one of their images,
regardless of the content quality on it.
YouTube is about 70 to 82.
That's kind of good.
It shows that they're actually doing some dynamic scaling,
although it's unclear whether or not it's actually manually
scaled, where they have an artist actually changing them,
or they have some sort of dynamic solution,
like I was saying.
Yahoo, 69 to 91.
Again, they may have some more responsive version of that.
Facebook's are at 85.
And Google image thumbnails are about 74.
Here's the really interesting-- Twitter user
JPEGs are anywhere between 30 and 100,
which means that for some images,
they're actually doing nothing.
And some images, they're doing everything.
This actually tells me-- I don't know if anyone-- no one's
in here from Twitter, right?
This actually tells me that they may have something dynamic
actually testing the noise ratio of the compression
there and actually serving you the most optimized JPEG
at the best image quality possible.
So that's really cool.
That's really cool to see that someone's
doing that out on the web.
OK, back to doom and gloom.
OK, we were over here.
So yeah, so these images probably
are a little too large in megabytes.
They're probably not optimizing it.
Chances are-- nope, that's not an image--
chances are they're just using a standard one.
So let'*** Timeline.
Let's just hit Record.
Let's see what's going on with memory.
I'm not touching anything.
Memory's increasing.
Not too much, 5.5, 5.6.
Again, we've got these timers getting fired.
Fine.js, I don't even know what this is.
Meetup script mobile find.
OK, so apparently it's trying to meet me and find me.
That's kind of creepy.
Mobile base.
So that's weird.
So they've got two separate timers
coming from their own website, doing two different things.
And again, not touching anything.
Nothing's happening, nothing's moving, but we're at 5.6 megs.
So this is like a slow leak.
It looks like there's a slow closure or something being
tossed to this.
So let's take a look at this, see if we can't drill in.
Maybe we get some insights.
Oh, yay.
It is a jQuery library.
Can we summon the power of pretty print?
Aha.
That didn't help.
I'll try that again.
There we go.
Oh, mustache.
Interesting.
Who uses mustache?
Can anyone explain this line of code to me?
AUDIENCE: It's a JavaScript [INAUDIBLE] derived from it.
COLT MCANLIS: So this is causing a memory leak.
Can anyone fix this?
Not now?
OK, that's cool.
Take your time.
That's all right.
We'll get back to it.
But basically, we're seeing again,
this kind of looks like an anonymous function
calling some factory objects, testing some object
definitions.
This in and of itself doesn't look bad,
although it is calling another anonymous function down here.
Sometimes the pretty print spacing
doesn't get it all right.
This might actually be sort of a closure in a closure.
It looks like we've got one close there, one open here.
Something's going on.
Any of you who are using third party libraries,
it's actually really easy to fall in these traps
where they're allocating memory and doing stuff
on your behalf that may be negatively impacting
your performance.
And we sometimes ignore these faults
and don't track these faults down
because the fact we get like event propagation or something
else.
Like, oh, I get a callback when something occurs.
That code you can actually write in about 100 lines
of your own making and actually keep it memory performant.
But instead, we pull in these large libraries.
So it's important that you know these trade-offs
when something like this is occurring.
Let's do another website.
Pete, we got what, 10 minutes left?
Yeah, about 10 minutes?
Let's see.
What haven't we done here?
So I have to load this because I really don't get this website.
And I really want to talk about the website more
than the performance characteristics.
So this is called Game of Phones.
Is this your site?
AUDIENCE: Yeah.
COLT MCANLIS: OK, cool.
I really don't get this website.
But it's here.
So we can take a look at it from a performance perspective.
Basically, what happens is someone
will record-- from what I can tell,
they're like very politically charged, angry arguments.
And you sign up, and someone will
call you and play this recorded message that's
like, blah, blah, blah, blah, blah, blah, blah.
Rally.
Fight the power.
And then you have to call someone else on the list
and try to regurgitate what you heard.
And so it's kind of like the game of telephone
that you play as kids, and you're
trying to get all the way through.
I have no idea why people are even doing this.
Like, I hate getting calls from my wife, much less
random strangers on the internet.
I'm on the internet because I don't want you to call me.
Send me a text or something.
Anyhow, personal thing.
I'm sure it works for you, brother.
I don't get the internet.
I'm too old.
That's my problem.
AUDIENCE: I've had people tell me it's the only phone calls
that they will answer.
They will answer phone calls from this
and from their mother.
COLT MCANLIS: Oh, dude.
Game of Phones, awesome.
You know what you need to do?
You actually need to get the voices from "Game of Thrones"
to actually do the call, and then it
would just go through the roof, dude.
HBO might sue me now.
Sorry about that.
Anyhow, let's look at this from a performance perspective.
There's really nothing on this page.
I mean, it's kind of text.
But we're going to run through it anyway,
just so you guys can kind of see the differences
in these things.
So am I here?
OK.
By the way, did you see actually what showed up?
Was this on the screen?
Sorry.
So this is Game of Phones.
Again, it's just text, people calling each other.
But this is it.
12 requests.
The interesting thing here is 107K, that's a little odd.
Like we're seeing some other pages come in below that.
Mainly this is coming from a concatent.
So Bootstrap is being included.
I'm not really sure why this needs Bootstrap.
I guess the cool kids are doing it.
And here's the funny thing.
We got bootstrap.min and then CSS that replaces Bootstrap.
So that's a thing.
And then jQuery.
And here's another Bootstrap again, and then telephone-gram
and then another jQuery.
Are you using two jQueries?
AUDIENCE: I should mention that I've never
made a web page before.
COLT MCANLIS: OK.
You're using two jQueries.
Do you know you're using two jQueries?
AUDIENCE: Now I do.
COLT MCANLIS: Now you do.
OK.
And then I like the GIF, right?
It's sprite sheeted, I guess.
Here's the cool thing.
So a 300 by 120 animated GIF is only 4.4K,
yet we were seeing like full JPEGs that were like 9K that
were static, right?
So I'm not really sure what else do with this.
Let me hit Timeline and see what this is doing here.
This is kind of a little awkward.
So your jQueries are using memory.
So this is kind of telltale.
Do you have a timer?
It looks like you have a timer on your--
AUDIENCE: [INAUDIBLE], maybe the audio player is using it.
COLT MCANLIS: Maybe the audio player.
Yeah, it looks like yeah, it does.
So it looks like there's a timer here.
I don't know if you guys can see this.
It looks like there's a timer here.
And you can see this red square up here, just the Play button.
Just like that Play button has a timer that
needs jQuery and Boostrap-- two jQueries and Bootstrap--
and is allocating like a meg of memory over like seven seconds.
So that's a thing.
Lots of rasterizes occurring in here.
Lots of recalculates.
So not only is it repainting, it's
actually like updating the DOM to repaint.
Let's look at this again.
That's updating the DOM.
Don't know why.
Maybe there's a cool jitter effect there.
You know what?
Maybe I got this wrong.
Maybe I'm actually looking at the Matrix.
Am I looking at the Matrix?
That would be kind of cool.
I'm like-- sorry.
I'm having fun.
It's late, and I have to keep you all awake
for like another five minutes.
So anyhow, I don't like this trend.
You're actually allocating more memory faster
than the other websites we looked at it.
It's probably because you have two jQueries,
but anyhow, let's dig in.
So let's go to profiles.
Again, follow the memory, find the performance problems.
So we follow the asset memory to figure out
where load problems are.
We follow dynamic memory to figure out
where compute problems and render problems are.
Can I click this button, please?
Clicky.
You've allocated too much memory for your site,
and I can't click.
Oh, there we go.
OK.
So let's do record heap allocations, hit Start.
So that's kind of interesting.
You guys see this pattern?
So this is actually really very, very regular allocations that
are occurring, two different sets of it,
but they're almost deleted immediately,
except for the stuff that happened
at the beginning of the trace.
So we're seeing the grey lines.
So the grey lines mean that what was allocated has actually been
freed now.
This is kind of odd.
I kind of want to see where this is coming from.
I like to dig in and figure out why I'm so bald.
So we have the whole thing, yada, yada, yada.
Let's actually just highlight this guy here.
So array, what's-- transition array.
So something's going on inside of V8.
All these are being deleted.
Compiled code.
Is this a deopt?
No, relocation info.
So it looks like there's just some sort of cases
where jQuery is executing-- and again, I see this a lot
with closures.
Closures, for some reason, tend to bring up this pattern.
jQuery's kicking off a closure that's
causing a reflow of your entire page for like a five pixel
by five pixel icon.
So you still loaded faster than the other sites.
Bravo.
Round of applause for that.
[APPLAUSE]
AUDIENCE: Real web pages don't need images.
COLT MCANLIS: Say again?
AUDIENCE: Real web pages don't need images.
COLT MCANLIS: There you go.
You know, I'm a fan of the text web.
That requires drinking to get more information out of that.
Anyhow, let's load up another one.
Pete, how are we doing on time?
AUDIENCE: You've got five minutes.
COLT MCANLIS: Five more minutes.
OK.
Let's clear up quickly, because I'm actually
really interested to try this Robitussin and whiskey thing.
I think we may have something on there.
AUDIENCE: I highly recommend it.
COLT MCANLIS: OK.
Let's try-- here we go.
Let's try this CBN Week.
And we're done.
I think at this time, I don't actually
need to tell you guys what I'm about to do.
This is-- no, I don't want to translate.
I used to be able to speak Chinese.
It was a beautiful language.
So you kind of know what I'm about to do.
I'm going to load up networking.
I'm going to see what images are too large, what JavaScript
is too large, what you're using that you shouldn't be using.
We're going to try to cull assets
and get rid of extra network loads.
I thought the points about sprite sheets
was perfect earlier.
By the way, they shouldn't be called sprite sheets.
They should be called atlases.
You should actually see my Udacity course rant on this.
Everywhere else in the world, in video games,
in film and everything, we call them atlases.
You know what?
Never mind.
Anyhow, let's see some scrolling.
Not that bad.
Let's head over to DevTools.
Let's take a look at this under the microscope, right?
Let's go back to network.
My computer said, I'm done.
All right.
This wil be the last site, and then we'll
actually get to all the questions.
And I think we're going to do a group question.
Right?
Fantastic.
So that's interesting.
So there's already 89 requests, 92 requests, 93, 95.
1.5 megs transferred so far.
1.9-- 2 megs.
2.195.
Let's see if we can go [INAUDIBLE].
So here's something interesting up here.
So notice this grey bar right here.
So in Chrome DevTools, when you look at this Network tab,
basically, you see two values.
You see sort of this semi-transparent
and then this opaque portion of these items.
That semi-transparent value is actually
how long the browser spent waiting to receive the asset.
This is one of the reasons that sprite sheets are actually
so important for you, because each browser has a set
number of limits of open connections
that it will allow to a single server.
For Chrome, I believe it's around six.
Which means if you have six requests in flight,
it'll block the rest of the requests until a slot opens up.
Think of it like a caching FIFO or whatnot.
And so Chrome actually shows you this here on the timeline.
You can see some of these actually waited
a very, very long time.
In this case, it was actually spent,
what is this, 471 milliseconds waiting.
It wanted to request this asset, but it
couldn't because there were other things in the pipe.
And you can kind of see that this is a function of the fact
that there's about 100 requests and 3.6 megs transferred.
For those of you who don't know, the average website
size right now, according to HTTP Archive,
is about 1.1 megs.
And that's for desktop.
They haven't really got into a lot of the mobile testing
just yet.
But obviously, mobile shouldn't be 1.1 meg, right?
So obviously, there's too big a content here.
So let's see if there is any big offenders.
Let's see if images are a problem.
Who thinks images are a problem?
AUDIENCE: Show of hands.
COLT MCANLIS: There's a 300K image.
200K, 197K, 161K.
152K.
What is in that image?
I think that's bigger than raw.
Yeah.
Yeah, obviously, these images are too big.
They're not being optimized.
They should be fixed.
Let's take a look at timeline.
Let's see if anything is going on with memory here.
Anything crazy?
Slow.
Again, timer.
We see this same pattern.
So we see almost all of these pages
are falling into the same pattern.
Also, almost all of these pages, and some of them,
in rare cases, are all using jQuery or jQuery twice.
Closures are being passed off to timers for things
like ads or analytics or marquees.
And this seems to be a common pattern.
But this is obviously is causing a lot of memory
and a lot of churn and some other weird things going on.
I can look at the frames times here.
And so let me actually do this.
I don't know if I showed you guys this tool.
Nope, cancel.
So as I'm scrolling here-- it's not picking that up.
OK.
Never mind.
I won't show you that tool.
Anyhow, let's be done with this for the evening
because I think Pete has some other stuff he wants
to talk to you guys about tonight.
So thank you for your time tonight.
Perfmatters.
Wait, wait, wait.
I'll let you start the clap in a second.
So here's how you get a hold of me.
If you guys, if anything today was controversial or something
worth tweeting or something you just
want to ask more questions about, go ahead and find me.
Make sure you join the Google+ Web Performance community.
There's a lot of great stuff there.
Please, for the love of god, use #perfmatters.
Follow #perfmatters.
It's a brand.
You should wear this at work.
Everything you do, you should be challenging your employees,
your managers, the owners of your company,
#perfmatters, #perfmatters, #perfmatters.
It's going to be the thing that separates
the billion-dollar companies from everybody
else on the mobile web in the next year.
In fact, it already is.
It's already [INAUDIBLE].
Challenge everyone.
Hold them to the standards of #perfmatters.
Now you can start the clap.
Yes.
[APPLAUSE]
COLT MCANLIS: Thank you for your time.