Other Browser Performance Improvements

Other improvements enhance Firefox's performance. These improvements include more than just improving rendering or communication. Rather they might make a combination of changes to Firefox's configuration

Rendering and Rasterization

What is rendering and rasterization?

Rendering is the process of creating an image from graphical objects such as polygons, textures, lines, and so on. Generally, rendering is performed by the application program and not the operating system.

Rasterization is the process of taking the rendered image and placing it into a display device. This process is done by the operating system (and sometimes hardware as well) and not by the application program.

You can do little to improve rasterization perhaps installing higher performance graphics hardware, improved and faster CPUs, or even an operating system that has a faster rasterization engine.

With rendering, you have much more control over performance. Rendering is a complex process that is far more complicated than many of us realize. For example, an optimization is made to avoid rendering objects that are not visible. This might be an object that is obscured or covered by another object that is higher in the Z order. (The Z order is the ordering of layers on an image; what is topmost is always visible and layers below the topmost layer are usually at least partially obscured by higher layers.)

No rendering engine is perfect. Some software is better than others, however. With Firefox, the goal is to improve the rendering as much as possible without trying to rewrite the program's rendering engine. (The author has written rendering engines for GIS applications, and can assure you that it is not a trivial process!)

Rendering and rasterization together are often referred to as painting.

Firefox waits for about a quarter of a second (250 milliseconds) before it attempts to render a document if the document has not been fully received. (A document is always rendered as soon as it is fully received, even if this time is less than a quarter second.)

It is possible to tell Firefox to start painting the page as soon as enough information has been received to allow painting to start. By default this is on, with that delay of a quarter second. Setting the time value to a lower value (or zero) shortens the wait before painting:

// Last value in milliseconds (default is 250) user_pref("nglayout.initialpaint.delay", 0); 

When pages are painted, there are cases where the page must be reflowed, or adjusted, to allow content received after painting has begun to fit properly on the document. This reflowing is controlled by a preference:

// ontimer is boolean, either true (1) or false (0) user pref("content.notify.ontimer", 1); 

The default value for this preference is true (1), and this value will probably provide the best performance. However, for some documents adjusting this to false (0) might help speed the painting process.

The time steps for reflows are defined by the content.notify.interval preference. There will only be a limited number of reflows before Firefox simply waits for the content to be received without doing a reflow.

// Interval is in microseconds (millionth's of a second) user pref("content.notify.interval", 120000); 

Recommended values are between 100,000 and 500,000 (one-tenth to one-half second). Some examples set this to a very low value; however, values below 100,000 typically hinder performance, not enhance it!

Firefox tries to reflow the document a certain number of times, and then simply stops and waits until the document's content has been received. If this preference is set to -1, a reflow never happens. Typical values are between 5 and 20, and vary with both the speed of your Internet connection and your computer's speed.

// Number of reflows before waiting for complete document: user pref("content.notify.backoffcount", 10); 

The backoffcount preference can be set by trial and error. If you change computers or connections, you will need to retune this value, however.