Chrome ralentiza sobre los sitios https, especialmente los internos

Estamos tratando de implementar Google Chrome en nuestra red corporativa, pero descubrimos que demora entre 2 y 4 veces más en cargar una página https (particularmente las nuestras internas) en comparación con IE. ¿Alguien ha experimentado esto y ha encontrado una solución?

Actualizar

Basado en la sugerencia de Handyman5, ejecuté algunos diagnósticos en Chrome y descubrí que la mayor cantidad de tiempo (más del 90% en cada página) se dedicaba a extraer archivos estáticos de la caché y renderizar la página. Sin embargo, si apago SSL en nuestro sitio, esto es casi instantáneo.

¿Alguna idea de por qué sería esto?

Chrome tiene una increíble herramienta de diagnóstico integrada, "about: net-internals" , que está diseñada para ayudar a solucionar problemas de red. En particular, tiene una pestaña "Eventos" que le permite especificar una URL y luego Chrome desglosa todo el proceso de carga, paso a paso, incluida la resolución DNS, los aciertos de caché y las solicitudes de elementos AJAX.

tl; dr Verifica cómo Chrome maneja la verificación y revocación de certificados.

Tuvimos un problema muy similar en una instalación en la que trabajé anteriormente, pero con Firefox. Para que esto sea un problema, debe confirmar que el problema es solo con las páginas https. Si no, hará poca diferencia.

Con Firefox (lo sé, lo sé, puedo leer, apunte próximamente), un grupo de personas tuvo problemas mientras que los usuarios de Internet Explorer (si puede creerlo) no. Habíamos utilizado la infame autoridad de ipsCA porque eran gratuitos para las instituciones educativas, pero finalmente enojaron a Firefox con su vergüenza y el control de sus certificados por parte de OCSP fue el culpable . Resulta que el navegador se estaba demorando debido al procesamiento de las Listas de revocación de certificados debido a la naturaleza de nuestros certificados SSL. Obviamente, como el mejor de nosotros, no mencionó su versión de Chrome, por lo que es difícil decir si fue un problemao sigue siendo un problema. Sin embargo, verificaría la configuración de CRL en Chrome. Hacerlo en Firefox alivió el problema. Además, verifique que sus certificados estén en regla, es decir, si están autofirmados. Lo que lo dejó en uso es que nos alejamos de la firma personal porque los usuarios idiotas de nuestros servicios se quejaban mucho y era gratis. Pensamos que nos estábamos ahorrando un dolor de cabeza, pero lo empeoramos.

Implementamos Google Chrome internamente, para admitir una aplicación desarrollada a medida (en ASP.NET MVC) pero ejecutándose en HTTP normal.

También tuvimos problemas con las páginas lentas debido al caché. Parece que Chrome extraía todos los archivos estáticos en cada carga de página y no los guardaba en su caché. Terminamos simplemente agregando encabezados caducados a nuestra aplicación para forzar el caché, y funcionó.

Podría seguir esa ruta (modificar sus aplicaciones web para especificar la estrategia de almacenamiento en caché para cada tipo de archivo) o investigar más el comportamiento de almacenamiento en caché predeterminado de Chrome.

Otros parecen tener problemas similares (por ejemplo, http://www.google.com/support/forum/p/Chrome/thread?tid=741fd9e03cfb7e7b&hl=en ).

Este artículo puede ser útil ya que proporciona un manual sobre el almacenamiento en caché de Chrome: http://gent.ilcore.com/2011/02/chromes-10-caches.html

Me encontraba con el mismo problema. Después de buscar durante mucho tiempo, descubrí que con la herramienta de monitoreo de procesos ( https://technet.microsoft.com/en-us/sysinternals/processmonitor.aspx ) Chrome estaba teniendo muchas colisiones al intentar escribir en% TEMP%. Borrar este directorio resolvió el problema para mí.

Al final, no pude encontrar una respuesta aquí. Todas las pruebas de monitoreo y creación de perfiles muestran que Google Chrome tarda mucho en cargar contenido estático seguro desde la memoria caché del cliente local. No tengo idea de por qué. Tuvimos que hacer que todos nuestros usuarios internos cambiaran a IE (que es lo que hizo la mayoría de las personas con problemas similares en la web).

Si el servidor es un servidor de aplicaciones basado en Java, hay un error común de Java que causa que los tickets de sesión TLS causen un gran retraso. Puede simular el error utilizando un openssl s_client realmente nuevo y diciéndole que habilite / deshabilite los tickets de sesión.

El verdadero culpable son las extensiones JSSE vs. TLS con valores nulos, que los tickets de sesión usan en la primera solicitud.

Cualquier posibilidad de que su servidor se quede sin datos aleatorios. En Linux, si usa /dev/randomy se queda sin datos aleatorios, su servidor se bloqueará y la carga de la página parecerá que se bloquea.

Por /dev/urandomlo general es lo suficientemente bueno. Si ese no es el caso, puede obtener hardware que generará datos aleatorios para usted.

Veo que está ejecutando ASP .NET: no puedo comentar si es un problema en Windows, pero vale la pena echarle un vistazo.