Tip:
Highlight text to annotate it
X
>> Got to love that kind of story. So we try very, very, very hard to give you all the
optimization tools that we can, as you've seen and they can be very effective, but if,
what if the application still isn't fast enough. What if you've done everything you can to
make your Java Script small and fast and your application still, still feels sluggish? Well,
actually this does happen. Java Script is not always the main source of latency and
sluggish in an application. There's a whole other world of things that can make your app
feel slow, that have been invisible in the past. I am super excited to be introducing
Speed Tracer tonight as part of GWT 2.0, that's going to help you with the rest of the story.
To tell you that story in detail. I'd like to introduce Kelly Norton, the Tech Lead of
Speed Tracer. >> NORTON: Thanks, Bruce. So first of all,
I just want to say in this Google Developer Event, the great thing about these Google
Developer Events, if you're willing to wear anything up here, they'll give you great shirts,
check that out, awesome. So, if you ever had to fix a performance problem in web application,
this part of tonight's event is especially for you. So, a few of us on the GWT team developed
the reputation for being able to run down these tricky performance problems in web applications.
The great thing about that type of work is if you're able to pinpoint a problem in an
application for a team, you're the hero. Well, at least for a little while. But the non-so-great
thing about it is invariably requires debugging the browser itself. You have to be constantly
building from source. You have to sprinkle in all these little pieces of instrumentation
code into that source, and then once you get it in place, you have to, sift through a reams
of data to find out exactly what in your application is causing problems. And we did this quite
a bit, and while we built a lot of little tools to get through it, every time we did
it, it kept us up late at night, which we--which we didn't like. So, after a while, we realized
that, all this timing code and all these little tools are generally helpful and we wanted
to make them available to all developers. So, we pulled the--we took the instrumentation
code and we contributed it to web kit, which is the browser engine inside of Google Chrome,
and then we took all our little tools and we pulled them together into a larger tool,
that helps you visualize and make sense as all the new data that's now coming out, out
of the browser. And so, we're going to release this tool as part of Google Web Tool Kit 2.0.
So we call the tool Speed Tracer, and it does three things to help you make your web apps
faster. First thing it does is it allows you to monitor application as you use them to
be able to spot performance problems as you--as they happen. The second thing is, exposes
a lot of timing data--exposes a lot of timing data from key parts of the browser, so you
can know exactly what are--what's causing those--those problems, those performance problems.
And the last thing it does is it actually, automatically highlights many of performance
problems we ran into as we were up late at night debugging browsers. So, as fun as it
is to sit here and to tell you the story of how it came about and then explain what it
does for you, it's about twice as much fun to show it to you. So, I'm going to do that
instead. So, get over to the right screen, I'm not going to do Andrew's demo again. So,
I have a web application and I'm interested in knowing how it performs. I'm just going
to use Google Calendar as an example. To get started with Speed Tracer, it's easy. I just
click on the Speed Tracer button on the browser, the interface comes up and we're now monitoring
what's going on inside the browser as we use Google Calendar. Now, if I go into Google
calendar and refresh; then return to the Speed Tracer interface, we'll see that some activity
has appeared. But let me show--let me actually explain what you're looking at. So, the first
thing you'll notice is the sluggishness graph at the top, scrap at the top, we call that
sluggishness graph. It's--it's simply a measure of how busy the browser is while it executes
your application. So it's really easy to use. If--if the graph is low on the Y axis, it
means that the browser is responding well. It was able to respond to the users. However,
if the graph reaches the top, it means that you're keeping the browser too busy and users
may start to notice delays, in other words, they'll think your app sluggish. Now, just
as users notice delays associated with keeping the browser too busy, they also notice when
it takes to load network resources. So, Speed Tracer also has this network graph that shows
you exactly when network resources start and stop loading. You'll also notice that on the
sluggishness graph, the network activity is actually overlaid directly. So it's easy to
correlate the loading and resources with their corresponding events in the browser. And if
you ever try to debug a problem with the XML HTTP request, you'll understand why that's
important. Now, once I find some interesting activity on the sluggishness graph, because
that's where I usually start. I want to zoom into that region and time, so I can push the
zoom buttons at the top, zoom in, or I can use the handles in the overview graph, or
what I usually do is I just select the region directly on the selections graph itself. And
once, I've selected the region, what is showing you here on the bottom is all the significant
events that are contributing to the sluggishness--sluggishness of this application. And if I mouse over these
events, you'll see that on the sluggishness graph, they are actually highlighted and their
duration is emphasized. So, for our final event and I'm interested in knowing more about
where the time went. I simply click on that row and it brings up a detailed breakdown,
includes both, a pie graph form that gives you a breakdown of the types of activities,
but also a detailed waterfall view that shows you exactly what happened and time. And by
the way, as we look at the types of activity you see here, you'll notice many things that
are previously missing from development tools, the things like, the parsing of HTML, delaying
out of DOM Elements, CSS style recalculation, even painting pixels to the screen. These
are all the things that can affect your apps performance, but as a developer they've previously
been completely hidden to you. Another thing I'll--another thing I'll mention is that,
Google Calendar is actually an example of an interactive application. It's not enough
to know that it loads as fast as it can. We also want to know that as the user interacts
with it, it continues to be snappy. So, if I go back in the Google Calendar, create a
new calendar entry. I suspect that after this, I will want some drinks. Then I return back
to Speed Tracer, I'll zoom all the way out, so we can see the full timeline. You see the--there's
some new activity over to the right of the sluggishness graph. By zooming into that--if
I can zoom into that, we can see all the details of the events here, just as we did as we were
loading the application. So another thing that is important to mention, there's many
performance and profiling tools that actually cause a big slow down in your application
as you use them, and it gets in the way. We've work really hard with Speed Tracer to make
sure these sorts of observer effects are negligible. So, if you're debugging an application in
Speed Tracer and the application seems slow, it's not Speed Tracer's fault, it's probably
your code. And now that--since I'm bragging on Speed Tracer a little bit, I also want
to point out, the Speed Tracer itself, we tried to make it a responsive application.
As a matter of fact, many people thought that it was actually a desktop application when
we began showing it around Google. But it's not, it's an HTML 5 application, deployed
as a Chrome extension and it's built with GWT. We want it to be an example of the type
of application that Speed Tracer actually encourages and we're really going to get this
question, so I'm going to answer it, I mean, go ahead and answer. We absolutely did this
by using Speed Tracer on Speed Tracer. So, that's sort of an intro to how to use it and
how to get it started. What I want to do now is take you through a scenario of the types
of problems we're able to pinpoint using Speed Tracer. So, not too long ago the AdWords team
came to us and they said they're having a performance problem. Whenever they displayed
a table in their user interface, it felt like the browser froze or sort of locked up. Now,
I'm not going to show you the entire AdWords application, because it's really complex,
instead I've created a simple, but hopefully dramatic reenactment of how this happened.
So, if I bring up my reenactment, AdWords came to us, displaying the table and application
look ed how, like this. Obviously a little slow and if we look inside the Speed Tracer,
zoom out; and I--I need to find my way to the relevant events and I've made that easy
by using a feature in Speed Tracer that allows us to put some Java Script code in our application
and have it mark directly on the timeline, when that even occurred. I could find that
by finding a blue info bubble on the left. So I'm going to zoom in, just a little bit,
so you can get a better view. You see the blue info bubble on the left, pointing out
the event. Now, the one thing you'll notice about this event, or the first thing you'll
notice is, the Speed Tracer thinks it's sluggish and we saw that when we pushed on the button.
The other thing that amazed us was just how much of this event was being spent in layout.
In fact, in case you can't read that, it's 90% of the time going to layout, and also
if you look at the waterfall view, you'll see it's just a lot of really small layout
events. So, but you'll remember at the beginning of this talk, I mentioned that Speed Tracer
would automatically identify many of the problems that we ran into. This is in fact one of those
problems, it turns out that it's easy to construct your DOM Code in such a way that you cause
the browser to do a layout over and over again. In fact, in many cases, you actually cause
the same DOM Elements to be laid out repeatedly. Speed Tracer is actually calling this out
explicitly, you see on the left there's some hints in the green and orange bubbles. On
of these points out the fact, that we're doing a lot excessive layout here. Now, arm with--armed
with the knowledge of two things, one; that this problem is occurring in our click event
and that two, it's being caused by excessive layout, we went into the AdWords code, and
it turns out, all of this logic was in basically one function. We--we separated two pieces
of very important code. We've separated the pieces of code that built up the DOM Element
from a piece of code that tried to measure how wide those DOM Elements were when they
were on the screen. All in all, very small change, a few lines; however, it made a big
difference in the performance of the application, which I'll show you now. This is about--this
is what the AdWords application looks like now, where they're displaying the table of
the--in the AdWords application looks like now. Going back to Speed Tracer so we can
get a good comparison, and again, we'll use that feature; it allows us to just look for
the info bubbles over on the left. Now, first thing you'll notice that it's much faster,
right? It's barely reaching the top of the graph now. But the other important thing is,
we went from 90% layout to only three percent layout. So with just a small change, I was
able to make a huge impact in the application. And by the way, this is the type of problem
that would have been really hard to find, because layout is usually completely hidden
to you as a developer. You see it is a long Java Script call, but in fact, there's all
this other activity going on inside the browser, like layout. So, let me just show one more
thing, suppose that I find the performance problem in an application just like the AdWords
team did. Now, the first thing I want to do is want to tell my team about it, because
I don't want to fix it myself. I want somebody to at least help me with it, right? So, I
could put together an email that list all the times and try to describe what I saw.
But that's going to be a hard email to type and it's going to be an even harder email
to read. So, what I would rather do, is just go into the tool, hit a save button, save
that file to disk. And then, I'll email that to my teammates. When they get that by email,
simply open it up in the browser again, hit open monitor, and this is going to bring up
the same view that I was looking at as I was looking at the--as I was originally looking
at the problem. So, not only are we seeing the same thing as team--the same thing as
teammates, but I can still use all the controls in the interface to navigate all the data
and even look at some details that the original person that found this may not--may have even
overlooked. So you can imagine how nice it is, if you get a, if you get a bug in your
issue tracker about [INDISTINCT] problems that have one of these things attached to
it. So, if we can switch back to slides; so this is Speed Tracer, it's a new tool, allows
you to monitor your applications as you them to find out where their performance problems;
it allows you to see a lot of these hidden timing inside of browsers that previously
confused and left browsers debugging for days. And then, it also it's automatically identifies
and highlights many of the problems that are common in causing performance problems. Like
everything in Google Web Tool Kit, it's all open source, so we hope that everyone will
contribute. But most importantly we hope that you'll use Speed Tracer in your next application,
to make it as responsive as possible without having to stay up all night, debugging browsers.
>> Thank you, thank you, nice, nice.