João Prado Maia’s Weblog

Simon Perkins of Simtec Ltd (makers of the HttpWatch plugin for Internet Explorer that I mentioned before) was kind enough to get in touch with me via email about my wishlist for YSlow / HttpWatch / AOL Pagetest.

He wasn’t familiar with Selenium, but said that it might be possible to hook up HttpWatch to retrieve performance data dynamically. He pointed to a blog post describing how to do so with Watir, an automated web testing tool written in Ruby. Simtec even has a tutorial about this on their own web site.

While that does sound interesting, it looks like Watir interfaces with HttpWatch with a COM object on Windows, and that’s how it gets the performance information.

The way to do this integration with Selenium would be to expose a set of JavaScript APIs (maybe the same set of objects available through the COM layer?), so one could write JavaScript code to export the HttpWatch information. That’s really what I would love to see.

If that was available, I could write a simple Selenium RC test suite in PHP, remote control a set of browsers from my Linux box, and get access to this performance data from HttpWatch by simply running some JavaScript function.

Here’s one thing that I wish YSlow (or even HTTPWatch or AOL Pagetest) supported: a way to dynamically export the results of the performance grade results. In a perfect world I would run a set of Selenium tests on my development environment, and get access to YSlow’s results from the Selenium API.

Selenium RC allows you to write unit tests in PHP (or a bunch of other programming languages), and get access to the browser as it is executing your test. If you could get access to YSlow’s results from JavaScript, then you could export that information directly to PHP, parse it, and store it. Add a few scripts to build some simple reports and you are done: performance metrics that you can track and act upon.

I was going to suggest this feature at Velocity last week, but there was no time for questions on most of the sessions. Here’s hoping this doesn’t happen next year.

Holy crap. I was bored at lunch time so I started visiting some random brazilian sites and looking at their YSlow performance grades. oglobo.globo.com has a performance grade of 33.

Biggest issues that I can see:

• Tons and tons of HTTP requests (8 external js files; 9 external css files; 79 (!!!) CSS background images)
• Most images have a 20 minute expire time
• No compression is going on for HTML/JS/CSS code
• Everything being served from the same hostname
• No minified JS code
• ETags are enabled

At least they are avoiding CSS expressions :)

This is kind of old by now, but Cuzillion is still an interesting little tool that can help developers trying to figure out critical paths in their XHTML code. This tool allows you to see if including an external script after a CSS file results in extra time to render a web page, for instance.

Steve’s demonstration of this tool at this year’s Velocity conference was very cool.

Google I/O is a self-proclaimed developer gathering happening in San Francisco at the end of this month (just two days though, May 28-29). It seems like a really cool event with lots of sessions about Web stuff in general.

The downside is that there will be around 70 sessions in a two day window, each with a time limit of 1 hour. So it seems like it will be kind of rushed, and I wonder how many attendees will miss a session because 4 other interesting ones are happening at the same time. Maybe expanding the number of days would have been a bit better.

It doesn’t look like I will be able to go as we will be finishing up on an upcoming release of our product.