Firefox and Chrome slow on localhost; known fix doesn't work on Windows 7

Turns out if you uncomment the 127.0.0.1 line in the hosts file, Chrome goes back to its snappy self on localhost URLs.

# localhost name resolution is handled within DNS itself.
    127.0.0.1 localhost

The hosts file is typically at C:\WINDOWS\system32\drivers\etc\hosts. To edit it in Win7, you'll need to run Notepad as administrator.

It turns out that the slowness is caused by an IPv6 issue with DNS and can easily be resolved by turning IPv6 support off in Firefox while doing localhost testing. To make the change, type

about:config 

in the address bar, locate the

network.dns.disableIPv6

setting and double-click on it to set it to true. This does the trick for the Firefox localhost issue on Vista and everything is running fast again.

http://kb.mozillazine.org/Network.dns.disableIPv6 has all the info you probably need - good luck!

I ran into a strange issue with only one of my local domains being slow while all the others responded just fine. Couldn't figure out why and finally put ::1 localhost at the bottom underneath my other ::1 something.local and it instantly cleared up, where previously I had it above the other entries. (I'm running OS X 10.8.3)

My final hosts file wound up looking something like this:

127.0.0.1 localhost
255.255.255.255 broadcasthost
::1 something.local
::1 something2.local
::1 something3.local
::1 localhost
fe80::1%lo0 localhost

I'd do what Tim Schneider mentioned. Also mentioned by this James here: http://theycallmemrjames.blogspot.com/2010/09/firefox-is-really-slow-testing-sites-on.html

"Double-click on ipv4OnlyDomains, and type localhost "

Jay

I had several entries in hosts (because I'm running virtual servers). Previously I had

127.0.0.1        localhost
127.0.0.2      i.localhost
127.0.0.3 secure.localhost

What seems to work better but not perfect is this:

127.0.0.1 localhost secure.localhost i.localhost

I suggest closing browsers, shutting down Apache, the restarting in reverse order when testing.

So far none of the fixes have worked very well for me. The problem remains intermittent. ..

However I noticed something interesting and figured I'd share in hopes that someone else can add to this.

If you shut off WiFi (i.e. turn the external internet feed off), and if you have for example, Chrome, FireFox and possibly other browsers open at the same time, and if Chrome chokes on a page, and you get the spinning pin wheel, and you try at that moment to also load a file from another browser, (from localhost) it will also hang until chrome finally times out (or whatever) and finally finishes many seconds later, even for simple pages.

This also happens with IE choking and blocking accesses from other browsers. I've tried this many times and I'm convinced there is something very funny going on.

There seems to be a link between the different browser processes. I hate to say this but I suspect there is a bug in the windows IP stack, as impossible as that sounds. The other possibility is that chrome is just bogging down or hogging the ip stack, or locking some file, so that others can't use it.

Also very interesting to note, is that if while chrome is frozen up, you re-enable WiFi, just as soon as the internet connects then chrome or IE finishes, along with whatever other browsers are also blocked.

That's sort of strange if you ask me. If you are working off of localhost there should be NO interaction with the internet.

I've tried to use WireShark to see what's going on, but it's confusing and so far I have not been able to nail down any packets involved.

There is something very funny going on.

I've deleted my .htaccess, and put an httpd.conf in which has the very minimum changes from the defaults.

I'm running Win7x64Pro, Apache 2.4.7.

BTW, it's not a php thing. Am sure about that at this point.

Also the lock ups seem to happen on ^R (page reload), not on browse to page, and where other page components need to be checked for current, like menu sprites (images). This would be where there is a 304 status (use HttpFox to see these).

Also, if you quickly reload the same page the chance that it will work is much higher. If you wait for a minute then it often gags again. I suspect chrome is getting results out of a short term cashe which is partly masking a deeper issue.