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

Lunascape Multi-Rendering-Engine Browser Review: Verdict—Three Trick Pony

lunascape Lunascape is a new browser that allows you to switch rendering engines on-the-fly. Internet Explorer, Firefox, and Google Chrome/Apple Safari all use different rendering engines and JavaScript engines to display your pretty web pages to you. This is the root cause of browser incompatibility issues—different engines interpret things (like web “standards”) differently and so you see pages display differently. This is the bane of a lot of developers, as we have to fight the many, many quirks that abound when we use certain parts of the DOM or certain JavaScript or CSS tricks. For a lot more on these issues, QuirksMode is a great resource.

Lunascape presents an interesting product, though one that’s only in the Alpha stage, so I’m sure we’ll be seeing a lot of things evolve from them. As a developer, I have Firefox, Internet Explorer and Google Chrome all installed and at the ready. It’s pretty simple, though a bit annoying, to boot up IE to make sure a page renders properly, even though we develop under Firefox.  (There are FF extensions that make this a simple right-click affair, however.) Lunascape simplifies the process a bit by allowing you to switch a tab’s rendering engine just with a right-click. And it works, for sure.

But I begin to question the utility of a browser that lets me switch rendering engines, but provides me with very few debugging tools or console access. We develop under Firefox because of things like the Web Developer extension and Firebug. These superb debugging tools let us delve into the DOM and help us identify our many AJAX transgressions. Without these tools, though, the workflow isn’t improved enough to justify a switch from just running the browsers separately.

Now, Lunascape currently supports IE extensions, so perhaps Firefox extension support is on the horizon… but this seems like something that could be very difficult to accomplish, given that XUL (which powers Firefox and the window chrome surrounding it) is a part of Gecko that exists a bit existentially to the site being rendered: Though, if Lunascape itself is XUL-powered, then that would help considerably.

Even still, the appeal just isn’t there for me. Lunascape clearly is betting on its three-trick-pony concept, but that only appeals to developers who know what a rendering engine is. Firefox is a considerably better browsing option for regular end users, so they’re left needing to improve the value proposition for developers and to give us a reason to switch. And they haven’t done that yet. One way they could start is by offering advanced debugging tools, better if they’re rendering engine-specific. Another might be to allow for regression testing in IE: Allowing us to render in older IE engines, like how IETester works.

For now, I plan on leaving this in the Alpha bin it came in and working with FF 3, Chrome/Safari and IE, side-by-side.

See also: TechCrunch & Lifehacker‘s coverage. (The latter, whose screenshot we borrowed.)

Posted in: Development, Reviews