Chrome rallenta sui siti https, in particolare quelli interni

Stiamo cercando di distribuire Google Chrome sulla nostra rete aziendale, ma stiamo scoprendo che ci vuole 2-4 volte più tempo per caricare una pagina https (in particolare la nostra interna) rispetto a IE. Qualcuno ha sperimentato questo e trovato una soluzione?

Aggiornare

Sulla base del suggerimento di Handyman5, ho eseguito alcuni test diagnostici in Chrome e ho scoperto che il maggior tempo (oltre il 90% su ogni pagina) veniva impiegato per estrarre i file statici dalla cache e renderizzare la pagina. Tuttavia, se disattivo SSL sul nostro sito, questo è quasi istantaneo.

Qualche idea sul perché questo sarebbe?

Chrome ha un fantastico strumento diagnostico integrato, "about: net-internals" , progettato per aiutare a risolvere i problemi di rete. In particolare, ha una scheda "Eventi" che consente di specificare un URL e quindi Chrome interrompe l'intero processo di caricamento, passo dopo passo, tra cui risoluzione DNS, hit della cache e richieste di elementi AJAX.

tl; dr Controlla come Chrome gestisce il controllo e la revoca dei certificati.

Abbiamo avuto un problema molto simile in una struttura in cui avevo precedentemente lavorato, ma con Firefox. Perché questo sia un problema, devi confermare che il problema è solo con le pagine https. In caso contrario, farà poca differenza.

Con Firefox (lo so, lo so, posso leggere, sottolineare il prossimo), un gruppo di persone ha avuto problemi mentre gli utenti di Internet Explorer (se puoi crederci) no. Avevamo usato la famigerata autorità ipsCA perché erano gratuiti per le istituzioni educative, ma alla fine incazzarono Firefox con la loro ombra e il controllo OCSP delle loro autorità era il colpevole . Si scopre che il browser stava ritardando a causa dell'elaborazione degli elenchi di revoche di certificati a causa della natura dei certificati SSL. Ovviamente, come il migliore di noi, non hai menzionato la tua versione di Chrome, quindi è difficile dire se fosse un problemao è ancora un problema. Tuttavia, vorrei controllare la configurazione CRL in Chrome. Farlo in Firefox ha alleviato il problema. Inoltre, controlla che i certificati siano in regola, cioè se sono autofirmati. Ciò che ha dato via da usare è che ci siamo allontanati dall'auto-firma perché gli utenti idioti dei nostri servizi si lamentavano molto ed era gratuito. Pensavamo di risparmiarci un mal di testa, ma abbiamo peggiorato le cose.

Abbiamo implementato Google Chrome internamente per supportare un'applicazione sviluppata su misura (su ASP.NET MVC) ma in esecuzione su HTTP normale.

Abbiamo anche avuto problemi con le pagine lente a causa della cache. Sembra che Chrome stia tirando tutti i file statici su ogni caricamento di pagina e non li salvasse nella sua cache. Alla fine abbiamo semplicemente aggiunto le intestazioni scadute alla nostra app per forzare la cache e ha funzionato.

Potresti seguire questa strada (modificare le tue applicazioni web per specificare la strategia di memorizzazione nella cache per ciascun tipo di file) o esaminare ulteriormente il comportamento predefinito della memorizzazione nella cache di Chrome.

Altri sembrano avere problemi simili (ad es. Http://www.google.com/support/forum/p/Chrome/thread?tid=741fd9e03cfb7e7b&hl=en ).

Questo articolo può essere utile in quanto fornisce un'anteprima sulla memorizzazione nella cache di Chrome: http://gent.ilcore.com/2011/02/chromes-10-caches.html

Stavo riscontrando lo stesso problema. Dopo aver cercato a lungo, l'ho scoperto con lo strumento di monitoraggio dei processi ( https://technet.microsoft.com/en-us/sysinternals/processmonitor.aspx ) Chrome stava riscontrando molte collisioni nel tentativo di scrivere su% TEMP%. La cancellazione di questa directory ha risolto il problema per me.

Alla fine, non sono riuscito a trovare una risposta qui. Tutti i test di monitoraggio e profilazione mostrano che Google Chrome è molto lento nel caricare contenuto statico sicuro dalla cache del client locale. Non ho idea del perché. Abbiamo dovuto fare in modo che tutti i nostri utenti interni passassero a IE (che è quello che ha fatto la maggior parte delle persone con problemi simili sul Web).

Se il back-end è un appserver basato su Java, esiste un bug java comune che causa un ritardo enorme dei ticket di sessione TLS. Puoi simulare il bug usando un nuovissimo openssl s_client e dandogli di abilitare / disabilitare i ticket di sessione.

Il vero colpevole sono le estensioni JSSE e TLS con valori nulli, che i ticket di sessione utilizzano nella prima richiesta.

Qualsiasi possibilità che il tuo server esaurisca i dati casuali. Sotto Linux se usi /dev/randomed esaurisci i dati casuali, il tuo server si bloccherà e il caricamento della pagina sembrerà bloccato.

Di solito /dev/urandomè abbastanza buono. In caso contrario, è possibile ottenere hardware che genererà dati casuali per te.

Vedo che stai eseguendo ASP .NET: non posso commentare se questo è un problema su Windows, ma vale la pena dare un'occhiata.