Chromeはhttpsサイト、特に内部サイトより遅い

私たちは企業ネットワーク全体にGoogle Chromeを導入しようとしていますが、IEと比較してhttpsページ（特に私たちの内部ページ）のロードに2〜4倍の時間がかかることがわかりました。誰かがこれを経験して修正を見つけましたか？

更新

Handyman5の提案に基づいて、Chromeで診断を実行したところ、キャッシュからの静的ファイルのプルとページのレンダリングに最も長い時間（各ページで90％以上）が費やされていることがわかりました。しかし、私たちのサイトでSSLをオフにすると、これはほぼ瞬時に起こります。

これがなぜなのかについての考えはありますか？

Chromeには、ネットワークの問題のトラブルシューティングに役立つように設計された「about：net-internals」というすばらしい組み込み診断ツールがあります。特に、URLを指定できる[イベント]タブがあり、ChromeはDNS解決、キャッシュヒット、AJAX要素リクエストなど、URLの読み込みプロセス全体を段階的に分析します。

tl; dr Chromeによる証明書の確認と取り消しの処理方法を確認します。

以前働いていた施設でも、Firefoxで非常によく似た問題がありました。これが問題になるには、問題がhttpsページでのみ発生することを確認する必要があります。 そうでない場合、それはほとんど違いがありません。

Firefox（私が知っている、私が知っている、私は読むことができる、近日公開予定）を使用すると、多くの人々が問題を抱えていましたが、Internet Explorerユーザー（信じられれば）は問題を抱えていませんでした。私たちは悪名高いipsCA機関を教育機関に無料で提供していたので使用していましたが、最終的にFirefoxを怒らせ、証明書のOCSPチェックが原因でした。SSL証明書の性質上、証明書失効リストの処理が原因でブラウザが遅延していることがわかりました。あなたは明らかに、私たちの最高の人として、Chromeのバージョンについて言及しなかったので、それが問題であったかどうかを言うのは難しいまたはまだ問題です。ただし、ChromeでCRL構成を確認します。Firefoxでそうすることで問題が緩和されました。また、証明書が良好な状態にあること、つまり自己署名されていることを確認してください。私たちのサービスのばかげたユーザーが何度も馬鹿にして無料だったので、それを使用することを許したのは、私たちが自己署名から離れたということです。私たちは頭痛の種を救っていると思っていましたが、さらに悪化しました。

カスタム開発されたアプリケーション（ASP.NET MVC上）をサポートするために内部でGoogle Chromeをデプロイしましたが、通常のHTTPで実行しました。

キャッシュが原因でページが遅いという問題もありました。Chromeは、ページが読み込まれるたびにすべての静的ファイルを取得しており、キャッシュに保存していないようです。キャッシュを強制的にオンにするために、アプリに期限切れヘッダーを追加するだけで終了し、それが機能しました。

その経路をたどるか（ファイルの種類ごとにキャッシュ戦略を指定するようにWebアプリケーションを変更する）、またはChromeのデフォルトのキャッシュ動作をさらに調査することができます。

他にも同様の問題があるようです（例：http : //www.google.com/support/forum/p/Chrome/thread?tid=741fd9e03cfb7e7b&hl=en）。

この記事は、Chromeキャッシングの入門書として役立つので役立つ場合があります。http：//gent.ilcore.com/2011/02/chromes-10-caches.html

私は同じ問題に遭遇していました。プロセスモニターツール（https://technet.microsoft.com/en-us/sysinternals/processmonitor.aspx）で長い間調べたところ、Chromeは％TEMP％に書き込もうとする多くの衝突に遭遇していました。このディレクトリをクリアすると、問題が解決しました。

結局、ここで答えを見つけることができませんでした。すべての監視およびプロファイリングテストは、Google Chromeがローカルクライアントキャッシュから安全な静的コンテンツをロードするのが非常に遅いことを示しています。なぜだかわかりません。すべての内部ユーザーをIEに切り替える必要がありました（これは、Webで同様の問題を抱えているほとんどの人が行ったものです）。

バックエンドがJavaベースのappserverである場合、TLSセッションチケットに大きな遅延を引き起こす一般的なJavaバグがあります。本当に新しいopenssl s_clientを使用してセッションチケットを有効/無効にするように指示することで、バグをシミュレートできます。

本当の原因は、セッションチケットが最初のリクエストで使用するnull値のJSSE対TLS拡張です。

サーバーでランダムデータが不足する可能性。Linuxでは/dev/random、ランダムデータを使用して実行すると、サーバーがブロックし、ページの読み込みがハングしたように見えます。

通常/dev/urandomは十分です。そうでない場合は、ランダムなデータを生成するハードウェアがいくつかあります。

ASP .NETを実行しているようです-Windowsの問題であるかどうかはコメントできませんが、一見の価値は十分あります。