Loading webpages faster in Mozilla Firefox | Hacking Firefox Speed

We can speed up the loading of webpages in Firefox with the help of simple hacks. This method of optimization of speed is also called 'page rendering'.

Page rendering is handled by the internal core technology, called NGLayout, or by Mozilla’s layout engine. By tweaking the NGLayout paint delay setting, you reduce the amount of time that the browser waits before it begins rendering a page while downloading, which achieves some marvelous visual performance. I like this a lot because it enables me to know exactly what is downloading and to enjoy its rendering in real time without having to wait for all the content to load. This does take its toll on central processing unit (CPU) utilization, but with today’s high-end processors and systems, this is less of a factor.

Using tab browsing usually requires less CPU time and memory; pages load faster because Firefox does not have to render a whole new window.

Hacking Page Rendering

Most of these hacks are scattered all over the Internet, but most take snippets from several key sources, including the Firefox Tuning information posted in the Firefox Features forum on MozillaZine.org forums.

To access the healthy discussion on tuning Firefox, visit http://forums.mozillazine.org/viewtopic.php?t=53650.

The TweakFactor.com site summarizes these hacks in a nice clean page, which can be found at

However, in my experience, the following tweaks are really the core tweaks that help in rendering and page timing for display purposes:
user_pref(“nglayout.initialpaint.delay”, 0);
user_pref(“content.notify.ontimer”, true);
user_pref(“content.interrupt.parsing”, true);
user_pref(“content.notify.interval”, 100);
user_pref(“content.notify.threshold”, 100000);
user_pref(“content.notify.backoffcount”, 200);
user_pref(“content.max.tokenizing.time”, 3000000);
user_pref(“content.maxtextrun”, 8191);
The nglayout.initialpaint.delay  tweak shown in the preceding code modifies the amount of time Firefox waits before it begins rendering a page, where the default is 250 (milliseconds). The rest of the content hacks alter the timing for internal reflow and page generation.

The “content.notify.ontimer” is on by default, but I always like to include it just in case. This turns on the timer-based reflow management used for rendering. Users upgrading from pre-1.0 releases may have this preference disabled; setting it to true should rectify this.

The “content.notify.interval” preference sets the amount of time allowed between reflows and is measured in microseconds, where the default is 250000. Some have balked at setting this to such a low number, but I have yet to suffer from doing so.

The “content.notify.backoffcount” sets the number of reflows to do before waiting for the rest of the page to arrive.

The “content.max.tokenizing.time” was implemented to give the user interface responsiveness while parsing a page. The default for this setting is three times the “content.notify.interval”. This is the amount of thread processing time to use before releasing controls to the user interface.

The “content.maxtextrun” preference by default is 8191, but in builds prior to 0.9.5, it was 8192, and the one-digit difference, based on the notes in the Bugzilla posting, made a huge difference in rendering due to buffer thrashing and over allocations. This hack is included just in case you are still on an old build or this setting has not been properly updated. For more information on this fix, visit https://bugzilla.mozilla.org/show_bug.cgi?id=77540.


The combination of these hacks should yield a very nice experience when downloading larger pages or pages with complicated table structures.

2/Post a reply/Replies

Post a Comment

Previous Post Next Post