Mainly a 'remember these for later brain' post -- but people might still get a fairly good speed improvement out of them with Xulrunner or Gecko.
updated (10-04-2008): added screenshots -- so it matches the other HOWTO's here :)
Remove the initial rendering delay
Firstly, Open Epiphany (all of these work for Firefox as well, mind you.) and type about:config into your location bar.
You should see a screen that looks like the one below:
First, Gecko (the Mozilla Backend) uses a delay when rendering any new page on-screen -- you can remove this delay by right-clicking anywhere in the main window and creating a New Integer key.
In the textbox that appears, name the new key “nglayout.initialpaint.delay” and set its value to “0″.
Disabling IPv6
Next, if you don't use it -- IPv6 can add delays to any page you view -- you can turn it off in Epiphany by toggling the "network.dns.disableIPv6" key to true.
First, find the "network.dns.disableIPv6" key in the filter, your screen should look similar to:
Right click the key and press the Toggle button -- your screen should now look like:
Disabling Prefetching
Prefetching, otherwise known as the ability to cache the next page you might want to read can actually slow your browsing down if you're on a larger network, behind a proxy or just browsing a site on a slow server -- also, SSL pages (such as those on online banking sites) are much snappier if you turn this off, although i've yet to prove why this is true, or if it's just a side-effect something else.
Anyway, to turn prefetching off -- find the "network.prefetch-next" key in the filter, your screen should look similar to:
Right click the key and press the Toggle button -- your screen should now look like:
Tuning Pipelining
Pipelining refers to the ability to use one HTTP connection to obtain multiple pieces of data -- reducing the load on the servers you are browsing and maximising the amount of data your connection can receive.
There's a LOT of discussion about pipelines and their use -- i've seen pages that tell people to increase their pipeline count from 4 to 30, 60 or even 100 -- of course, telling the server you can fit more data into one connection than you can possibly receive is annoying for server administrators ...
Why?
Imagine you've got a server that hosts something reasonably popular and you've got a client that doesn't support pipelining, one that does using the default and and one that's tuned their client to receive 100 requests at once ...
The server, that basically knows nothing about what an end-user can support when it is asked to build a new connection, so in this case it would allocate enough resources to send 105 requests at once.
Even though the average broadband (512k ADSL) connection would use 5 in about the same fashion at the receivers end.
Considering the maximum number of actual connections to a particular server is in the range of 4 and 16 and that HTTP requests remain open between your client and the server for 300 seconds (both of which we'll tune later in this article) -- requesting an excessive amount of data per request is just poor considered poor etiquette.
So, let's tune our pipelining to a value that makes sense from both an available bandwidth point of view and doesn't annoy every network administrator on the planet.
To do this, we need to make sure pipelining is turned on, then we need to set two values -- one for connections created normally and one for those created by a proxy.
First, find the "network.http.pipelining" key in the filter, your screen should look similar to:
Right click the key and press the Toggle button.
Next, repeat the process for the network.http.proxy.pipelining key.
Finally, we need to define a value -- this basically depends on the type of site you're browsing, but it is considered to be poor form to make this value more than a double digit number -- I'm using 8 on all my boxes, 12 works quite well too on my 3 megabit connection, but I personally wouldn't recommend anything higher than that -- when you're done, your screen should now look like:
Tuning Per-Server Connection Limits
Now that we've tuned the pipelined connections, we need to increase the number of connections that your browser can open to a server before needing to queue new ones -- this speeds up sites that host their static content on other servers to the dynamic content, as well as making more efficent use of prefetching too.
To do this, find the "network.http.max-persistent-connections-per-server" key in the filter, your screen should look similar to:
The defaults in Firefox 2.x (xulrunner 1.8) are 2, they have been recently increased for Firefox 3.x (xulrunner 1.9) to 6.
Personally, i've found 4 to be a reasonable number on my lower-end machines (those less than a P4 1.5ghz), I use 8 everywhere else, because it matches my pipelining use.
Increasing this number to more than 10 makes the performance of Epiphany actually reduce considerably, it makes significant delays after the fourth or so page I access at once, possibly due to the fact the maximum total number of connections that Gecko opens at once is 24 (or 32, if you're using a newer Firefox 3.x build).
Right click the key and press the Modify button. Now enter the value in seconds that you'd like to change it to -- remembering the guidelines listed above.
Your screen should now look like:
Tuning Keepalive Timeouts
HTTP Keepalives play an important role in how long upstream servers keep connections open to the one client. It's incredibly useful being able to hold a connection open for a client, but having your client tell the server to hold it for 300 seconds (5 minutes) uses valuable resources on internet servers, as well as holds valuable RAM within your browser -- Basically, on the off chance you might go back to that site within the 5 minute window.
In my experience, 60 seconds (1 minute) works just as well, as is far friendler to the internet at large.
Before anyone asks (someone over my shoulder just did) -- this is not the same thing as a website timing your session out due to inactivity (like an online shop or a bank) -- this is the lower-level server infrastructure of the interschnitzel, not the website itself.
To change the keepalives to something more friendly:
Find the "network.http.keep-alive.timeout" key in the filter, your screen should look similar to:
Right click the key and press the Modify button. Now enter the value in seconds that you'd like to change it to -- personally, I wouldn't recommend going below 30 seconds (or the pipelining improvements we made above become mooted), but 30, 60, 90 and 120 are all reasonably acceptable values.
When you're done, your screen should now look like:
At this point, you might be inclined to say -- that's fast enough -- but there's one other rendering tweak which makes Epiphany much snappier ...
Tuning Page Re-rendering Delay
These tweaks control the number of times that Gecko/Xulrunner will refresh the page as data is being retrieved. The default is off, which will make the backend re-render the page periodically as each piece of data is being retrived.
If you're not behind a caching proxy, these particular tweaks will improve the amount of time it takes to render a page that contains content coming from a number of different sources (for example, Youtube or the Australian Stock Exchange) as well as remove the hideous delay that the non-free Flash Player has when it is being embedded into a page that contains .swf content.
In order to make this work, we have to add two new entries to our configuration -- right-click anywhere in the main window and creating a New String key.
In the textbox that appears, name the new key “content.notify.ontimer” and set its value to “true″.
Repeat the process, except this time -- make a New Integer key.
In the textbox that appears, name the new key “content.notify.backoffcount” and set its value to “5″.
After pressing OK, your screen should look similar to the one below:
Skip To The End...
Don't want to hear the explainations? Just want to cut-and-paste some recommendations? If so, make sure Epiphany is completely shutdown (or the preferences file will be overwritten with the defaults after you eventually close it).
Open the .gnome2/epiphany/mozilla/epiphany/prefs.js file with your favourite text editor and add:
user_pref("content.notify.backoffcount", 5);
user_pref("content.notify.ontimer", true);
user_pref("nglayout.initialpaint.delay", 0);
user_pref("network.dns.disableIPv6", true);
user_pref("network.http.keep-alive.timeout", 60);
user_pref("network.http.max-persistent-connections-per-server", 8);
user_pref("network.http.pipelining", true);
user_pref("network.http.proxy.pipelining", true);
user_pref("network.http.pipelining.maxrequests", 8);
user_pref("network.prefetch-next", false);
Save your file and re-open your browser for a much, much speedier experience.
Other Advanced Tweaks
note: These particular tweaks should be used by a technical audience only -- they may adversely affect your browsing speed on low-end machines, Epiphany's memory usage, or cause some machines to crash, you should use caution when modifying a production system -- caveat emptor.
These two tweaks control the amount of time (in milliseconds) that it takes the backend to return control to the rendering engine after the user has moved the mouse, used the keyboard or done some other "high-latency" task that pauses the rendering engine in favour of user interaction.
They both depend on the key “content.notify.ontimer” being available and enabled, which you should already have if you have followed the rest of this guide.
user_pref("content.notify.interval", 750000);
user_pref("content.switch.threshold", 750000);
This means the browser will wait less than 1 second (0.75 seconds) to return processing to the renderer, rather than the default 1 second.
On much slower machines, you may want to move them to slightly higher than 1 second values -- which makes the backend give more processing to the user interface at the expense of rendering time. A friend with an older Pentium III on a 256k ADSL connection has better performance from:
user_pref("content.notify.interval", 1250000);
user_pref("content.switch.threshold", 1250000);
Which causes the browser to wait an extra quarter of a second for the user to stop doing anything before giving everything back to the rendering engine -- it also means they can view an extra few pages before Epiphany starts becoming sluggish.
The End...
