Estamos tentando implantar o Google Chrome em toda a nossa rede corporativa, mas constatamos que leva de 2 a 4 vezes mais tempo para carregar uma página https (especialmente as internas) em comparação com o IE. Alguém já experimentou isso e encontrou uma solução?
Atualizar
Com base na sugestão do Handyman5, executei alguns diagnósticos no Chrome e descobri que o maior período de tempo (mais de 90% em cada página) estava sendo gasto na extração de arquivos estáticos do Cache e na renderização da página. No entanto, se eu desativar o SSL em nosso site, isso é quase instantâneo.
Alguma ideia de por que isso seria?
No final, não consegui encontrar uma resposta aqui. Todos os testes de monitoramento e de perfis mostram que o Google Chrome é muito lento para carregar conteúdo estático seguro do cache do cliente local. Não faço ideia do porquê. Tivemos que fazer com que todos os nossos usuários internos mudassem para o IE (que é o que a maioria das pessoas com problemas semelhantes na Web fez).
O Chrome tem uma ferramenta de diagnóstico incorporada incrível, "about: net- internals ", que é projetado 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 elemento AJAX.
tl; dr Veja como o Google Chrome lida com a verificação e a revogação de certificados.
Tivemos um problema muito semelhante em uma instalação na qual eu trabalhei anteriormente, mas com o Firefox. Para que isso seja um problema, você precisa confirmar se o problema é apenas com as páginas https. Se não, isso fará pouca diferença.
Com o Firefox (eu sei, eu sei, eu posso ler, aponte), um monte de pessoas teve problemas enquanto os usuários do Internet Explorer (se você pode acreditar) não. Usamos a infame autoridade ipsCA porque eles eram gratuitos para instituições educacionais, mas acabou irritando o Firefox com a sua maturidade e a OCSP verificando os seus certs foi 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 a versão do Chrome, por isso é difícil dizer se foi um problema ou 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 os seus certificados estão em boas condições, isto é, se eles são auto-assinados. O que deu para usar é que nos afastamos da auto-assinatura porque os usuários idiotas de nossos serviços reclamavam muito e eram gratuitos. Nós pensamos que estávamos nos salvando de uma dor de cabeça, mas fizemos pior.
Implementamos o Google Chrome internamente para oferecer suporte a um aplicativo personalizado desenvolvido (no ASP.NET MVC), mas executado no HTTP normal.
Também tivemos problemas com páginas lentas devido ao cache. Parece Chrome estava puxando todos os arquivos estáticos em cada carregamento de página, e não salvá-los em seu cache. Acabamos simplesmente adicionando cabeçalhos de expiração 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 armazenamento em cache para cada tipo de arquivo) ou investigar o comportamento de cache padrão do Chrome.
Outros parecem ter problemas semelhantes (por exemplo, link ).
Este artigo pode ser útil, pois fornece uma documentação sobre o armazenamento em cache do Chrome: link
Eu estava correndo para o mesmo problema. Depois de pesquisar por um longo tempo, descobri a ferramenta de monitoramento de processos ( link ) que o Chrome estava em execução em muitas colisões tentando gravar em% TEMP%. Limpar este diretório resolveu o problema para mim.
Se o back-end for o servidor de aplicativos baseado em java, há um erro comum em java que faz com que os Títulos de sessão TLS causem um grande atraso. Você pode simular o bug usando um novo s_client openssl e dizendo para habilitar / desabilitar tickets de sessão.
O verdadeiro culpado é as extensões JSSE vs. TLS com valores nulos, que os tickets de sessão usam na primeira solicitação.
Qualquer possibilidade de o servidor ficar sem dados aleatórios. No Linux, se você usar /dev/random e ficar sem dados aleatórios, seu servidor bloqueará e o carregamento da página parecerá interrompido.
Normalmente, /dev/urandom é bom o suficiente. Se esse não for o caso, há algum hardware que pode gerar dados aleatórios para você.
Vejo que você está executando o ASP .NET - não posso comentar se isso é um problema no Windows, mas vale a pena dar uma olhada.
Tags google-chrome https