Jaime Yap is a developer for the Google Speed Tracer team. Google Speed Tracer is a Google Chrome extension that will help you debug and find performance bottlenecks in your Web applications. Google uses the utility internally for debugging and finding perormance bottlenecks in commonly used applications such as Gmail, Google Maps, and AdWords that millions of people use on a daily basis. Jaime Yap will be at the Velocity 2010 Web Performance and Operations Conference in San Jose, CA, on June 22nd through the 24th. Jaime Yap will be at Velocity giving demos and answering questions on Speed Tracer, as well as participating in a lightning talk, so you can learn more about Speed Tracer.

Jaime also spoke of the following insights on Speed Tracer and Velocity 2010:

Q: Please tell us a little about yourself and your involvement with the Velocity Conference

Jaime Yap: I’m an engineer at Google I started at Google working on the Google Web Toolkit Team. Steve Souders asked me to participate this year, which is pretty awesome. It’s my first time attending Velocity, so I’m pretty excited about that. I’ll be a part of the performance tools lightning demos, and I’ll also be manning the Google booth doing some one-on-one demos of Speed Tracer.

Q: What is Speed Tracer and what does it do?

Jaime Yap: Speed Tracer is a tool to help you identify and fix performance problems in your Web applications. We’re a chrome extension, and we’ve been working close with the Google Web Toolkit folk, giving some deep looks inside the browser to measure browser performance. We try to give a continuous picture of what the browser is doing when you run your webapps.

So most tools focus on startup latency, for modern Web applications like Google Maps, Gmail, Google Wave, you really need some tools to see exactly what the browser is doing as you run your app.

Q: What is Google Web Toolkit (GWT)? Does Speed Tracer require it to run?

Jaime Yap: GWT is a framework and a programming model for writing Web applications in Java. It actually just compiles Java to Javascript. So in the end, it’s just JavaScript, HTML, and CSS. We built Speed Tracer using the Google Web Toolkit. To use Speed Tracer on your Web applications, you don’t have to write your applications using Google Web Toolkit.

So if you run your Web application with just Javascript, HTML, CSS, and jQuery and so forth,

Q: How long does Speed Tracer to set up?

Jaime Yap: Speed Tracer is a Chrome extension, so all you have to do is go to the extensions gallery and install it. Speed Tracer uses some deep hooks inside of WebKit. To make that available to Chrome extensions and to Speed Tracer, you have to launch Chrome with a  command-line flag. All you have to do is install Speed Tracer is to install it from the extensions gallery in a single click. And once it’s installed, all you have to do is run Chrome with a command line flag.

We have 1 to 3 step instructions on our Getting Started Page. Once it’s running, it’s always running and you can use it by clicking on a single button in the Chrome UI.

Q: What unique features or metrics does Speed Tracer offer?

Jaime Yap: The Speed Tracer team is responsible for coming up with the initial implementation and instrumentation within WebKit, and we’ve been working very closely with the WebKit. And since then we’ve been working very closely with the WebKit inspector people. We both consume the same data, so the timeline panel that just launched with the WebKit inspector, thats a stock part of Safari and Chrome.

Both Speed Tracer and Inspector show timing data thats pretty deep inside the browser by timings we instrumented with native C++ code. These measurements are pretty much only available from this instrumentation. These measurements include layout times, repaint times, time to process scripts, DOM related dispatches, garbage collection passes in the JavaScript engine, etcetera.

We also have been working with AppEngine and Spring Insight, to provide server-side traces. We demoed this in the keynote at Google I/O. What this allows you to do is allows you to view server-side performance metrics, in a single tool, that you can use on a production application.

Also, we’ve designed the UI to draw attention around performance hot spots, and de-emphasizing things that are less important with respect to performance of your application. So I think that the Speed Tracer UI bring a lot to the picture.

Q: Is Speed Tracer able to differentiate between performance problems with your Web application and the browser itself?

Jaime Yap: Speed Tracer does benchmark the browser, but it benchmarks the browser, while you are in your application. So your application itself will have unique performance characteristics on Chrome. So if you application is doing something pathologically wrong in Chrome, you will see it in Speed Tracer.

Im gonna plug Kelly Norton, our tech lead, he gave a presentation at Google I/O called Measuring in Milliseconds Redux, that covers Speed Tracer.

Q: Whats the most interesting use case or problem that you solved using Speed Tracer.

Jaime Yap: There’s been a few ove the development of Speed Tracer. There was a large impact in addressing table rendering performance in AdWords. And they ran into some performance rendering issues in Adwords called layout thrashing. It was a very cool because it was a learning experience for us developing Speed Tracer, and a learning experience for AdWords.

Google Maps, for example, is a really fast, awesome application. It was kind of cool to see that they were using our logging API. I can’t say that we were working with them, so I don’t know what performance problems that they found, but we did notice that they were using our logging API. Thats an honor that a team with such low latency requirements was using our Speed Tracer for that.

Q: What do you have upcoming at Velocity 2010

Jaime Yap: I’m going to give a lightning demo session, where we’ll demo a bunch of performance tools in a 10 or 15 minute demo, and I’ll also be at the Google booth answering questions about Speed Tracer.