Chrome lento em sites https, principalmente os internos

Estamos tentando implantar o Google Chrome em nossa rede corporativa, mas estamos descobrindo que leva 2 a 4 vezes mais tempo para carregar uma página https (principalmente as nossas próprias internas) em comparação com o IE. Alguém já experimentou isso e encontrou uma correção?

Atualizar

Com base na sugestão de Handyman5, executei alguns diagnósticos no Chrome e constatei que a maior quantidade de tempo (mais de 90% em cada página) estava sendo gasta em extrair arquivos estáticos do Cache e renderizar a página. No entanto, se eu desativar o SSL em nosso site, isso é quase instantâneo.

Alguma idéia de por que isso seria?

O Chrome possui uma incrível ferramenta de diagnóstico integrada, "about: net-internals" , projetada para ajudar a solucionar problemas de rede. Em particular, ele possui uma guia "Eventos", que permite especificar um URL e, em seguida, o Chrome detalha todo o processo de carregamento, passo a passo, incluindo resolução de DNS, ocorrências de cache e solicitações de elementos AJAX.

tl; dr Verifique como o Chrome lida com a verificação e revogação de certificados.

Tivemos um problema muito parecido em uma instalação em que trabalhei anteriormente, mas com o Firefox. Para que isso seja um problema, você precisa confirmar que o problema é apenas com páginas https. Caso contrário, fará pouca diferença.

Com o Firefox (eu sei, sei, posso ler, apontar adiante), muitas pessoas tiveram problemas, enquanto os usuários do Internet Explorer (se você pode acreditar) não tiveram. Tínhamos usado a infame autoridade ipsCA porque eram livres para instituições de ensino, mas , por fim, irritamos o Firefox com sua sombra e o OCSP era o culpado . Acontece que o navegador estava atrasando devido ao processamento de listas de revogação de certificados devido à natureza de nossos certificados SSL. Você, obviamente, como o melhor de nós, não mencionou sua versão do Chrome, por isso é difícil dizer se foi um problemaou ainda é um problema. No entanto, eu verificaria a configuração da CRL no Chrome. Fazer isso no Firefox aliviou o problema. Além disso, verifique se seus documentos estão em boas condições, ou seja, se são autoassinados. O que o dispensou de usar é que nos afastamos da autoassinatura porque os usuários idiotas de nossos serviços choramingavam muito e eram gratuitos. Pensávamos que estávamos poupando uma dor de cabeça, mas pioramos.

Implantamos o Google Chrome internamente, para oferecer suporte a um aplicativo desenvolvido personalizado (no ASP.NET MVC), mas rodando em HTTP normal.

Também tivemos problemas com páginas lentas por causa do cache. Parece que o Chrome estava puxando todos os arquivos estáticos em cada carregamento da página e não os salvando em seu cache. Acabamos simplesmente adicionando cabeçalhos expirados ao nosso aplicativo para forçar o cache, e isso funcionou.

Você pode seguir esse caminho (modificar seus aplicativos da web para especificar a estratégia de cache para cada tipo de arquivo) ou investigar mais o comportamento padrão de cache do Chrome.

Outros parecem ter problemas semelhantes (por exemplo, http://www.google.com/support/forum/p/Chrome/thread?tid=741fd9e03cfb7e7b&hl=en ).

Este artigo pode ser útil, pois fornece uma cartilha sobre o cache do Chrome: http://gent.ilcore.com/2011/02/chromes-10-caches.html

Eu estava correndo para o mesmo problema. Após pesquisar por um longo tempo, descobri com a ferramenta de monitoramento de processos ( https://technet.microsoft.com/en-us/sysinternals/processmonitor.aspx ) O Chrome estava enfrentando muitas colisões tentando gravar em% TEMP%. A limpeza deste diretório resolveu o problema para mim.

No final, não consegui encontrar uma resposta aqui. Todos os testes de monitoramento e criação de perfil mostram que o Google Chrome é muito lento ao carregar conteúdo estático seguro do cache do cliente local. Não faço ideia do porquê. Todos os usuários internos precisavam mudar para o IE (o que a maioria das pessoas com problemas semelhantes na Web fez).

Se o back-end for appserver baseado em java, há um bug java comum que faz com que os tickets de sessão TLS causem um grande atraso. Você pode simular o bug usando um realmente novo openssl s_client e dizendo para ativar / desativar tickets de sessão.

O verdadeiro culpado são as extensões JSSE vs. TLS com valores nulos, que os tickets de sessão usam na primeira solicitação.

Qualquer possibilidade de o seu servidor ficar sem dados aleatórios. No Linux, se você usar /dev/randome ficar sem dados aleatórios, o servidor bloqueará e o carregamento da página parecerá travado.

Geralmente /dev/urandomé bom o suficiente. Se não for esse o caso, poderá obter um hardware que irá gerar dados aleatórios para você.

Vejo que você está executando o ASP .NET - não posso comentar se é um problema no Windows, mas vale a pena dar uma olhada.