Last Updated: 17-September-1998

This document enumerates some of the performance enhancements that we've been batting around internally at Netscape. It is by no means exhaustive, and other suggestions are heartily encouraged. In the cases where someone is actively working on one of these ideas, contact information is noted. We'd like to do all of them (or, understand why we shouldn't -- some may not be good ideas after all), so if you want to get involved, pick something with and hack away! Eventually, I hope that we'll be able to set up links to more detailed content for each of these projects as work evolves.

A bureaucratic note on "contacts" and "owners". A "contact" is someone who has done some thinking about the project (and maybe even suggested it), but hasn't done anything with it or is looking to hand it off. An "owner" is someone who is actively involved in hacking code. The distinction is made to clarify what is actively being worked on, and what needs work. If a project that you are interested in already has an "owner", by all means contact the person and see what you could do to help (i.e., don't feel that it's "taken" and the owner doesn't want any help: if that were the case, it wouldn't be listed here).

There are more ideas here than we can work on. We need your help! And if you have other ideas, let us know!.

Cursor Feedback

Mozilla needs to be more rigorous about cursor feedback: the cursor should never be left as "busy" for longer than needed (e.g., at startup on blank screen). Ensuring that the correct cursor type is shown provides solid feedback with respect to what a user can and cannot do with the browser.

Contact: Don Melton (don@netscape.com).

DNS Caching

We want to investigate the effects of caching DNS information in the browser. Specifically, Mozilla will maintain a DNS cache and apply it for frequently visited sites, which will remove the overhead of repeated DNS lookups. An even more aggresive implementation might lookahead and prefetch the DNS information for links on the current page. The DNS cache will be refreshed using a suitable algorithm automatically, or may be forced to refresh by the user.

Owners: Judson Valeski (valeski@netscape.com), Gagan Saksena (gagan@netscape.com).

Enhanced Network Cache Algorithm & Implementation

Evaluate and implement a better algorithm for cache replacement (the current feeling is the LRU really isn't appropriate). This will require some detailed analysis, and may be affected by the characteristics of the content that a user tends to browse.

Other cache-related tasks include modularization (using the XPCOM infrastructure), and implementing a shared cache that can identify equivalences across multiple URLs that use the same data.

Owner: Gagan Saksena (gagan@netscape.com).

FTP Resume Feedback

One of Mozilla's "stealth features" is the ability to dynamically detect and resume a failed FTP transfer. Unfortunatly, most users think that FTP is buggy because "it couldn't have downloaded that 8Mb file that fast!": a typical case of poor user interface. It would sure be great to make an end-user aware that a partially successful transfer had been detected, and could be resumed. This might involve adding some "browser internals" information to the Aurora UI for FTP downloads that are currently in progress, adding a better "Save As..." dialog that would give the user an appropriate prompt if it detected that a download could be resumed, and so on.

Contact: Hubie Shaw (hshaw@netscape.com).

HTTP Bundling

On request from client, the server could bundle together all of the elements of a page (images, JavaScript, etc.) into a "bundle", and send the bundle to the client in one big transfer. The client would then unbundle the contents and display them. This concept is similar to that of Java JAR files. Because Mozilla supports incremental rendering, it would be important to order the contents of the "bundle" so that elements that are to be displayed first (e.g., the .html document file) appear early on in the transfer.

Contact: John Giannandrea (jg@netscape.com).

HTTP Compression

A web server can compress the content that it sends across the net to a client; in turn, a client decompresses the content before displaying it. Even though most image formats use some kind of compression already, HTTP compression could dramatically decrease the amount of data transferred over the wire, particularly for "vanilla" HTML and JavaScript scripts.

Owner: John Giannandrea (jg@netscape.com).

Keep Alive

The client could attempt to maintain an open TCP connection with a server in anticipation of re-using that connection for subsequent transfers. This would cut out the overhead associated with establishing a new socket. Although Mozilla currently does re-use connections within the current page, it does not attempt to maintain open connections across pages.

Contact: Judson Valeski (valeski@netscape.com).

Layout Enhancements

Table layout. The browser should maintain a persistent model of the content: this would be used to implement dynamic reflow, as well as facilitate general text and table layout performance improvements.

Parse tree cache. Cache the persistent model of a page along with the content cache, and use this when displaying the page from the cache. This would achieve "reflow-level" performance when page is displayed from cache.

Owners: Chris Toshok (toshok@netscape.com), Nisheeth Ranjan (nisheeth_mozilla@yahoo.com).

Low-bandwidth Protocol Analysis

We're looking at how well HTTP runs over a slow link. To do this, we're ripping apart HTTP at the TCP packet level, and examining what actually goes over the wire. We'll determine the effect of OS-level TCP parameters on overall performance. We hope to evaluate the impact of HTTP/1.1 features like compression and pipelining.

Owners: Hubie Shaw (hshaw@netscape.com), Chris Waterson (waterson@netscape.com).

Runtime Performance Tracing

By instrumenting netlib and other modules to gather timing statistics, we

• Determine what network-related operations are taking the most time (e.g., DNS lookup, TCP connect).
• Determine the relative frequency of content that kills Mozilla's performance (e.g., Mozilla blocks on IMG tags without size information; we could fix this, but how often does it really happen?).
• Enable the mozilla.org community at large (not just those of us with profilers) to begin attacking performance problems in the codebase.

Owner: Chris Waterson (waterson@netscape.com).

Page Progress Feedback

Often, there is no clear indication of what is currently being downloaded as a web page loads. We're all familiar with the "spastic progress meter" that jumps from 5% to 90%, and then back to 20%! Although this might give an end user some feeling that "a lot is going on", it would probably be best to be able to clearly set their expectations about the progress of a page load. Similarly, during a SUBMIT post (e.g., to a CGI), there is almost no feedback to the user with respect to what is going on.

Contact: Chris Waterson (waterson@netscape.com).

Prefetch

It would be interesting to see if it is possible to efficiently prefetch pages that a user might view via links from the current page. Prefetching could be either content directed (i.e., via extension to HTML) or heuristically based.

Content based prefetch could work by allowing an author to specify a <LINK> tag in the document header with the SRC attribute specifying the URL to be prefetched:

<HEAD>
<LINK REL="prefetch" HREF="prefetchUrl">
...
</HEAD>

Alternatively, a hypertext link in the document could trigger prefetch by having the PRE attribute:

<A HREF="prefetchURL" PRE>This url would be prefetched</A>

Heuristically based prefetch might work by traversing the document from top to bottom, and fetching content as it encounters links. Alternatively, the browser might simply prefetch ("refresh") the documents that are in the user's history at startup, under the assumption that the user is likely to visit those pages again.

Owner: Gagan Saksena (gagan@netscape.com).

Profiling

Although not really a project in and of itself, it would be nice to have somebody as a "lead" for the profiling effort. This person would evaluate profiling tools, collect and publish tips for using the tools, maintain the current list of "hot spots" that need to be dealt with, and gather new test cases that illustrate performance problems.

Owners: Hubie Shaw (hshaw@netscape.com), Chris Waterson (waterson@netscape.com).

Proxy Autodetect

Even at small ISPs, proxy servers can achieve cache hit rates of up to 30%! This can lead to a much "smoother" web experience, and makes the browser a much more efficient user of network resources. On startup, Mozilla should attempt to determine if a proxy server is available automatically, and if it finds one, use it.

Contact: Judson Valeski (valeski@netscape.com).

Smarter Image Caching

Currently, an when an image is tossed from the cache, information about its dimensions (width and height) is discarded as well. There are two problems with this: first, large images tend to be flushed from the cache quickly due to the large amount of space they require on disk; and second, large images (in fact, any image) tends to force a document reflow when the image size is unknown. By keeping the image dimensions cached separate from the image contents, it may be possible to avoid reflow. (Currently, content providers are encouraged to specify image dimensions in the <IMG> tag, so it would be interesting to see what percentage of images on the web actually have unspecified dimensions before charging off and doing this optimization.)

Contact: Gagan Saksena (gagan@netscape.com).

Tune On Install

On installation, parameters such as disk cache size, memory cache size etc. could be tuned for optimal performance based on the user's OS, available memory, free hard disk space, and so on.

Contact: Chris Waterson (waterson@netscape.com)