Chrome memperlambat situs https, terutama situs internal

Kami mencoba untuk menyebarkan Google Chrome di seluruh jaringan perusahaan kami, tetapi kami menemukan bahwa dibutuhkan 2-4X lebih lama untuk memuat halaman https (terutama yang internal kami sendiri) dibandingkan dengan IE. Adakah yang mengalami ini dan menemukan perbaikan?

Memperbarui

Berdasarkan saran Handyman5, saya menjalankan beberapa diagnostik di Chrome, dan menemukan bahwa jumlah waktu terbesar (lebih dari 90% pada setiap halaman) dihabiskan untuk menarik file statis dari Cache dan merender halaman. Namun, jika saya mematikan SSL di situs kami, ini hampir seketika.

Adakah pemikiran mengapa ini terjadi?

Chrome memiliki alat diagnostik bawaan yang mengagumkan, "about: net-internal" , yang dirancang untuk membantu memecahkan masalah jaringan. Secara khusus, ia memiliki tab "Acara" yang memungkinkan Anda menentukan URL dan kemudian Chrome memecah seluruh proses memuatnya, langkah-demi-langkah, termasuk resolusi DNS, hit cache, dan permintaan elemen AJAX.

tl; dr Periksa bagaimana Chrome menangani pemeriksaan dan pencabutan sertifikat.

Kami memiliki masalah yang sangat mirip di fasilitas yang sebelumnya saya kerjakan, tetapi dengan Firefox. Agar ini menjadi masalah, Anda perlu mengonfirmasi bahwa masalahnya hanya dengan laman https. Jika tidak, itu akan membuat sedikit perbedaan.

Dengan Firefox (saya tahu, saya tahu, saya bisa membaca, menunjukkan), sekelompok orang memiliki masalah sementara pengguna Internet Explorer (jika Anda percaya) tidak melakukannya. Kami telah menggunakan otoritas ipsCA yang terkenal karena mereka bebas untuk lembaga pendidikan, tetapi akhirnya membuat Firefox kesal dengan OCAD dan memeriksa sertifikat mereka adalah biang keladinya . Ternyata peramban sedang tertunda karena memproses Daftar Pencabutan Sertifikat karena sifat dari sertifikat SSL kami. Anda jelas, sebagai yang terbaik dari kami, tidak menyebutkan versi Chrome Anda, jadi sulit untuk mengatakan apakah itu masalahatau masih menjadi masalah. Namun, saya akan memeriksa konfigurasi CRL di Chrome. Melakukan hal itu di Firefox meringankan masalah. Juga, periksa sertifikat Anda dalam performa yang baik, yaitu jika mereka ditandatangani sendiri. Apa yang memberikannya untuk digunakan adalah kami pindah dari penandatanganan diri karena pengguna layanan idiot merengek banyak dan itu gratis. Kami pikir kami menyelamatkan diri kami dari sakit kepala, tetapi kami membuatnya lebih buruk.

Kami menggunakan Google Chrome secara internal, untuk mendukung aplikasi yang dikembangkan khusus (di ASP.NET MVC) tetapi berjalan pada HTTP normal.

Kami juga memiliki masalah dengan halaman yang lambat karena cache. Tampaknya Chrome menarik semua file statis pada setiap pemuatan halaman, dan tidak menyimpannya dalam cache. Kami akhirnya hanya menambahkan header yang kedaluwarsa ke aplikasi kami untuk mengaktifkan cache, dan itu berhasil.

Anda bisa turun rute itu (memodifikasi aplikasi web Anda untuk menentukan strategi caching untuk setiap jenis file), atau menyelidiki lebih lanjut perilaku cache default Chrome.

Orang lain tampaknya memiliki masalah yang sama (misalnya http://www.google.com/support/forum/p/Chrome/thread?tid=741fd9e03cfb7e7b&hl=en ).

Artikel ini mungkin berguna karena menyediakan primer tentang caching Chrome: http://gent.ilcore.com/2011/02/chromes-10-caches.html

Saya mengalami masalah yang sama. Setelah lama mencari, saya menemukan alat monitor proses ( https://technet.microsoft.com/en-us/sysinternals/processmonitor.aspx ) Chrome mengalami banyak tabrakan yang mencoba menulis ke% TEMP%. Membersihkan direktori ini memecahkan masalah bagi saya.

Pada akhirnya, saya tidak dapat menemukan jawaban di sini. Semua tes pemantauan dan profil menunjukkan bahwa Google Chrome sangat lambat dalam memuat konten statis aman dari cache klien lokal. Tidak tahu kenapa. Kami harus meminta semua pengguna internal kami beralih ke IE (yang dilakukan sebagian besar orang dengan masalah serupa di web).

Jika backend adalah server berbasis java, ada bug java umum yang menyebabkan Tiket Sesi TLS menyebabkan penundaan besar. Anda dapat mensimulasikan bug dengan menggunakan openssl s_client yang benar-benar baru dan mengatakannya untuk mengaktifkan / menonaktifkan tiket sesi.

Penyebab sesungguhnya adalah ekstensi JSSE vs. TLS dengan nilai nol, yang digunakan tiket sesi atas permintaan pertama.

Segala kemungkinan server Anda kehabisan data acak. Di Linux jika Anda menggunakan /dev/randomdan kehabisan data acak, server Anda akan memblokir dan memuat halaman akan terlihat seperti hang.

Biasanya /dev/urandomcukup bagus. Jika tidak, ada beberapa perangkat keras yang bisa Anda peroleh yang akan menghasilkan data acak untuk Anda.

Saya melihat Anda menjalankan ASP .NET - Saya tidak dapat mengomentari apakah itu masalah pada Windows, tetapi layak untuk dilihat.