MALE SPEAKER: So we're here back at Devoxx, and I'm here
with Ilya Grigorik, who's here talking about performance and
Chrome dev tools, and performance of front
ends and web apps.
So welcome.
ILYA GRIGORIK: Thank you.
MALE SPEAKER: You were covering two things.
First of all, in the university session, how to
make a website's performance.
And performance is kind of a black art, I
think, to a lot of people.
And browsers, at the same time, are
pretty complex things.
They're almost like an OS.
So should people try to understand how it's built, or
are there any low hanging fruits or methodology to get
your things to--
ILYA GRIGORIK: So really, it's both.
You should always go for the low hanging fruit, because, by
definition, those are the low hanging fruit.
But I think in general, if you want to build an application
that is performant over the long term, you need to
understand how the mechanics of your operating system work.
And you mentioned that the browsers are increasingly
becoming like an operating system.
They absolutely are.
You have networking, you have graphics, you have everything
in between.
There's literally not a computer science problem that
we're not pushing boundaries on in the modern browser.
That's not there.
So that was in large part what the session was about.
Of course, you can only fit so much into three hours, but
nonetheless it was like three hours of here's how the
browser works.
MALE SPEAKER: And people can find your slides online if
they Google them, I'm sure.
We'll have a link somewhere so that people can find them.
I think they're very useful, even with us.
And it will be on [INAUDIBLE]
as well for people to watch.
So how about things like page speed or using CDNs or DNS
lookups is an obvious thing people don't always look into.
These are all good things.
ILYA GRIGORIK: So these are all techniques, right?
These are all one component of a larger picture.
So in the web performance community, if you will, we
kind of have this distinction, which I don't think is
actually necessarily even fair, which is back end versus
front end performance.
Which is like, the stuff that happens on your server, and
then everything that the browser does.
Whereas I like to take kind of like a holistic picture, and
say, well, the lifetime of a page or your app or what have
you, needs to take into account both.
Because sometimes maybe your app is blocked on DNS, and
then the question is, how do I find out?
How do I measure it?
I guess kind of the other meta point that I like to make
about performance is a lot of people treat it
as a technical metric.
It should be a business metric.
Performance is a feature.
There are products out there where speed is a feature.
Think of Google search.
Speed is a feature, absolutely, and you should
design for it as such.
So if you can connect speed and performance to your
business or bottom line metrics--
and in fact, I've shown a number of case studies from
other companies outside of Google where they see a direct
correlation between how fast the page loads and my
conversions, or bounce rates, and everything like that.
If you can show that to your CEO, CFO, your team, even,
that's a viable metric, as opposed to just being like, on
a weekend, I'm going to spend my 20% time
optimizing the page.
MALE SPEAKER: Well, and it's interesting to see how people
actually start using Chrome dev tools as more like
development tools, not just the afterthought, the tool you
bring up to fix performance after you've built it.
So people are spending more time in tools such as the ones
provided in Chrome.
ILYA GRIGORIK: Yeah.
So that was kind of my second talk, which is, the whole
premise is the browser is probably one of the most well
instrumented platforms that we have today.
And you may just not realize it yet.
That was kind of the tagline, right?
And you can do all kinds of stuff.
You can do detail, network debugging, look at the
graphics pipeline, look at the low level networking, and in
fact, you have to.
Once you actually get into the weeds of what is the browser
doing, that's what you need to understand.
MALE SPEAKER: OK.
ILYA GRIGORIK: And it is almost like
an ID at this point.
MALE SPEAKER: True, true.
I see a lot of people, a lot of developers actually using
it as such.
So you actually looked at the Devoxx website as well.
ILYA GRIGORIK: Yep.
MALE SPEAKER: And you have a few things to share with our
friends organizing the conference and
running this website.
What kind of things did you find, and are they typical of
things you find elsewhere?
ILYA GRIGORIK: They were actually typical, and I have
to say, the Devoxx site actually was pretty good, all
things considered.
So no complaints there.
So some interesting takeaways.
An average page on the internet today is about one
megabyte in size.
One meg.
I find this number surprising, right, the first
time I heard it.
And it's composed of over 80 requests.
So one page, where there is 80 resources--
images, JavaScript, CSS--
that need to come in to compose the page, and we're
connecting on average to over 30 servers to fetch all of
that data, right?
And of course, as users, we expect all of this to happen
instantaneously.
It's like, yes, connect to 30 servers, compose all of this,
and just instantly display it.
I think for Devoxx, if memory serves, it was more requests.
It was like 140 requests.
But nonetheless, it was structured well, so it loaded
pretty fast.
So they did a good job.
MALE SPEAKER: So somebody must have been using Chrome tools.
ILYA GRIGORIK: Yes.
MALE SPEAKER: OK, cool.
So you also covered something about the difference between
latency and bandwidth, and how developers should look at it,
how it's really important.
ILYA GRIGORIK: Yeah.
So this is a big aha moment, I think, for a lot of people,
where you turn on your TV, you watch the commercials for your
ISP, and it's like, get the latest 4G, highest speed,
whatever bandwidth connection, right?
And oftentimes, I think, we think of speed and performance
on the web as just bandwidth.
Like, can I get a bigger pipe, if you will, to my house?
Because that'll solve all problems.
If we have bigger pages, so what?
We'll just get more bandwidth.
The problem is, bandwidth doesn't actually help after a
certain point with web browsing.
So as we said, we have 80 requests.
We have many parallel connections.
And if you kind of go into lower levels of how TCP works,
we don't actually use all the bandwidth at the beginning of
the TCP connection.
So you're actually bound by latency.
And unfortunately, latency is not changing.
We have this annoying thing called the speed of light, and
it's like, we just can't figure out
how to go any faster.
So because of that, we need to pay attention to latency.
This is-- you mentioned CDNs.
The whole point of a CDN is to get a server closer to the
user, such that we can terminate
the connection faster.
That is the prime point there.
And just understanding why you need that is very important.
So if you're running a site here in Europe, and your
server is in the US, because you're using some cloud
provider, you're penalizing all of your users by a
significant margin-- like 150, 200 milliseconds.
MALE SPEAKER: And eventually you're not making as much
money as you should be.
ILYA GRIGORIK: Right, and in all likelihood, your bounce
rates are higher, and other things.
MALE SPEAKER: So speaking of all of this, how much of that
is going into innovation and standards?
I mean, I hear about HTTP2 maybe coming along.
Can you say a word about that, and how maybe that was
inspired by [INAUDIBLE]
Google?
ILYA GRIGORIK: Yeah.
So actually, one of the efforts that we've been
sponsoring at Google and working very closely with is
the W3C web performance group.
So this is a group that was started a couple years ago,
and it has already created a number of standards, like
navigation timing.
Navigation timing allows you to get instrumentation data
out of the browser for things like, so how long did that DNS
lookup take?
You couldn't access this data maybe even a year ago.
So we have this now, and you mentioned HTTP2.
So that was also in some part driven by SPDY.
So this is a kind of experimental protocol we
deployed at Google, and it's available in Chrome, Firefox
and Opera now.
MALE SPEAKER: Is it fair to say that it's
used in most services?
So if you're using the Chrome browser, and you access a
Google service, it's actually--
ILYA GRIGORIK: Yep.
So Google servers speak SPDY.
Chrome speaks SPDY.
So if you're accessing our service-- if you're reading
Gmail, or doing Google searches via HTTPS, you're
running over SPDY.
You're not running over HTTP.
Now, here's a caveat.
SPDY is not a replacement for HTTP.
HTTP is still the same, but we kind of
changed one layer below--
basically, how we send the messages on the wire.
And by virtue of changing that, we can actually make the
transport more efficient, so it can push multiple resources
over the same connection.
So the HTTP 2.0 effort is basically that, or at least,
we have a charter now for that working group-- the IETF
working group-- which is going to take SPDY version two of
the protocol that we designed, and use that
as a starting point.
So in the coming year or couple of years, hopefully
we'll standardize it and release it as HTTP 2.0.
MALE SPEAKER: OK.
Great.
That's exciting to hear.
ILYA GRIGORIK: And the world will be a better place.
MALE SPEAKER: Of course.
That's what we all aim for.
Let me close with a final question.
What about mobile in this whole picture?
That's probably someplace where performance is as
important, if not more important than desktops and
typical browsers.
You have also browsers there, and tools are actually
available to help you with that.
So what are we doing there?
ILYA GRIGORIK: So everything we just talked about applies
to mobile, especially bandwidth and latency.
So of course we still have room for improvement in terms
of bandwidth and mobile.
Having said that, latency is much worse than desktop, for a
number of reasons which we won't get into here.
But it only makes it more important that we design with
efficiency in mind, like reusing connections,
leveraging all of the caches, and all the rest.
We also are building--
I think we are building, but we still need a lot better
tools for mobile.
So for example, in Chrome, we have remote debugging, and
this is very important, not just because you can connect
to your phone and kind of pull the data out of it, but you
can actually simulate and use the wireless network on your
phone to feel how the page looks, or how it downloads, if
you will, or even how it executes.
We develop our mobile apps on our desktop.
We run it in an emulator, which is still running on your
beefy quad-core with whatever graphics card.
Then you put it on your little phone, right, and it's still
underpowered, comparatively speaking.
These things are getting very good in terms of computing
power and all the rest, but nonetheless, orders of
magnitude less.
And then it just feels very different, right?
So with Chrome dev tools, you can now use all the same
tooling to debug on your phone, which is awesome.
I think we still have more room for improvement, though.
MALE SPEAKER: OK, great.
So looking forward to those improvements as well.
Thanks for taking the time.
ILYA GRIGORIK: Thank you.