Monday, October 19th, 2009

Har Har! One archive for Web performance and beyond; Implemented in Firebug and HttpWatch

Category: Debugging, Performance

Steve Souders has posted about the HTTP Archive Specification and how it is now supported by both Firebug and HttpWatch (and hopefully more soon!).

Steve says it best, and it started as his baby, so I will let him announce it:

What’s needed is an industry standard for archiving HTTP information. The first step in establishing that industry standard took place today with the announcement of HttpWatch and Firebug joint support of the HTTP Archive format.

HttpWatch has long supported exporting HTTP information. That’s one of the many reasons why it’s the packet sniffer I use almost exclusively. Earlier this year, as part of the Firebug Working Group, I heard that Firebug wanted to add an export capability for Net Panel. I suggested that, rather than create yet another proprietary format, Firebug team up with HttpWatch to develop a common format, and drive that forward as a proposal for an industry standard. I introduced Simon Perkins (HttpWatch) and Jan “Honza” Odvarko (main Net Panel developer), then stepped back as they worked together to produce today’s announcement.

The HTTP Archive format (HAR for short – that was my contribution ;-) is in JSON format. You can see it in action in HttpWatch 6.2, released today. HAR has been available in Firebug for a month or so. You need Firebug 1.5 alpha v26 or later and Honza’s NetExport add-on (v0.7b5 or later).

Here’s what the end-to-end workflow looks like. After installing NetExport, the “Export” button is added to Firebug Net Panel. Selecting this, I can save the HTTP information for my Google flowers search to a file called “google-flowers.har”.

After saving the file, it’s automatically displayed in Honza’s HTTP Archive Viewer web page:

I can then open the file in HttpWatch:

I’m incredibly excited to see this milestone reached, thanks to the work of Honza and Simon. I encourage other vendors and projects to add support for HAR files. The benefits aren’t limited to performance analysis. Having a format for sharing HTTP data across tools and browsers is powerful for debugging and testing, as well. One more block added to the web performance foundation. Thank you HttpWatch and Firebug!

Posted by Dion Almaer at 4:25 pm

2.6 rating from 43 votes


Comments feed TrackBack URI

I use firebug religiously but I NEVER use it’s built-in Http debugging tools.

Fiddler is far superior and works with ALL browsers so I can debug http traffic across all browsers (and all platforms – its a proxy). Fiddler does so many things that Firebug does not and probably won’t ever do with HTTP traffic (reverse-proxy, auto-responder, and so much more). And it also includes a format for archiving the traffic, much like this article is talking about. IMO, Fiddler is simply the best tool for the job of analyzing HTTP traffic.

Comment by leptons — October 19, 2009

Too bad it is only on windows. Any mac equiv?

Comment by sovtek — October 19, 2009

@leptons – Indeed Fiddler is a great tool, but this article is not about any single tool. Having a common format for HTTP logging will be a great addition to all such tools.

Imagine this – customer X is having a problem with your site that you can’t reproduce. Let’s say he’s running a Mac. With HAR widely adopted you can give him a few simple instructions and he’ll send you a detailed log in no time.

Comment by tsonev — October 20, 2009

@leptons – Fiddler being a proxy is a bad thing as it means it alters browsers behaviour so it doesn’t actually give you a true representation of how you page/HTTP requests would handle over a real life connection.

Comment by simon000666 — October 20, 2009

This is great news. I’ve wanted something similar to export sessions from Charles/Fiddler/Firebug/HTTPWatch/whatever and round-trip this data between the various tools we use. Having a standard format will make it much easier to conduct arbitrary/custom analysis, rendering and reporting to highlight the particular thing you’re interested in.

Comment by sfoster — October 20, 2009

Maybe it’s just the fact that my morning coffee hasn’t kicked in yet, but I’m not creative really seeing much benefit here.

Don’t get me wrong, I’m a fan of creating a standard for anything like this, but I just don’t see many of my clients being comfortable with running the NET panel all the time just on the off chance something might happen. Most of my clients can’t reproduce something in the first place. If they could I would able able to reproduce and life would work out.

Is it a useful performance metric, or is this primarily meant for debugging?

Comment by blepore — October 20, 2009

Would love to try HttpWatch — don’t want to spend $395 on it. :P

Comment by mdmadph — October 20, 2009

excepted that export is not available in the free edition.

Comment by olivvv — October 20, 2009

@tsonev hits the nail on the head – this is about providing a way for people to work together regardless of which tool they choose.

@leptons: I agree – Firebug Net Panel can be inaccurate for web pages that have intensive JavaScript – the page’s JavaScript can mess up Net Panel’s results. In practice, however, I rarely encounter this situation. Since I use Firebug so much, I use Net Panel frequently. One downside of Fiddler is that it’s a proxy so it alters the browser behavior. (See Roundup on Parallel Connections.)

@sovtek: I review a bunch of packet sniffers in Even Faster Web Sites: AOL Pagetest, WebPagetest, VRTA, Fiddler, Charles, Wireshark, and IBM Page Detailer. The key is – how many of these will adopt HAR? Honza pointed out that DebugBar has already added HAR support.

@blepore: Most pages have a consistent performance profile. There are always some variabilities, but when doing performance analysis a single capture is often representative. The ability to save this, share it, and recall it later is huge.

Comment by souders — October 20, 2009

Leave a comment

You must be logged in to post a comment.