Wednesday, January 26, 2005

Firefox 1.0 Speed-up Tweak!

Open Firefox ..type about:config in the address bar and press enter.

Type network.dns in the filter box at the top of the page, two results should remain.

Double click on network.dns.disableIPv6 to change its value to "True"

Restart Firefox. You should notice a speed increase, page to page.



mmChronic said...

That seems t work a treat. I can't believe they enabled ip6 support by default!

hypersloth said...
This comment has been removed by a blog administrator.
hypersloth said...

This is the fourth different way I've read to speed up firefox, and by now I'm thoroughly confused.

I noticed no change with the method I tried, and later read the comments here, and finally just changed it back... I hope it's back to the default settings, because I forget which method I used... regardless, if what the comments said was true, it speeds up some things, slows down others, could mess some things up, and that's why the defaults were set the way they were originally. Anyway, here are the other three methods

from here on metafilter: Speed up Firefoxfrom here on milkandcookies: Make Firefox Faster, and a comment saying this one is easier

Any clues?

mmChronic said...

This one is a different one to those others so is worth trying. You definitely don't need ip6 dns lookup as the interweb is still ip4.

As for whether the others work - I'm not sure. I'm sure Merg will cast some light on it for us though! ;)

Merg said...

Hm... so long as the remote server supports it correctly (or remote proxy -- which is less likely, I'd guess) pipelining should always speed stuff up...

Apache supports it properly. http/1.1 requires it if a server supports persistant connections, but that's not stopped some out there writing servers that support one but not the other, or not supporting pipelining correctly.

As a side note, I'm fairly sure the popular proxy/cache/accelerator/load-balancer, squid, does NOT support it.

Anyway, here comes the hand-wavey bit.

Pipelining is where a persistant http connection is used (ie not one per file) and the server allows the client (browser) to request multiple files in one go. So, for example, after it gets index.html, it can request several graphics files, and they're returned one after the other, sequentially.

Now, this removes the request/recieve/request/recieve bottleneck where the latency between the server recieving and answering the request is sometimes a fairly major source of slowdowns, at the slightly higher cost of more resources on the webserver -- it needs to keep the list of files to send in memory.

Another benefit is smaller files will sometimes all fit inside a single packet. Or an overall smaller number of packets. So, less load on routers, etc. and slightly less network overhead.

The higher resources, if everyone's doing it, can result in a net slowdown. And servers that don't properly support it can be a problem.

Otherwise, AFAIK, it should always be at least as fast (and realistically, in 99% of cases, much faster).

I thought this was going to be about the paint delay "speedup", since that's purely perceptual -- setting it to zero makes it appear faster since it start rendering the page immediately data is recieved rather than after it's gathered more data... but overall render time is actually longer. However, users are used to "instant rendering" in IE, so they notice when Firefox and other Gecko-based browsers doesn't do it.

I think that's it in a nutshell.

mmChronic said...

I knew you could be relied on for the techy networky bits! ;)

hypersloth said...

Nice follow-up. I hate Bush, but to use a Texan analogy, "don't fix it if it ain't broke." I'm not even going to bother, because my sh*t is fast, yo.
I especially enjoyed the hand-wavey bit.

Merg said...

You're welcome :)