Chrome ralentit sur les sites https, en particulier les sites internes

Nous essayons de déployer Google Chrome sur notre réseau d'entreprise, mais nous constatons qu'il faut 2 à 4 fois plus de temps pour charger une page https (en particulier nos propres pages internes) par rapport à IE. Quelqu'un a-t-il vécu cela et trouvé un correctif?

Mise à jour

Sur la base de la suggestion de Handyman5, j'ai exécuté des diagnostics dans Chrome et constaté que le plus grand temps (plus de 90% sur chaque page) était consacré à l'extraction de fichiers statiques du cache et au rendu de la page. Cependant, si je désactive SSL sur notre site, cela est presque instantané.

Avez-vous des raisons de penser que ce serait le cas?

Chrome dispose d'un formidable outil de diagnostic intégré, "about: net-internals" , conçu pour aider à résoudre les problèmes de réseau. En particulier, il possède un onglet "Événements" qui vous permet de spécifier une URL, puis Chrome décompose le processus complet de son chargement, étape par étape, y compris la résolution DNS, les accès au cache et les demandes d'éléments AJAX.

tl; dr Vérifiez comment Chrome gère la vérification et la révocation des certificats.

Nous avons eu un problème très similaire dans une installation où je travaillais auparavant, mais avec Firefox. Pour que cela soit un problème, vous devez confirmer que le problème concerne uniquement les pages https. Sinon, cela fera peu de différence.

Avec Firefox (je sais, je sais, je peux lire, point à venir), un tas de gens ont eu des problèmes, contrairement aux utilisateurs d'Internet Explorer (si vous pouvez le croire). Nous avions utilisé la tristement célèbre autorité ipsCA parce qu'ils étaient gratuits pour les établissements d'enseignement, mais nous avons finalement énervé Firefox avec leur obscurité et la vérification OCSP de leurs certificats était le coupable . Il s'avère que le navigateur tardait à cause du traitement des listes de révocation de certificats en raison de la nature de nos certificats SSL. Évidemment, en tant que meilleur d'entre nous, vous n'avez pas mentionné votre version de Chrome, donc il est difficile de dire si c'était un problèmeou est toujours un problème. Cependant, je vérifierais la configuration CRL dans Chrome. Le faire dans Firefox a atténué le problème. Vérifiez également que vos certificats sont en règle, c'est-à-dire s'ils sont auto-signés. Ce qui l'a donné à utiliser, c'est que nous nous sommes éloignés de l'auto-signature parce que les utilisateurs idiots de nos services pleurnichaient beaucoup et c'était gratuit. Nous pensions que nous nous épargnions un mal de tête, mais nous avons aggravé la situation.

Nous avons déployé Google Chrome en interne, pour prendre en charge une application développée sur mesure (sur ASP.NET MVC) mais fonctionnant sur HTTP normal.

Nous avons également eu des problèmes avec les pages lentes à cause du cache. Il semble que Chrome tirait tous les fichiers statiques à chaque chargement de page et ne les enregistrait pas dans son cache. Nous avons fini par simplement ajouter des en-têtes expirés à notre application pour forcer le cache, et cela a fonctionné.

Vous pouvez emprunter cette voie (modifier vos applications Web pour spécifier la stratégie de mise en cache pour chaque type de fichier) ou étudier plus en détail le comportement de mise en cache par défaut de Chrome.

D'autres semblent avoir des problèmes similaires (par exemple http://www.google.com/support/forum/p/Chrome/thread?tid=741fd9e03cfb7e7b&hl=en ).

Cet article peut être utile car il fournit une introduction à la mise en cache de Chrome: http://gent.ilcore.com/2011/02/chromes-10-caches.html

Je rencontrais le même problème. Après une longue recherche, j'ai découvert avec l'outil de surveillance des processus ( https://technet.microsoft.com/en-us/sysinternals/processmonitor.aspx ) Chrome rencontrait de nombreuses collisions essayant d'écrire dans% TEMP%. L'effacement de ce répertoire a résolu le problème pour moi.

En fin de compte, je n'ai pas pu trouver de réponse ici. Tous les tests de surveillance et de profilage montrent que Google Chrome est très lent à charger du contenu statique sécurisé à partir du cache client local. Je ne sais pas pourquoi. Nous avons dû faire basculer tous nos utilisateurs internes sur IE (ce que la plupart des gens ayant des problèmes similaires sur le Web ont fait).

Si le serveur principal est un serveur d'applications basé sur java, il existe un bogue java courant qui provoque des tickets de session TLS entraînant un énorme retard. Vous pouvez simuler le bogue en utilisant un tout nouveau openssl s_client et en lui disant d'activer / désactiver les tickets de session.

Le véritable coupable est les extensions JSSE vs TLS avec des valeurs nulles, que les tickets de session utilisent lors de la première requête.

Toute possibilité que votre serveur manque de données aléatoires. Sous Linux, si vous utilisez /dev/randomet manquez de données aléatoires, votre serveur se bloquera et le chargement de la page aura l'air de se bloquer.

/dev/urandomEst généralement assez bon. Si ce n'est pas le cas, vous pouvez obtenir du matériel qui générera des données aléatoires pour vous.

Je vois que vous exécutez ASP .NET - Je ne peux pas dire si c'est un problème sous Windows, mais ça vaut le coup d'œil.