Chrome slow over https sites, particularly internal ones

Chrome has an awesome built-in diagnostic tool, "about:net-internals", which is designed to help troubleshoot network problems. In particular, it has an "Events" tab which lets you specify a URL and then Chrome breaks down the entire process of loading it, step-by-step, including DNS resolution, cache hits, and AJAX element requests.

tl;dr Check how Chrome handles certificate checking and revocation.

We had a very similar issue at a facility I previously worked at, but with Firefox. For this to be an issue, you need to confirm the issue is only with https pages. If not, it will make little difference.

With Firefox (I know, I know, I can read, point forthcoming), a bunch of people had issues while Internet Explorer users (if you can believe it) did not. We had used the infamous ipsCA authority because they were free for educational institutions, but eventually pissed off Firefox with their shadiness and OCSP checking of their certs was the culprit. Turns out the browser was delaying because of processing Certificate Revocation Lists because of the nature of our SSL certs. You obviously, as the best of us, did not mention your Chrome version, so it hard to say if it was an issue or is still an issue. However, I would check CRL configuration in Chrome. Doing so in Firefox alleviated out issue. Also, check your certs are in good-standing, that is if they are self-signed. What gave it away to use is we moved away from self-signed because idiot users of our services whined a lot and it was free. We thought we were saving ourselves a headache, but we made it worse.

We deployed Google Chrome internally, to support a custom developed application (on ASP.NET MVC) but running on normal HTTP.

We also had issues with slow pages because of the cache. It seems Chrome was pulling all the static files on every page load, and not saving them in its cache. We ended up simply adding expires headers to our app to force the cache on, and that worked.

You could go down that route (modify your web applications to specify caching strategy for each type of file), or investigate further Chrome's default caching behavior.

Others seem to have similar problems (e.g. http://www.google.com/support/forum/p/Chrome/thread?tid=741fd9e03cfb7e7b&hl=en).

This article may be useful as it provides a primer on Chrome caching: http://gent.ilcore.com/2011/02/chromes-10-caches.html

I was running into the same issue. After searching for a long time I found out with the process monitor tool (https://technet.microsoft.com/en-us/sysinternals/processmonitor.aspx) Chrome was running into many collisions trying to write to %TEMP%. Clearing this directory solved the issue for me.

In the end, I couldn't find an answer here. All the monitoring and profiling tests show that Google Chrome is very slow at loading secure static content from local client cache. No idea why. We had to have all of our internal users switch to IE (which is what most of the people with similar problems on the web did).

If the backend is java-based appserver, there is a common java bug that causes TLS Session Tickets to cause a huge delay. You can simulate the bug by using a really new openssl s_client and telling it to enable/disable session tickets.

The real culprit is JSSE vs. TLS extensions with null values, which session tickets use on the first request.

Any possibility that your server runs out of random data. Under Linux if you use /dev/random and run out of random data your server will block and the page load will look like it hangs.

Usually /dev/urandom is good enough. If that is not the case there's some hardware you can get that will generate random data for you.

I see you are running ASP .NET -- I can't comment on wether that is an issue on Windows, but well worth a look.