Chrome verlangsamt sich gegenüber https-Websites, insbesondere internen

Wir versuchen, Google Chrome in unserem Unternehmensnetzwerk bereitzustellen, stellen jedoch fest, dass das Laden einer https-Seite (insbesondere unserer eigenen internen) im Vergleich zum IE 2-4-mal länger dauert. Hat jemand dies erlebt und eine Lösung gefunden?

Aktualisieren

Auf Vorschlag von Handyman5 habe ich einige Diagnosen in Chrome durchgeführt und festgestellt, dass die größte Zeit (über 90% auf jeder Seite) für das Abrufen statischer Dateien aus dem Cache und das Rendern der Seite aufgewendet wurde. Wenn ich jedoch SSL auf unserer Website deaktiviere, geschieht dies fast augenblicklich.

Irgendwelche Gedanken darüber, warum das so sein würde?

Chrome verfügt über ein fantastisches integriertes Diagnosetool, "about: net-internals" , mit dem Netzwerkprobleme behoben werden können. Insbesondere verfügt es über eine Registerkarte "Ereignisse", auf der Sie eine URL angeben können. Anschließend bricht Chrome den gesamten Ladevorgang Schritt für Schritt auf, einschließlich DNS-Auflösung, Cache-Treffer und AJAX-Elementanforderungen.

Überprüfen Sie, wie Chrome mit der Prüfung und dem Widerruf von Zertifikaten umgeht.

Wir hatten ein sehr ähnliches Problem in einer Einrichtung, in der ich zuvor gearbeitet habe, aber mit Firefox. Damit dies ein Problem darstellt, müssen Sie bestätigen, dass das Problem nur bei https-Seiten auftritt. Wenn nicht, macht es wenig Unterschied.

Mit Firefox (ich weiß, ich weiß, ich kann lesen, auf etwas hinweisen) hatten einige Leute Probleme, während Internet Explorer-Benutzer (wenn Sie es glauben können) dies nicht taten. Wir hatten die berüchtigte ipsCA-Autorität benutzt, weil sie für Bildungseinrichtungen frei waren, aber schließlich Firefox mit ihrer Schattigkeit verärgert und die OCSP-Überprüfung ihrer Zertifikate der Schuldige war . Es stellte sich heraus, dass der Browser aufgrund der Verarbeitung unserer SSL-Zertifikate aufgrund der Verarbeitung von Zertifikatsperrlisten verzögert wurde. Sie haben offensichtlich als die Besten von uns Ihre Chrome-Version nicht erwähnt, daher ist es schwer zu sagen, ob es sich um ein Problem handeltoder ist immer noch ein Problem. Ich würde jedoch die CRL-Konfiguration in Chrome überprüfen. Dies in Firefox zu tun, hat das Problem behoben. Überprüfen Sie auch, ob Ihre Zertifikate in gutem Zustand sind, dh wenn sie selbst signiert sind. Was es zur Nutzung verraten hat, ist, dass wir uns von der Selbstsignierung entfernt haben, weil idiotische Nutzer unserer Dienste viel gejammert haben und es kostenlos war. Wir dachten, wir würden uns Kopfschmerzen ersparen, aber wir haben es noch schlimmer gemacht.

Wir haben Google Chrome intern bereitgestellt, um eine benutzerdefinierte Anwendung (unter ASP.NET MVC) zu unterstützen, die jedoch unter normalem HTTP ausgeführt wird.

Wir hatten auch Probleme mit langsamen Seiten wegen des Caches. Es scheint, dass Chrome bei jedem Laden aller Seiten alle statischen Dateien abgerufen und nicht im Cache gespeichert hat. Am Ende haben wir unserer App einfach abgelaufene Header hinzugefügt, um den Cache zu erzwingen, und das hat funktioniert.

Sie können diesen Weg gehen (Ihre Webanwendungen ändern, um die Caching-Strategie für jeden Dateityp festzulegen) oder das Standard-Caching-Verhalten von Chrome weiter untersuchen.

Andere scheinen ähnliche Probleme zu haben (z . B. http://www.google.com/support/forum/p/Chrome/thread?tid=741fd9e03cfb7e7b&hl=de ).

Dieser Artikel kann nützlich sein, da er eine Einführung in das Chrome-Caching bietet: http://gent.ilcore.com/2011/02/chromes-10-caches.html

Ich hatte das gleiche Problem. Nachdem ich lange gesucht hatte, fand ich heraus, dass Chrome mit dem Prozessmonitor-Tool ( https://technet.microsoft.com/en-us/sysinternals/processmonitor.aspx ) auf viele Kollisionen stieß und versuchte, in% TEMP% zu schreiben. Das Löschen dieses Verzeichnisses löste das Problem für mich.

Am Ende konnte ich hier keine Antwort finden. Alle Überwachungs- und Profiltests zeigen, dass Google Chrome beim Laden sicherer statischer Inhalte aus dem lokalen Client-Cache sehr langsam ist. Keine Ahnung warum. Wir mussten alle unsere internen Benutzer zum IE wechseln lassen (was die meisten Leute mit ähnlichen Problemen im Web taten).

Wenn das Backend ein Java-basierter Appserver ist, gibt es einen häufigen Java-Fehler, der dazu führt, dass TLS-Sitzungstickets eine große Verzögerung verursachen. Sie können den Fehler simulieren, indem Sie einen wirklich neuen openssl s_client verwenden und ihn anweisen, Sitzungstickets zu aktivieren / deaktivieren.

Der eigentliche Schuldige sind JSSE vs. TLS-Erweiterungen mit Nullwerten, die Sitzungstickets bei der ersten Anforderung verwenden.

Jede Möglichkeit, dass Ihrem Server die zufälligen Daten ausgehen. Wenn Sie unter Linux /dev/randomzufällige Daten verwenden und keine zufälligen Daten mehr haben, wird Ihr Server blockiert und das Laden der Seite sieht so aus, als ob es hängen bleibt.

Ist normalerweise /dev/urandomgut genug. Wenn dies nicht der Fall ist, können Sie Hardware erwerben, die zufällige Daten für Sie generiert.

Ich sehe, dass Sie ASP .NET ausführen. Ich kann nicht kommentieren, ob dies ein Problem unter Windows ist, aber einen Blick wert.