The goal of the Mozilla Performance Project is to improve the overall performance of the Mozilla browser, especially for users that are connected to the Internet via a slow, high-latency connection like a 28.8kbps modem. Most people (present company included!) currently find that surfing the Internet can be a painfully slow experience. In fact, in at least one survey, poor performance over dialup has been cited as the number one complaint that people have with the web!

Although there is definitely a positive correlation between connection speed and browser performance, the modem isn't the only contributor to the overall perception of slowness. Sure, your modem brings low bandwidth and high latency to the party, but that's only part of the puzzle. As much as we hate to admit it, there are plenty of places where a pile of inefficient code is lurking deep in the bowels of the browser. Furthermore, there may be many cases where the browser could make a slow operation "seem" faster by providing more feedback or a better user interface. This leads to the three areas that we're hoping to focus on for Mozilla:

Raw network performance, which involves tweaking protocols to get the most out of the modem (or any network connection, for that matter). This will involve groveling through TCP traces to optimize Mozilla's usage of the protocol, tuning OS-specific parameters to identify the optimal setting for Mozilla, analyzing the potential impact of HTTP/1.1 features, and so on. A secondary (but equally important) task will be to ensure that the browser maintains a small "network footprint", and doesn't use more that its fair share of server and network resources.

Raw program performance, which involves detailed profiling to find and remove "hotspots" in the code. A good entry point here will be "that site that just always comes up too slowly", whether you're at home on a modem or at work through a T1. This work will involve getting down and dirty with some profiling tools, suggesting algorithms (and of course, hacking up their implementation) to get stuff running as fast as possible.

Perceived program performance, which is the catch-all for any trick, hack, or gizmo that makes Mozilla seem faster. This could be something as simple as improving the feedback that Mozilla gives to the user during a slow network operation, or something as fancy as hacking the order in which images get fetched and displayed. Unlike network throughput and profiling, this is very qualitative, "touchy feely" kind of area with a lot of potential for creativity.

How can I get involved? Simple. Pick something that's slow and make it run fast fast fast! For starters, take a look at some of the project ideas that we've come up with internally. For the projects that are underway, pick apart our algorithms and methodology, and tell us how we could be doing things better. Or suggest your own performance project: I'll add it to the growing list of uncooked ideas that people have sent in. If you'd like to get involved with mozilla.org, working on Mozilla's performance is a great way to start: most of the projects can start small, and it's easy to measure the impact of your individual contributions.

How does this relate to the new layout engine? The new layout engine, sometimes referred to as NGLayout, is a ground-up rewrite of the layout code, and it incorporates a ton of fancy algorithms to make presentation faster. Unfortunately, NGLayout isn't going to be integrated into Mozilla for a while: the first "official" release of Mozilla will probably go out with the current layout engine. Although there definitely is some overlap in the layout work that we're doing to improve the initial release of Mozilla (e.g., continuous reflow and some of the caching enhancements), we hope that much of the other work will flow naturally into performance benefits for NGLayout.