Firefox et Chrome ralentissent sur localhost; le correctif connu ne fonctionne pas sous Windows 7
On sait que Firefox et Chrome sont lents sur localhost quand IP6 est activé. Dans les versions précédentes de Windows, la solution la plus simple consiste à commenter cette ligne à partir du fichier hosts, comme expliqué dans la réponse à cette question .
::1 localhost
Cependant, comme indiqué dans cette question , dans Windows 7, cette ligne est déjà commentée:
# localhost name resolution is handled within DNS itself.
# 127.0.0.1 localhost
# ::1 localhost
Existe-t-il un autre moyen de désactiver la référence ::1 localhost dans Windows 7?
Il s'avère que si vous ne commentez pas la ligne 127.0.0.1 dans le fichier hosts, Chrome retourne à son URL accrocheur sur les URL localhost.
# localhost name resolution is handled within DNS itself.
127.0.0.1 localhost
Le fichier hosts est généralement à C:\WINDOWS\system32\drivers\etc\hosts. Pour le modifier dans Win7, vous devez exécuter Notepad en tant qu'administrateur.
Il s'avère que la lenteur est due à un problème IPv6 avec DNS et peut facilement être résolue en désactivant la prise en charge IPv6 dans Firefox lors des tests d'hôte local. Pour effectuer le changement, tapez
about:config
dans la barre d'adresse, localisez le
network.dns.disableIPv6
paramètre et double-cliquez dessus pour le définir sur true. Cela fait l'affaire pour le problème localhost de Firefox sur Vista et tout fonctionne à nouveau rapidement.
http://kb.mozillazine.org/Network.dns.disableIPv6 a toutes les informations dont vous avez probablement besoin - bonne chance!
Je me suis heurté à un problème étrange: un seul de mes domaines locaux est lent, alors que tous les autres ont très bien répondu. Je ne pouvais pas comprendre pourquoi et finalement mettre ::1 localhost en bas, sous mon autre ::1 something.local, et tout s'est éclairci instantanément, là où je l'avais auparavant au-dessus des autres entrées. (J'utilise OS X 10.8.3)
Mon dernier fichier hosts a fini par ressembler à ceci:
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
Je ferais ce que Tim Schneider a mentionné. Aussi mentionné par ce James ici: http://theycallmemrjames.blogspot.com/2010/09/firefox-is-really-slow-testing-sites-on.html
"Double-cliquez sur ipv4OnlyDomains et tapez localhost"
Geai
J'ai eu plusieurs entrées dans les hôtes (parce que j'utilise des serveurs virtuels). Auparavant j'avais
127.0.0.1 localhost
127.0.0.2 i.localhost
127.0.0.3 secure.localhost
Ce qui semble fonctionner mieux mais pas parfait est this :
127.0.0.1 localhost secure.localhost i.localhost
Je suggère de fermer les navigateurs, d’arrêter Apache, de le redémarrer dans l’ordre inverse lors des tests.
Jusqu'à présent, aucun des correctifs n'a très bien fonctionné pour moi. Le problème reste intermittent. ..
Cependant, j'ai remarqué quelque chose d'intéressant et je me suis dit que j'espérerais que quelqu'un d'autre puisse ajouter quelque chose.
Si vous désactivez le Wi-Fi (c.-à-d. Que vous désactivez l'alimentation Internet externe), et si vous avez par exemple Chrome, FireFox et éventuellement d'autres navigateurs ouverts en même temps, et si Chrome étouffe une page, et vous essayez à ce moment de charger également un fichier depuis un autre navigateur (de localhost). Il sera également suspendu jusqu’à ce que chrome expire enfin (ou autre) et finisse plusieurs secondes plus tard, même pour des pages simples.
Cela se produit également avec IE en bloquant et bloquant les accès d'autres navigateurs. J'ai essayé cela plusieurs fois et je suis convaincu qu'il se passe quelque chose de très drôle.
Il semble y avoir un lien entre les différents processus du navigateur. Je déteste dire cela, mais je soupçonne qu’il ya un bug dans la pile IP de Windows, aussi impossible que cela puisse paraître. L'autre possibilité est que chrome est en train d'encrasser ou de monopoliser la pile d'ip, ou de verrouiller un fichier, de sorte que d'autres ne peuvent pas l'utiliser.
Il est également intéressant de noter que si, pendant que Chrome est gelé, vous réactivez le WiFi, dès que Internet se connecte, chrome ou IE se termine, ainsi que tous les autres navigateurs également bloqués.
C'est un peu étrange si vous me demandez. Si vous travaillez avec localhost, il ne devrait y avoir AUCUNE interaction avec Internet.
J'ai essayé d'utiliser WireShark pour voir ce qui se passait, mais c'est déroutant et jusqu'à présent, je n'ai pas été en mesure de déterminer les paquets concernés.
Il se passe quelque chose de très drôle.
J'ai supprimé mon fichier .htaccess et mis un fichier httpd.conf contenant le minimum de modifications par rapport aux valeurs par défaut.
J'utilise Win7x64Pro, Apache 2.4.7.
BTW, ce n'est pas une chose php. Je suis sûr à ce sujet à ce stade.
De plus, les blocages semblent se produire sur ^ R (rechargement de page), et non sur parcourir la page, et où les autres composants de la page doivent être vérifiés pour les actuels, comme les images-objets de menu (images). Ce serait là où il y a un statut 304 (utilisez HttpFox pour les voir).
En outre, si vous rechargez rapidement la même page, les chances qu’elle fonctionne seront beaucoup plus grandes. Si vous attendez une minute, il est souvent à nouveau gags. Je soupçonne que chrome obtient des résultats d’un cashe à court terme qui masque en partie un problème plus profond.
Juste essayer le mode "Incognito" sur Chrome et "Mode privé" sur Firefox.
Je sais que cela ne devrait pas être une réponse correcte. Mais vous pouvez l'utiliser comme solution temporaire.
Comme quelqu'un d'autre l'a noté dans une réponse différente - si vous avez bitdefender, cela gâcherait joyeusement votre expérience de développement.
Il est préférable d’ouvrir la console bit defender, entrez alt-shift-control-g (qui le met en "mode de jeu") et lancez à partir de là.
en mode de jeu, Bitdefender ne vous laissera pas tomber.
Ce n'est pas une réponse directe mais j'ai eu le même problème et aucune des modifications de fichiers IPv6 ou hôtes ci-dessus n'a fonctionné pour moi. Mon projet asp.net MVC4 était vraiment lent après avoir appuyé sur F5 pour actualiser les modifications de js sur localhost. Cela se produisait sur tous les navigateurs - Chrome, FF et IE. Finalement, j'ai découvert que IIS Express 8.0 avait été installé sans que je m'en rende compte, et il s'avère que la version 8.0 est extrêmement lente pour servir des fichiers js et semble être un bogue. Si j'ai exécuté iisexpress sur la ligne de commande et appuyé sur F5, je pouvais voir que chaque fichier js prenait 4 ou 5 secondes à se charger.
J'ai fini par désinstaller IIS 8.0 et installer IIS express 7.5 et immédiatement le problème a été corrigé. Voici les étapes que j'ai suivies:
- Désinstallez IIS express 8.0
- Supprimez le dossier IISExpress (sous Windows 7, il se trouve dans Mes documents\IISExpress).
- Installez IIS express 7.5 ( Lien vers le téléchargement de IIS Express 7.5 )
IIS Express 8.0 semble être installé avec VS 2012; par conséquent, si vous aviez une nouvelle installation ou éventuellement une mise à jour du service pack, cela aurait pu mettre à niveau votre version précédente IIS précédente.
Un peu tard pour une réponse, mais j’ai essayé tout ce qui précède et c’est quand même lent pour Windows 7. Lorsque j’utilise localhost, le chargement de la page a pris environ 20 secondes.
Firefox s'est amélioré avec la réponse de @Mark Mayo mais pas tout le temps et Chrome était encore très lent.
J'ai trouvé une solution ici
En gros, j’ai ajouté les lignes suivantes au fichier httpd.conf d’Apache (car elles n’y étaient pas déjà présentes)
AcceptFilter http none
AcceptFilter https none
EnableSendfile off
EnableMMAP off
Testé à la fois Chrome et Firefox et la page se charge instantanément