Several years ago, we released a little FireBug plugin called YSlow. This tool allows you to analyze your Web pages for performance problems. Among the things that YSlow can do includes measuring page-load time, and beaconing its results back to a home server.
Since then, the front-end performance discipline has grown significantly with page-speed and page-test tools, and also services that trend the results of these tests over time.
One thing's been missing though. While these tools let us measure our pages in the lab (that is, your dev box), what the end user actually experienced was, for the most part, unknown. With the number of variations in operating systems, browsers, plugins, ISPs, network configurations, geography, and microwave ovens, it's impossible to simulate all possible combinations that a visitor to your site might have.
To fill this gap, we're releasing a tool called Boomerang.
Boomerang is a piece of JavaScript that you add to the bottom of your Web pages, where it measures page-load time, among other things, and beacons the results back to your server. It's released under the BSD License, and there's documentation included along with the source.
Boomerang is currently in beta, and we'd love to have more people working on it. So go check out the code, use it, fork it, patch it, and tell us how you like it.
8 Comments
Philip, this is a good initiative and will be really help in determining application performance at client end. We have started using it but that data that we collected in our testing environment is far from reality. We are getting t_done (Round trip time of the page) time as 653 but actually it is 11 sec approx as per firebug.
Hi Ashish,
Can you show me the page in question? Also, I assume you’re testing firebug and boomerang from the same client box.
Philip
Can you explain what beacon.php does? I’m dealing with a .NET environment and would love to give this a try.
It actually does nothing. This is what I have on my own server:
but that’s only because dreamhost won’t let me set a URL handler. Then at the end of the day I go and parse through the access logs and pull out data in bulk. Have a look at howto-0 in the documentation for more details.
There’s also a discussion forum where you can ask more questions: http://developer.yahoo.net/forum/?showforum=127
Philip
looks like the blog ate my code. It looks like this:
header(“Connection: close”, true, 204); header(“Cache-control: no-cache”);
Hello Philip, Boomerang is awesome! I have been messing around with it for the past couple of weeks and have it running on a live server collecting results. However, whilst many of the results come back with reasonable results (e.g. 10 seconds which compares to webpagetest), I do get the odd large round trip times (96 seconds, 109 seconds) and there doesn’t seem to be any correlation with the bandwidths.
Do you have any idea why I may be experiencing this? Any avenues to investigate? Any assistance would be greatly appreciated.
Thanks in advance,
Greg
Hi Greg,
Do you know where these slow beacons come from? There can be a few reasons for this.
The user might have a temporarily bad connection because the microwave just went on or maybe they’re downloading a movie at the same time.
It could be a stale cookie that stored the start time and by some fluke ended up passing all tests. If this is the case, I’d like to investigate it further, but it’s a little hard to debug what the user sees.
The user may be from a country with a bad internet connection to your server
The best thing you can do for now is to just filter out outliers using IQR filtering. I have some details on my presentation on the topic here: http://www.slideshare.net/bluesmoon/index-3441823
Regarding bandwidth, it’s approximate, but should give you an order of magnitude. For real users, available bandwidth tends to fluctuate all the time depending on what they’re doing on the web, and whether their connections are shared with others and if there’s anything else interfering with their signal. Since bandwidth is measured only once a week, there’s a chance that this value won’t be entirely correct for the entire duration, so it may not always correlate. I find it best to use the bandwidth (and its margin of error) to decide on a bandwidth block that the user should fall in to. Pick 4 or 5 blocks, and then aggregate roundtrip measures per bandwidth bucket.
If you have more questions, feel free to post them on the discussion forums since that way we can keep all questions together.
Philip
If you have more questions, feel free to post them on the discussion forums since that way we can keep all questions together.
Thanks & Regards, Chrismartin, http://www.glssystems.net