Google Speed Tracer Makes AJAX Optimization Easier

SpeedTracer-SluggishnessDetailGoogle today announced Speed Tracer as part of their Google Web Toolkit offerings. While most of the GWT focuses on enabling developers to create web applications in Java (which compiles down to optimized JavaScript), Speed Tracer is a useful profiling tool for any developer wrestling with XMLHttpRequest.

What makes Speed Tracer different?

Developers have long used Firebug to identify what AJAX requests were causing bottlenecks and to analyze responses to those requests. Firebug is an extremely powerful tool and does a serviceable job with this approach, but Speed Tracer takes things one step further, analyzing the “sluggishness” of your application by examining how busy or blocked the UI is in your browser. This can help developers analyze why their application feels slow, instead of simply focusing on network-based bottlenecks.

Speed Tracer makes use of specific, unique APIs built into Webkit for this very purpose, which gives it a unique advantage compared to other profiling tools. Instead of simply guessing and checking, developers will now have full visibility into what’s causing their applications to appear slow:

Using Speed Tracer you are able to get a better picture of where time is being spent in your application. This includes problems caused by JavaScript parsing and execution, layout, CSS style recalculation and selector matching, DOM event handling, network resource loading, timer fires, XMLHttpRequest callbacks, painting, and more.

Very cool stuff. What’s more, it’s free, open source, and available for users of Google Chrome right now. Check out their tutorial below:

Google Speed Tracer

Posted in: Cool Stuff, Development, Tech News

Better Memory Management Tools for Web Apps Coming Soon

mem_usage

Developing a “web 2.0″ application brings with it a host of new challenges previously unfelt or easily ignored with older, single-page-load-per-action apps. The browser has evolved from a simple page renderer to an application platform that busily executes JavaScript and receives, parses, and displays loads of new data without ever leaving the page. Developers are now struck with the challenge of ensuring their applications manage memory properly and efficiently—your JavaScript can leak memory, killing the user experience on your site, but also impacting the user’s complete experience with their system across the board.

To date, it’s been a bit of a struggle to manage memory, since developers are essentially forced to rely on their operating system’s memory managers to even monitor the memory usage of their browser. Even then, testing can be frustrating, as Firefox, for instance, stores all tabs in the same process. Google Chrome is multi-threaded; each tab is its own process. Chrome also features its own built in task manager, so you can identify which page is using exactly how much memory, CPU, and bandwidth. Even at its most detailed, the stats available only show aggregate memory and virtual memory usage—these abstract figures make troubleshooting individual pieces of your code difficult to say the least.

The folks over at Mozilla’s Developer Tools Lab are looking to change that by building a memory analysis tool that helps devs understand exactly how their application is using memory, and the behavior of the cycle (garbage) collector:

We plan on the initial implementation of this tool to be simple. For memory usage, we want to introduce the ability to visualize the current set of non-collectible JavaScript objects at any point in time (i.e., the heap) and give you the ability to understand why those objects aren’t collectible (i.e., trace any object to a GC root). For the cycle collector, we want to give you a way to understand when a collection starts and when it finishes and thus understand how long it took.

Ben Galbraith and the team are soliciting help and feedback, so if this is an issue you’ve had to deal with in the past, make sure you comment.

A New Memory Tool for the Web | Ben Galbraith’s Blog via Ajaxian

Reblog this post [with Zemanta]

Posted in: Cool Stuff, Development