Browser Page Load Performance

November 24th, 2008

Steve Souders is currently doing more to improve the performance of web pages and web browsers than anyone else out there. When he worked at Yahoo! he was responsible for YSlow (a great tool for measuring ways to improve the performance of your site) and he wrote the book on improving page performance: High Performance Web Sites. Now he works for Google but much of what he's up to is the same: Making web pages load faster.

I've been really excited about one of his recent project releases: UA Profiler. The profiler is a tool that you can run in your browser to determine the status of a number of network-performance-specific features that tie heavily to browser page load performance.

Here's a look at the current breakdown:

We can see Firefox 3.1 taking a lead, fixing 9 out of 11 of the issues tested for. Firefox 3, Chrome, and Safari 4 all come after with 8 fixed. Firefox 2, Safari 3.1, and IE 8 next at 7. Those numbers help to give you an overall feel of the page load performance that you'll see in a browser. (Naturally these tests don't take any rendering or JavaScript performance numbers into account but network performance generally trumps their total runtime anyway.)

Information about network performance is important for two reasons:

1. It informs browser vendors as to the quality of their browser. A browser fixing any of the points specified by the test will yield faster page loads.
2. It informs web site developers as to the problems they should be taking into consideration when developing a site. For example if a browser they support doesn't handle simultaneous stylesheet downloading perhaps their page should be re-worked.

The tests themselves can be broken down into a couple categories (Steve explains them all, in detail in the FAQ):

Network Connections

Two big things are tested here: The number of simultaneous connections that can be opened to a hostname (sub-domains count as different hostnames) and how many connections can be opened to any number of hostnames, simultaneously. These numbers can give you a good indicator of how many parallel downloads can occur (most commonly seen for downloading multiple images, simultaneously).

Additionally there is a check to see if the browser supports Gzip compression. The results aren't too exciting here as all modern browsers support Gzip compression at this point.

Parallel Downloads

All browsers are capable of downloading images in parallel (multiple images downloading simultaneously) but what about other resources (like scripts or stylesheets)?

Unfortunately it's much harder to get scripts and stylesheets to load in parallel since their contents may dramatically change the rest of the page. The loading of these resources occur in three steps:

1. Downloading (can be parallelized)
2. Parsing
3. Execution

The load order breaks down like so (sort of an advanced game of rock-paper-scissors): Scripts prevent other scripts from parsing and executing, stylesheets prevent scripts from parsing and executing.

It's been hard for browsers to implement the parallelization of script downloading since scripts are capable of changing the contents of the page - and possibly removing adding new scripts or stylesheets to the page. Because of this browsers are starting to get better at opportunistically looking ahead in the document and pre-loading stylesheets and scripts - even if their actual use may be delayed.

Changes in this area will yield some of the largest benefits to browser page load performance, going forward, as it's still one of the most untapped areas of improvement.

Caching

While all modern browsers support caching of resources, caching of page redirects is much less common. For example, consider the case where a user types in "http://google.com/" - Google redirects the user to "http://www.google.com/" but only a couple browsers cache that redirect as to not retry it later.

A similar case of redirect caching occurs for resources, for example with stylesheets, images, or scripts. Since these occur much more frequently it becomes that much more important for browsers to cache every action that they can.

Prefetching

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:

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.

Going forward it will become increasingly important to have publicly-visible tests like the UA Profiler that are able to encourage browser vendors to act quicker at implementing critical browser functionality. Anything that's able to, even indirectly, improve the performance of the browsing experience for users of the web is absolutely critical, in my book.

Tags: browser, performance, network

18 Comments on 'Browser Page Load Performance'

Color Profiles in Firefox 3

April 29th, 2008

Deb Richardson wrote up an interesting piece today describing color profile support in Firefox 3. The result of a color profile is a more-accurate mapping from an original set of colors to better match the intended rendering. Profiles can be provided by the operating system (to provide better color distribution globally) or even locally by individual images.

For example, observe the following image which compares the difference between Firefox 2, Firefox 3 (with color profile support), and an image in Adobe Photoshop:

There is a noticeable difference between the rendering of the image in Firefox 2 compared to both Photoshop and Firefox 3 (in which they are rendered identically). All of this is due to the fact that Firefox 3 and Photoshop use the additional color profile information to get a better mapping of the resulting colors.

There's one tricky point, however: Color profile support is disabled, by default, in Firefox 3. However, it can be quickly enabled by installing the Color Management Add-on or by twiddling some options in about:config.

The reasoning for the feature being disabled was outlined for two particular issues:

1. There was a large 10-15% drop in performance when this feature was enabled. The extra time spent on large images began to add up quite quickly. Obviously this will be a point that'll be worked on in upcoming releases - but introducing a regression that large was pretty much unacceptable.
2. Plugins (such as Flash, Silverlight, Quicktime, etc.) did not do color profile correction, causing rough mis-renderings to occur. This correction is, unfortunately, left up to the plugins themselves - leaving this out of the realm of the browser itself. It's unclear as to how this will be resolved.

At the very least, however, you can grab the Color Management Add-on with your copy of Firefox 3 and begin to view your pictures with an extra level of color and crispness.

Tags: firefox, colors, mozilla, browser

20 Comments on 'Color Profiles in Firefox 3'

Firefox Personas

April 4th, 2008

The Mozilla Labs team has been busy working on some new extensions to enhance user experience while testing out new concepts. One extension that recently got a major update was Personas.

The premise behind the extension is that it's currently too difficult to trivially theme and customize your Firefox experience. To counter this Personas makes the experience fantastically simple. For example, the following can be achieved using only a single image (which is seamlessly chopped up and positioned by Personas):

Now what I find to be especially interesting about this extension is the recent introduction of dynamic content into the rendering area. Instead of requiring the use of an image you can now specify a live URL (which can contain any number of things - including images, SVG, Canvas Element, JavaScript, etc.).

Here's a quick peek at putting a live Google map behind the top toolbar area of the browser:

Users are starting to contribute their own, like this page of a live web cam watching a university in Germany.

I'm really excited by this super-tivial means of styling an application. It's like taking the best part of HTML/CSS/JS widgets and combining it with trivial user customization and community.

While the end result may, or may not, look glamorous (depending on your taste) it's undeniable that simple user customization is a quick trip to get users more excited about their experience (making the browser 'their own'). I'm definitely curious to see what will built with this tool - especially now that dynamic content is being thrown in to the mix.

Update:

I was able to get a code example from Chris Beard for developing one of these advanced Persona extensions. To quote him:

You just need to put in script or content within the header/footer blocks. Also adding support so that it will pop up a window on first run so you can prompt for settings (e.g. flickr tags to use to render a photo mosaic) as well as an options window which users will be open for each Persona from the main interface.
...
The URL gets called every 60 minutes loading into a background iframe. The iframe is then captured every minute with the resulting image transfer to the chrome as a PNG data URL. No user content is privileged.

This is especially interesting since you can seed your browser layout with personal information, as he mentioned (photos from your Flickr stream, weather for your location, etc.)

Tags: browser, firefox, mozilla

12 Comments on 'Firefox Personas'