Tuesday, November 25th, 2008

UA Profiler: A second look

Category: Browsers, Performance

We posted on Steve’s UA Profiler tool, and John Resig has taken a nice look at the current results.

It actually now looks like Minefield (Firefox nightly) is getting 10 out of 11, and the other browsers are doing great too.

Jonas Sicking of Mozilla has a really nice comment that talks about what the engines are doing and some nuances. For example, if you have a CSS file and a JS file, do you block just in case the JS looks into CSS values (e.g. “in case there is a call to .offsetTop in the script”). How about looking ahead to see? That is the case. You can download away and try to do the right thing. document.write() is another beast that seems to do a lot of harm. Having the browser be smart about it (“they don’t do that”) will be good.

Back to John, he also discusses features that we can use as developers:


This is part of the HTML 5 specification and allows for pages to specify resources which should be opportunistically downloaded in case they should be used in the future (the common example of image rollovers could be used here).

There’s a full page describing how to use them on the Mozilla developer wiki but it isn’t that hard to get started. It’s as simple as including a new link element in the top of your site:

  1. <link rel="prefetch" href="/images/big.jpeg">

And that resource will be downloaded preemptively.

Inline Images

The final case that the profiler tests for is the ability of a browser to support inline images using a data: URI. Data URIs give developers the ability to include the image data directly within the page itself. While this saves an extra HTTP request it’s important to note that the resource will not be cached (at least not as external resource – it may be cached as part of the complete page). The use of this technique will vary on a case-by-case basis but having a browser support it is absolutely important.

Posted by Dion Almaer at 9:16 am

3.9 rating from 16 votes


Comments feed TrackBack URI

How is it that FF2 could do Cache Redir and FF3 cannot?

Comment by Vordreller — November 25, 2008

I believe its something in the HTML5 spec:

Comment by TNO — November 25, 2008

@Vordreller: It was a regression in Firefox 3. The UA Profiler helped the Mozilla team to catch and identify the issue. Once it was spotted it was resolved nearly instantly (and will be working again in Firefox 3.1 as a result).

Comment by JohnResig — November 25, 2008

Leave a comment

You must be logged in to post a comment.