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

Firefox and Chrome are known to be slow on localhost when IP6 is enabled. In previous versions of Windows, the simplest fix is to comment out this line from the hosts file, as explained in the answer to this question.

::1 localhost

However, as noted in this question, in Windows 7 this line is already commented out:

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

Is there an alternative way to disable the ::1 localhost reference in 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][1] has all the info you probably need - good luck!

[1]: http://kb.mozillazine.org/Network.dns.disableIPv6 "http://kb.mozillazine.org/Network.dns.disableIPv6"

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.

A bit late for an answer but i tried all of the above and still it was slow for me on Windows 7. When I use localhost it took about 20+ secs for page load.

Firefox improved with @Mark Mayo's answer but not all the time and Chrome was still very slow.

I found a solution here

Basically, i added the following lines to Apache httpd.conf file (as they weren't there already)

AcceptFilter http none 
AcceptFilter https none 
EnableSendfile off 
EnableMMAP off

Tested both Chrome and Firefox and the page loads instantly

As someone else noted in a different answer - if you have bitdefender, then that will merrily ruin your development experience.

Best to open the bit defender console, enter alt-shift-control-g (which puts it in "game mode") and run from there.

in game mode, bitdefender won't bollocks up your localhost!

This isn't a direct answer but I had the same problem and none of the above IPv6 or hosts file changes worked for me. My asp.net MVC4 project was really slow after hitting F5 to refresh js changes on localhost. It was happening across all browsers - Chrome, FF, and IE. Eventually I found out that IIS Express 8.0 got installed without me realising, and it turns out 8.0 is extremely slow when serving up js files and seems to be a bug. If I ran iisexpress on the command line and hit F5 I could see each js file took 4 or 5 seconds to load.

I ended up uninstalling IIS 8.0 and installing IIS express 7.5 and straight away the problem was fixed. Here are the steps I followed:

• Uninstall IIS express 8.0
• Delete the IISExpress folder (on Win 7 it's in My Documents\IISExpress)
• Install IIS express 7.5 (Link to IIS Express 7.5 download)

IIS Express 8.0 seems to be installed with VS 2012 so if you had a new install or possibly a service pack update this might have upgraded your previous IIS express version.

Just Try "Incognito" mode on Chrome and "Private Mode" on Firefox.

I know this not should be a correct answer. But you can use this as a temporary solution.