Tip:
Highlight text to annotate it
X
SAM: Without further ado, I'd like to
introduce the first panel.
Our moderator is James Pearce, who does Dev Rel for Facebook.
He tells me that he now spends about half of his time doing
stuff on native.
But his first love is still the web.
And so it's highly appropriate that he's going to be taking
this really crucial session about mobile performance.
So take it away, James.
Thank you.
JAMES PEARCE: All right.
Well, welcome everybody.
As Sam said, this is the performance panel.
I was honored to be invited to come and moderate it.
I guess Facebook's recent history with mobile and the
web has been relatively well documented.
It's, as Michael said, the Zuckerberg quote is "the gift
that keeps giving." But we have obviously made a
commitment on our apps anyway, on the Facebook apps, to
producing the best possible quality experience as we can.
And we've ended up rewriting both of our iOS and Android
apps to be pure native, where they were previously hybrid
HTML5 in a wrapper kind of apps.
And if I summarize starkly the decision we made there, it was
performance.
There was only one reason why we did that.
We had to retrain literally hundreds of developers.
We had to retool our entire build chain to produce iOS and
Android apps where we'd been previously
building a pure web stack.
And pixel for pixel, the old web app and the new native
apps were indistinguishable.
Not anymore, but if you'd put them side by at the time, it
was very, very difficult to tell which was which.
And the only way you could tell they were different was
the performance.
And overnight, pretty much, our ratings in the App Store
for the iOS app went from two stars to four stars.
And let me just say again, it was nothing to do with the
pixels or the appearance or the rendering or the drop
shadows or anything.
It was purely the performance and the increased user
experience of that.
So it was because of mobile web performance that we had to
make this incredible investment.
And we really didn't want to have to do that.
So I'm here mostly to moderate and channel your questions and
channel the questions off the moderator here.
But also I'm going to say, dude, where's my
60 frames per second?
You honestly promised us this years ago.
The web was going to catch up.
But we haven't got it.
And businesses like ours and businesses around the world
are still struggling with this problem.
So I have a panel here of four distinguished experts, two
from the Chrome team and two from external companies.
I'd like them to introduce themselves.
We have Paul, Tom, Ilya, and Ariya.
A couple of minutes each if you wold like, just to
introduce yourselves, please.
PAUL BAKAUS: Hi, everybody.
My name is Paul Bakaus.
I am the W3C rep and CTO for a studio
called Studio 5 at Zynga.
And we're basically on a mission to build what we think
is the next generation of social games.
And we think HTML5 is the right platform for that.
We've been operating in stealth mode for quite a bit,
but now we're starting to roll out our first experiments.
And lots of them really involve performance with terms
like instant play.
We want to make people play the games instantly.
And that's where we think HTML5 comes really into play.
All right, that's me.
TOM WILTZIUS: Hi, I'm Tom Wiltzius.
I'm a product manager on the Chrome team, working across
graphics projects including Canvas, WebGL, but also core
rendering performance.
So I am on the other side of all of this.
ILYA GRIGORIK: Hi, everyone.
My name is Ilya.
So I'm a developer advocate on Make the Web Fast and Google
Chrome teams.
And my focus has primarily been on the network side-- so
specifically for mobile performance latency, how do we
accelerate that?
So HTTP 2.0, SPDY, and just trying to figure out what we
can do to move the web forward and to enable richer apps that
are still efficient when delivered over the web.
ARIYA HIDAYAT: Hi, everyone.
My name is Ariya.
I work for Sencha.
We produce frameworks, tools, and cloud surfaces for web
application, both desktop and mobile.
I have a general interest in web technologies.
I have been mainly the native guy for a very long time.
I worked on WebKit when I was with Nokia.
And then two years ago, 2 and 1/2 years ago, I decided to
switch sides and try to find out how painful or comfortable
it is working with front-end development.
JAMES PEARCE: So now that you know who everybody is, that's
a great opportunity for you to think of the hardest question
you would like to ask each of them.
And hopefully you all have the moderator page up, so you can
ask them there or simply raise your hand.
But to get started with, well, I was thinking about this.
Mobile performance, there's no one thing that contributes to
performance.
It's a blend of lots of different disciplines.
And we expect developers to be masters of all of them in
order to produce highly performant apps.
Sometimes it's going to be the GPU that's the impact or the
major effect on their performance.
Sometimes it's going to be the network performance.
Sometimes it's going to be JavaScript runtime.
So given that the average developer is looking at this
huge surface area of problem that they have to solve, where
should they start first?
What are the major performance pain points that you see from
your points of view?
I guess we'll start at this end and go down again.
PAUL BAKAUS: OK, so I think it depends on what you're
building, really.
But I think if you're building web apps and websites, it's
mostly about load time performance.
I would see load time performance being the biggest
bottleneck right now.
There's been recent studies that e-commerce sites have
been degrading in terms of performance--
I think over 40% percent or something.
And that's very, very worrying to me.
And on mobile, it's even worse.
If the website loads in over 10 seconds,
most people drop off.
And of course, it's not entirely the fault of the
website and the browser.
It's also network performance, network latencies.
But I think that's an area where we
should focus on first.
With games, as longer-lived the sessions are for your app
or for your game, the more you have to focus, obviously, on
runtime performance, memory management, lots of stuff.
But I would start with load time.
TOM WILTZIUS: Yeah, I suppose I'm a bit biased in that I
work on rendering performance, so that's probably what I'm
going to say is the most important thing.
But I do think that we are moving to this world where
people expect a lot more out of web applications.
We're moving from this world of e-commerce sites and the
like, which are strongly rooted in the tradition of the
web as document viewer, and we're moving much more towards
applications where we expect real-time performance.
And I'll call out James's point earlier about needing to
retrain this entire corps of Facebook developers to do
native mobile app development and how painful that was.
But I think it's in some ways unrealistic to expect that the
same developer skill set that applied to building the old
generation of web applications, which were very
rooted in, again, a document viewer-type model--
it's unrealistic to expect that skill set to cleanly
apply to an application that you're expecting to do
something very different.
When you're expecting 60 frames a second and
complicated UI animations and transitions, you're building a
different beast.
It's going to require a different set of skills.
So I think the entire community does need to prepare
for and expect appropriately that a lot of reeducation is
going to be required.
ILYA GRIGORIK: So I work in networks.
And I'm also biased.
But I'll second what Paul was saying.
But I'll also add a few more things, which is there's
obviously the first experience when you first load the page.
And then there's the rest of the experience, which is your
app is loaded, and then the frames per second and
everything matters.
So it's not a question of either/or.
And I would say, if the question is where do you
start, I would actually say it's neither
one of these three.
So internally, we have been talking about render, compute,
and network.
Those are the three pillars of performance.
And the moment you fix one, you're on to the next.
And then you unlock the next bottleneck.
So the place to start is to actually invest into analytics
to figure out where is my problem to begin with.
It's not a question of, I know rendering, so all I'm going to
focus on rendering.
It's like, well, if your bottleneck is compute, that's
where you should start.
So in the network world, at least, we have put a lot of
effort into developing tools like real user measurement
such that you can gather real data from real users and real
hardware and then figure out that, hey, no, it really is a
problem on 3G, for example, from our users to download
these apps.
And I know you guys have done a lot of work to figure out
how to get the games down in sub-three seconds or even
sub-one second.
PAUL BAKAUS: That's right, yeah.
ILYA GRIGORIK: And that's a really interesting challenge.
TOM WILTZIUS: I will also say that's an area where we are
way behind on the rendering side of things.
Your ability to measure in fields anything about how your
rendering performance is, it's really hard, to the point
where you sort of can't do it.
And I think that's the kind of thing we've talked about, for
instance, in the web performance working group,
about what we might be able to do about that.
But I think we're not really closing in on a solution yet,
largely because
implementations vary so wildly.
So if anyone has bright ideas about what they would like to
see from a field analytics API for rendering, I'd
love to hear it.
ARIYA HIDAYAT: So in my opinion, evangelism is one
thing that we need to work better.
We need to come up with better vocabulary to the developers.
Those who work in the front end development space, they
probably never studied computer science.
So if I'm being given the task by my manager to build the
mobile side of the company, and then suddenly I need to
know everything from GPU compositing to JavaScript Just
In Time Compiler, garbage collector, and other
thingamajig, this is all scary stuff.
So that's one thing that we need to work more.
And another thing is also to give the understanding that,
performance not only, but optimizing the passport,
meaning that the bits and piece from the server and the
client, with the rise of single-page application, your
apps might run for a while.
So for example, if you build an address book, and sorting
your contacts, 10 contacts if 10 miliseconds, it doesn't
mean that they will scale nicely if you use bubble sort.
So scalability is also important with respect to
performance and not only time measurement.
JAMES PEARCE: So it sounds to me like there are lots of
individual technical things we need to think
about here as well.
But there is an overall cultural issue, which is that
developers who think the web is something they can just
lash up in a text editor are now being dropped into a very
different world where they are being expected to use tools
with 40-character long command lines and huge, big log spews
that they have to visualize and so forth.
So we can come back to some of the technology, but I'm
intrigued by this because there's a tooling piece here,
which is going to make it a lot easier for people.
And there's best practices around how they should
instrument their apps, both at, presumably, development
time but also at run time.
Maybe the two of you could talk a little bit about what's
happening on Chrome, and then we're going to talk about some
other browsers, too, if you don't mind.
So just give us a quick rundown on tools and education
and instrumentation as is it pertains to Chrome.
TOM WILTZIUS: Sure.
You want to kick it off?
ILYA GRIGORIK: Sure.
So for network, I'll highlight one, which is actually
cross-browser, which is Real User Measurement.
So this is a new API--
well, relatively new.
It's supported by all the modern browsers where when the
page loads, you can actually query it to say, give me all
the time stamps for the sequence of the loading of the
page-- so anything from TCP connection time to there was a
redirect to this is how much time it took to load.
And the cool thing about this is that once you have this
data, this is from a real user on a real
device on a real network.
You can beacon it back to your analytics, aggregate it, and
then segment it in a bazillion different ways and actually
run meaningful A/B experiments.
You can actually figure out that this connection took this
long and so forth and so forth.
So this alone I think has changed the network
performance conversation in a dramatic way, now that we can
gather this data.
We need something like that for GPU.
And maybe it's as simple as sampling this data and
beaconing back via a similar mechanism.
TOM WILTZIUS: Yeah.
And that's definitely the kind of thing, again, where we're
interested in trying to explore.
But it is challenging because the notion--
people ask for things like, well I just want how many
frames a second am I getting.
That's actually not a meaningful question to ask,
because in a multi-threaded browser, you can have one to
four answers to this question.
And you get a different number of answers depending on what
browser you're running in.
So from a cross-browser tooling or analytics
perspective, I think rendering is one of the toughest because
it's one of the areas where the browsers have evolved most
differently.
But I think we are moving towards a world where a
combination of some of the CSS features that have been speced
and the performance needs of the platform are forcing a
slow reconvergence of how a lot of these things work.
So I'm cautiously optimistic that, in the future, we'll be
able to instrument some of these things better.
Sorry, go ahead.
ILYA GRIGORIK: So for Chrome DevTools, we put in a lot of
effort into instrumenting all the right bits of the stack so
that you can get at the root of the problem.
But I think that one challenge that we have today is you
still need a lot of education to know what to look for.
You need to run the trace, and then you're
looking at this waterfall.
And you need training.
I know that when I sit down with somebody--
with yourself or Paul-- and I see you guys go through the
whole workflow, I'm like, oh, there's five tricks I was
never aware of just because I never thought about it.
So what we can do, I think, a better job of is actually
giving these kind of insights to developers, to say here's
an anti-pattern.
Let's flag it.
Let's put a red flag beside it and have a Learn More link.
This is the culture piece.
We need to educate people about what these things are.
I think we've done a fairly good job on the network side
because we've been tackling that problem for longer.
Rendering and other things, we have a lot of room for
improvement.
PAUL BAKAUS: Well I just wanted to say, one big issue,
I think, with rendering performance and measuring
rendering performance is because it's harder to isolate
it on the actual device--
because it might be entirely the user fault why
rendering is down.
He might have lots of apps open that do something in the
background and that consume memory.
And then text just keep swapping from memory spaces.
And that's something that I think is fairly difficult,
because if you get reports in from the same device-- let's
say a Nexus device--
but to completely randomize, it's very hard to construct
data out of that.
I think that's a real challenge.
TOM WILTZIUS: I think to an extent that is a challenge
with network performance as well, though, because it's
entirely possible that, oh, some app
is swamping my loadable--
PAUL BAKAUS: App congestion.
TOM WILTZIUS: Yeah, exactly.
It's the nature of a shared resource, right?
I do think though-- to get back to your original question
about what are some of the best tools available, at least
in Chrome, for debugging rendering performance--
compared to where we were maybe a year ago, we do have
some features that are relatively simple and
incremental, but you get a lot of mileage out of them.
These are things like the Vertical Timeline.
We have rearchitected the way our paint rectangle visibility
feature works.
To work with the latest actual under-the-hood rendering
pipeline, we have a mode that continuously repaints the
entire page, which helps you diagnose what is taking a long
time to paint.
These are relatively simple things, but they can actually
go a pretty long way in debugging sites.
And I know I was talking to Paul Lewis, one of our other
developer advocates, just before this talk about people
who were coming by earlier at the Chrome Perf Alley thing
over at Moscone, and, I think, often weren't aware that this
was a big problem or weren't aware of how they would even
begin to start addressing this but, with a little bit of
education about how to use these tools, actually came
away with a lot of things that they could go
investigate on their own.
So I think, yes, that is cultural.
Yes, that is educational.
And I think we're starting to have some better
tools in this space.
But for the really hard cases, we're still not there.
ARIYA HIDAYAT: So related to the performance and tools, we
also need to educate developers to include
performance metric as part of their development workflow.
For example, you build a fantastic game.
You've built a nice scroller, nice apps, and it scrolls
beautifully.
And then suddenly some intern, junior engineer, whoever, are
checking some code.
Probably he has a good intention, but the performance
drops from 60 frames per second to 30, and there's no
way to detect that.
ILYA GRIGORIK: So can I add just one thing?
So prior to focusing on network performance, I was
actually part of the Google Analytics team, so there's my
another bias.
Performance is a feature.
When we talk about your performance drops, your
conversion drops, your engagement drops, we have good
measurements--
as you mentioned before, where convergence dropped by 4%.
There's not many features you can add to an e-commerce site
that will bump your revenue per user by 4%.
So it is a feature like any other.
It should be prioritized on your backlog like any other.
It's not a sprint that you do at the end to
clean up your app.
It's like, I'm going to build this thing, and then I'm going
to fix performance.
You can't slap on performance, just like you can't slap on
security at the end.
So invest early into measuring this stuff.
How does this actually translate to my users?
I think this is a very, very important metric.
JAMES PEARCE: All right, I want to do a little straw poll
here if possible.
How many people here in the audience, if you're developing
for mobile and you're developing for the mobile web,
if you find a performance problem, do you
know what to do?
Do you feel like you have all the tools you need to be able
to go and diagnose it?
Do you feel you have the understanding about network
GPU, especially in the mobile case, to go and solve that?
Who feels that they are totally tooled up and ready to
go, cross-browser, cross-device.
[LAUGHTER]
JAMES PEARCE: Nobody.
OK, so there's obviously work to be down.
But I think cross-browser thing is important.
And I know this is predominantly a Chrome
session, but I think--
oh, it's Deon.
Deon, where are you?
You have a question which, I think, is to
do with other browsers.
Would you like to stand up and ask?
AUDIENCE: Sure.
Hi, Deon [INAUDIBLE]
Labs.
And so you set up my question very nicely.
MALE SPEAKER: Do you have the mic?
JAMES PEARCE: I'm wondering whether A/V is easier or
harder than web performance at this point?
[LAUGHTER]
ARIYA HIDAYAT: It's wired.
They should have the wireless mic.
AUDIENCE: Hey.
So we have that exact pain point.
The Chrome Developer Tools are amazing.
There's good developer tools across other browsers
and that like that.
But I watch all the developers on the team coming up with
this problem on some ancient Android browser that's being
used by someone in the UK or some BlackBerry user or
someone else.
And they have to go and re-learn a different tool for
everything.
It's like the equivalent that we've joked about before,
where you have "Friends" is really successful on TV, and
then you've got to make the DVD.
And you've got to re-cast everyone and film it again
from scratch.
It just is so painful.
And then you get the Sony MiniDisc version that just has
your buddies in it.
So is there any hope coming there?
TOM WILTZIUS: To a certain extent, this is a pretty
difficult thing you're asking for, because the point of many
independent but interoperable implementations of web
browsers is that the implementations are different.
So if what you really want is visibility into the guts of
the thing, which is, I think, often what people ask for,
then that's tough.
I think, honestly, the real hope is two-fold.
One, the performance pain points that are most obvious
and most easy to stumble on will be ironed out over time
as those real legacy browsers go away and modern browsers
care a lot more and compete with each other to try to stay
performant.
And then from a standardization perspective,
we get very good APIs defined and everyone sticks to them.
We're doing a lot of work to make sure that, especially in
a world with Blink, another rendering engine, we stay as
interoperable as possible when it comes to spec compliance.
But people don't spec performance.
So what we're relying on to make sure performance is just
good is competition between browsers.
I think that's healthy.
I think that's going to work.
And hopefully that will push the performance ceiling--
or floor, depending on how you look at it--
to a point where you don't need to worry as much about
huge differences like these cliffs existing only in some
browsers but not in others.
And we'll get to only things that are fundamentally,
because of the specification or something, too slow, and
then we can have conversations about how we can improve them
by changing the APIs.
JAMES PEARCE: So Paul, I'm guessing you probably have a
fairly large surface area that you're looking to deal with,
and you do have perf specs.
You do know what frames per second you have to get to.
PAUL BAKAUS: That's right.
JAMES PEARCE: Would you like to share those with us?
PAUL BAKAUS: Well, first of all, I wanted to say that,
regarding the specs, I think it's super odd that
performance is not part of spec.
And I've been talking about this on the W3C-level odd.
And what's weird is that in most other standards bodies,
performance is actually part of spec.
So in the LTE spec, for instance, performance is a
large part of it.
And I find it super odd that it's not being done on the
W3C, level.
So that's first.
And so, on the product side, we are also taking performance
very seriously from the start and adding it to the spec.
So we'd like to be at 60 FPS for run-time
performance, sure.
We have goals to stay below three seconds for load time,
at least on Wi-Fi And LTE.
If you're on a 3G connection, all bets are off, because even
just activating the radio signal to the next cell can
take up to a couple seconds.
So at that point, you don't have much influence over it.
But yes, I think the point about regression that Ariya
mentioned is a good point, because if you have it in a
spec really early, performance metrics for your features,
what you want to build, you start thinking about it
differently.
And with every commit, you continue measuring if it
degraded your performance or not, whether
you're still on track.
And I think that that's what's super important, not
specifically whether you're looking for to have your
upload in three or five seconds, but really just
making sure you have a spec.
JAMES PEARCE: And what is your target device portfolio?
Do you set the floor at a particular version of a
particular browser?
And--
by the way, I'm interested-- what do you do for users that
happen to have an inappropriately poor device?
PAUL BAKAUS: So I'm happy to say that the stuff we're
building right now has a fairly large
set of browser support.
So, for instance, on Android, we're targeting
Gingerbread and up--
which is, as you know if you've worked with Android on
mobile performance, Gingerbread is quite a
challenge because it only has the stock browser.
Well, I'm not sure if you can install Chrome mobile on
Gingerbread.
I don't think you can.
ARIYA HIDAYAT: You can install Opera.
PAUL BAKAUS: You can install Opera, but not many people do
it, I think.
At least that's my guess.
I don't have data on it.
Sorry about that.
But yeah, it's a real challenge.
That being said, I also think there's a place to build games
and apps that push the edge.
I just wrote a blog post about this, actually.
I was arguing that many managers really think HTML5 in
particular has a performance issue.
I don't think that's fair.
I think no user complains--
well, some do, but I argue they're stupid.
But usual users don't complain that their latest PC game
doesn't run well on their
10-year-old Windows XP computer.
But people do with HTML5.
I see managers trying to load apps in IE8 on bad hardware,
and they're complaining about it.
And that has to stop.
That's just not fair.
And I think we need to push it more.
ARIYA HIDAYAT: So we can also view it from a different
perspective.
How many of you here have heard about RoboHornet?
Oh, good.
So the idea behind this benchmark is to come up with a
common set, bearing any standard performance metrics
from the standard bodies, that can be run in all browsers.
And that should be, if you've got the buy-in from the
browser vendors--
for example, inserting a thousand rows in the table
should not get slower as the browser gets new release.
For example, IE12 should not be slower compared to IE11 or
IE10 with respect to doing that kind of stuff.
So if that is part of the development workflow from the
browser vendor themself, then they know for sure that, hey,
if I degrade this performance, then some real-world
application like Google Apps or frameworks like Sencha
Touch Mobile that will have a performance impact.
ILYA GRIGORIK: So getting back to the tooling question across
different platforms, I think we have some good answers for
the network side.
So for example, we have project open source products
like WebPagetest which allow you to run a test against
different browsers-- so IE, Chrome, and the rest-- and get
the same visual output.
And that is already a great start because I know DevTools
really, really well, but I haven't been using the IE
tools for a while.
So at least now, you can put them side by side and say,
here's A. Here's B. And now I can compare the waterfalls and
compare that.
And we've developed, basically, bottom-up specs for
that-- so HTTP Archive Spec, where we can right-click on
the waterfall and export it and import it
into a different tool.
We have an export for the Timeline in Chrome, but we
don't have a tool.
It would be cool if you could export a rendering timeline
from Firefox and also have a similar tool where you could
compare them and say, I'm getting x FPS here and y FPS
over there.
That's all doable, I think.
TOM WILTZIUS: Yeah, again, modular the fact that people
ask for FPS not realizing that this is a difficult thing to
really standardize what the term even means.
But your point's absolutely a good one.
And actually I'll tie that to what we were saying about
measuring performance regressions.
We have a framework, I guess I'd call it, that we've used
to monitor Chrome performance as we develop Chrome.
It's called Telemetry.
It's something you can go check out.
We have some documentation on the Chromium Dev site if
you're interested.
But basically it's a Python harness that talks to Chrome
via the Chrome Developer Tools protocol and instructs it to
do simple things like load a page, scroll it, get a bunch
of stats back out.
But again, these are implementation-specific stats,
which is painful.
But then we can monitor for like scrolling performance
regressions, for instance.
And if people like external developers want to plug their
own content into this and keep the version of Chrome fixed
but iterate on that content, I think this could be a useful
tool for that.
ILYA GRIGORIK: So I think what we can do to make that better
is make it simpler.
TOM WILTZIUS: And then make it work across browsers.
ILYA GRIGORIK: Because if you would do a WebPagetest, as I
come to a web page, I type in, literally, the name of the
page, and I just say IE10 or IE9.
And I'm done.
Right now to run Telemetry, it's like, yeah, check out
Chromium and just build it.
It's like, look.
And then there's the fact that it's a [INAUDIBLE]
checkup.
TOM WILTZIUS: It does work with stock Chrome matter.
But yeah, your point's a good one.
And I wonder--
I don't know if we need to get buy-in from other browser
vendors or what-- how we can make this
work with other browsers.
We need a standard way of communicating from outside the
browser in.
JAMES PEARCE: So we actually have a related question on the
moderator here, which is the from Andre Behrens.
Here?
No?
Yes.
Would you like to come up and ask it regarding Chrome
performance versus--
ANDRE: Sure.
JAMES PEARCE: You're on record.
[LAUGHTER]
ANDRE: Great.
Yeah, my question was simply--
I have a pretty heavy app that I work on--
why is the performance on certain things quick as the
dickens on an iPad currently and not on a Nexus 10?
Are they cheating?
Is there a hardware cheat?
Or is it just enough time?
Or where are the slowdowns at?
Because I notice them sometimes.
It's a lot better, but I notice them.
TOM WILTZIUS: You're talking about rendering
performance, I assume?
ANDRE: Yes.
TOM WILTZIUS: Or do you have specific operations in mind?
ANDRE: The one that really gets me is touch response and
rendering after the touch response.
And I'm doing a big, heavy, nasty thing.
It's that I'm moving a lot of DOM nodes around.
But on the Pixel, it's really great.
On my computer, it's really great.
On the iPad, it's really great.
On most Android devices, it's pretty good.
And I'm wondering what the difference is?
TOM WILTZIUS: Yeah, so some of this is a resource question.
I love the comparison between iPads and iPhones and Android
devices because it shows we're in the same league, even
though they're half the price.
But I do think that it remains a challenge for us to make
good on all the performance promises of comparison.
So to a certain extent, we have our work
cut out for us there.
But it is something we're working on very hard, and
hopefully we'll just get better underneath you
as time goes on.
The latest versions of Chrome for Android, which is to say
those that have come out in the last few months, have
actually a radically different rendering architecture than
the ones that came out, say, at this time last
year, at I/O 2012.
And we're going to continue making changes at almost that
big a pace.
So right now, one of the things we're looking at, for
instance, is what can we do about input latency, which
it's probably not the exact silver
bullet for your problem.
But it's very much related.
And part of Chrome's very complicated multi-process
architecture is that we do a lot of threat hopping, and
this is really hurting performance when it comes to
input latency.
This is something we're looking at
revamping right now.
So our hope is a lot of this will get better.
I don't think there's anything fundamental here.
I do want to point out one other thing
though, which is also--
I don't want to make excuses, but it is a lot more
challenging to change things that are so related to things
like touch input because they we work across five operating
systems, not one.
And that's a major challenge.
JAMES PEARCE: OK.
We're actually a little pushed for time.
Time flies when you're having fun.
But I did have one final question, and then we're going
to go around with the conclusion,
which is perhaps related.
I'm not sure if there's a GPU issue or a networking issue.
But I have a very specific question from Charles Ying,
which is, are there any efforts in place to optimize
the power consumption of Chrome right now?
This is something that web developers have never really
thought about before, but now they do have to.
TOM WILTZIUS: I can speak to this one if you want to.
ILYA GRIGORIK: So I'm curious about the "do have to." Do you
have a good example in mind?
Is that something that you guys optimize for?
JAMES PEARCE: Well on the assumption that people spend
25% of their time on smartphones on Facebook, I
suppose we have a responsibility to make sure
it's not using up their batteries too much.
But I would imagine the same goes for games.
You don't want to be the, quote, "app that is
responsible for killing someone's battery in a day."
ILYA GRIGORIK: So I think maybe a year ago--
we were just talking before this panel--
talking about FPS in a browser was a new concept
for a lot of people.
I think talking about battery life today in a browser is a
new concept for a lot of people
because, what do you mean?
I'm just rendering a web page.
That is not the case, because we're building apps.
And these apps are running for a long time.
They have memory leaks.
They have other things.
On networking side, there are lots of great examples where
we're doing things wrong today--
things like, let me just slap on a real time analytics
beacon on my page, because it's awesome.
I get a nice vanity dashboard that shows me the number of
people on my site.
And then every five seconds, you're pinging the radio and
just burning the fricking battery on the device.
And so those are good examples of where we need
to fix these patterns.
I think we need to educate developers.
We need to educate the companies that are building
these things.
Google Analytics actually addressed this
about a year ago.
But I've done a recent survey of other real-time analytics.
They're all doing the same problem.
TOM WILTZIUS: Yeah, I think, to be perfectly honest, from a
rendering standpoint, we are so bottlenecked on core
performance right now that power consumption, while we
definitely worry about it, it's lower on our
hierarchy of worries.
And the reason is that, as we improve performance, we are
only going to improve power consumption.
So right now, to scroll a web page in Chrome for Android on
an older generation Nexus device-- so a Nexus S or
something-- yeah?
Greg, you want to say something?
GREG SIMON: Yeah.
TOM WILTZIUS: Burns all your CPU, which
burns all your power.
So we got to fix that.
GREG SIMON: Yeah, we do care a lot about power.
And we're actually working right now on making changes to
our Telemetry, which is a Python framework for running
tests on Chrome Desktop, Chrome OS, Chrome on Android.
So we're working on making changes to
actually measure power.
Sorry, I am Greg Simon.
I work with the Blink team and others.
ARIYA HIDAYAT: So in some cases, this also needs some
cooperation from the hardware vendor.
For example, Qualcomm has a very nice profiler.
I can't remember the name.
But that gives you the exact measurement of the consumption
from the radio to the GPU.
And that's very important metrics because if I build my
game using WebGL and then suddenly it burns more power
than as if you would have written with [INAUDIBLE], then
that's not good proposition.
ILYA GRIGORIK: And I just want to add, one thing I'd love to
see as part of either DevTools or any sort of tool chain is,
for example, visibility into the radio.
Paul, you mentioned that sometimes just turning on the
radio takes, literally, seconds and
burns a lot of battery.
Having understanding and visibility into how the radio
operates can have a huge impact.
We don't have any
instrumentation across any platform.
Even the native apps don't really have good
instrumentation.
I was looking-- so Qualcomm is a great example.
AT&T actually has a great tool.
There's basically no other tool where you can actually
record a session on your phone, and then--
it's not an exact measurement-- but it will
model the radio states and the actual battery consumption.
It'll tell you, this app consumed x
many joules of energy.
And that's a start.
JAMES PEARCE: Cool.
We have time, I think, for one question from the floor.
AUDIENCE: So we were talking about actual performance and
real numbers and what we could do to improve things, but we
were also talking about the education.
Do you think we should put more time into educating
people about perceived performance?
Because we only have certain limits that we have right now,
like 3G, so should we talk more about, not fall-backs,
but different angles of how to make things better for users
without building new devices?
PAUL BAKAUS: Oh, yeah.
I would say absolutely.
I think that's a great point.
As internal at Zynga, we always think about actual
performance and perceived performance, responsiveness.
And that starts with easy stuff.
If you click a button, make it do something
while you're waiting.
Or if you're loading your page, show a loader.
Do something.
Put something out to the user, so that anxiety of waiting
isn't perceived the same way.
And there's all kinds of techniques to do that, and I
think it's important to educate people about those.
JAMES PEARCE: Any interest in getting one more question in?
Do you want a question?
AUDIENCE: No, actually, I want to answer the power question.
JAMES PEARCE: Oh, wants to answer the power question.
Unless anyone has any more on that previous point?
TOM WILTZIUS: No, you should let Chris go for it.
JAMES PEARCE: Go ahead.
AUDIENCE: So I'm Chris [INAUDIBLE].
I'm the tech leader for the Chrome for Android.
So I think to answer the power question is Android actually
does have the tools to measure the power, and they're very
precise, the tools.
The device is called the [INAUDIBLE] device.
They basically replace the battery on the phone, and they
measure on the per-amp base for all the actions.
And then they publish all the open source how to hook up the
tools with Android platform.
So if you have a web app, you can run the apps and then to
monitor what action can trigger it.
So as a developer, I will suggest the things is try to
not put a lot timers, especially just because on the
mobile device, when CPU is running in the high frequency,
it is burning a lot of battery.
And for the multicore devices, sometimes they
keep one core working.
But if a CPU working load is higher, they're going to bring
up more cores.
So the more cores means more power usage.
And then they have this way is basically after a couple
milliseconds, no activity, they're going to
crank down the power.
But if you keep every, say, two seconds and you fire a
timer yourself and try to check something in the
background, and if nothing happened, you sleep.
But the device is going to basically keep running this
high power mode and then basically
going to burn the battery.
And also things for the radio things is every time one radio
is taking a little bit of longer time to bring up, and
then they normally keep it in the longer times.
And another case, for example, as Wi-Fi.
So probably people having device with the Wi-Fi this
week experienced the bad experience, bad battery life
in the Moscone center.
Because Wi-Fi bad, so the device keeps trying to connect
to the Wi-Fi, and then that also burn the batteries.
JAMES PEARCE: Two minutes?
Got two minutes left?
All right, OK.
We started late.
We are using up time.
So if we could just quickly go around, I have two questions.
You have 30 seconds to answer two questions each.
And the first question is if I'm an average web developer
and I want to take away something that I can start
doing right now to make my web apps more performant, what
would that one thing be?
And secondly, if you could cast a magic spell to make
mobile web performance a better place, assuming you had
the power of the Google Chrome team for example, what would
that one thing be?
Go ahead--
30 seconds each.
PAUL BAKAUS: OK, so first thing, I'm going to give you
an actionable item on actual improving your perceived
responsiveness of your app but also saving your battery life.
And that is any time the app doesn't have anything to do--
for instance if your app needs a login flow.
So you started a login, username, password, input--
at that time, do a big network burst to load all your data in
the background because, after the user logs in, he will have
all the stuff loaded already.
And the chance is very likely he doesn't quit the app before
logging in, so that's a great point in which you should be
loading data.
JAMES PEARCE: And the one thing you
would fix if you could?
PAUL BAKAUS: The one thing I would fix
is, let's see, scrolling.
Yeah, give us good scrolling APIs on Chrome Mobile.
TOM WILTZIUS: You want the APIs?
PAUL BAKAUS: I want APIs.
Yeah, Microsoft has them.
Chrome doesn't.
TOM WILTZIUS: All right.
I guess my one takeaway would be that you should be aware
that jank is a problem, and it's a hard problem to solve.
But we do have some tools to solve it, and I would
encourage you to check out a lot of our developer relations
resources on how to use Chrome's DevTools
to fight that jank.
I gave a talk about this yesterday, but even basic
tools like Show paint rectangles or Show composited
layer borders or the Vertical Timeline go really far.
JAMES PEARCE: And you are the fairy godmother, so what is
the one thing you can fix for everybody?
TOM WILTZIUS: Yeah, right.
That's a good question.
I guess I was going to phrase my answer somewhat
differently, because I wasn't going to fix something.
I was going to change the way a lot of the web's
specifications were built so that we're not stuck in such
complicated scenarios.
JAMES PEARCE: Ah, that counts.
That counts.
Go ahead.
TOM WILTZIUS: There are a lot of things that we would like
to be able to do that we're a little bit hemmed in by the
immense, expansive API service of the web.
So I am happy that on mobile we've been able to move a
little bit faster.
I want us to be able to move a little bit faster everywhere.
I think one of the ways we're going to do that without
actually causing pain by changing things is by
introducing new primitives into the web that are going to
allow us to have the pit of awesome--
the things that are only going to be fast, but you're going
to be able to do less inside of them.
We have ideas around, for instance, infinite list
containers that are just going to work.
And you won't be able to have crazy overhanging floats, but
it'll be fast.
And that'll be good.
JAMES PEARCE: Infinite list
controllers in a pit of awesome.
Yeah.
Can we have that by tomorrow?
TOM WILTZIUS: Sure.
JAMES PEARCE: Thank you.
Ilya?
ILYA GRIGORIK: Let's see, so maybe coming back to perceived
performance, I think that's a really good point.
And coming back to education as well, I think developers
should learn about the radio and how it works, this mobile
radio thing.
Because we keep complaining about mobile network being
slow, unpredictable, so much latency, variability.
Once you actually learn how the basics of
those things work--
you probably need to spend a couple of hours just reading
about how it works--
you can actually model most of these high-latency
environments really, really well.
Anticipate them, and then you very quickly realize that an
average thing, like an average request over
3G, will take a second.
That directly tells you something about how you design
your application, how you structure, how your UI works
and all the rest.
JAMES PEARCE: Magic wish?
ILYA GRIGORIK: Magic wish--
faster than speed of light travel, because that would
solve all of our latency problems.
JAMES PEARCE: That is magical
ILYA GRIGORIK: Right.
That network performance-- solved.
But I don't think we're going to get that.
Yeah.
JAMES PEARCE: All right, well, never mind.
[LAUGHTER]
ARIYA HIDAYAT: So like what Ilya said, treat performance
as a feature, automate performance measurement, put
it as part of your development workflow, CI system, whatever,
even if it's just a simple smoke test.
Create that git precommit hook that blocks the check-in if
something gets lower.
JAMES PEARCE: All right, and the magic wish?
ARIYA HIDAYAT: The magic wish--
so, more parallelism.
So the Samsung Galaxy S4 Internet Edition this eight
core CPU, a big-LITTLE Endian and a big-LITTLE architecture.
So I think we're going to see probably 16 core mobile CPU in
the near future, so more parallelism in the browser
will be very awesome.
JAMES PEARCE: All right, that's it.
We're over.
That's a wrap.
Thank you, everyone.
[APPLAUSE]