8

We are trying to deploy Google Chrome across our corporate network, but we're finding that it takes 2-4X longer to load an https page (particularly our own internal ones) compared to IE. Has anyone experienced this and found a fix?

Update

Based on Handyman5's suggestion, I ran some diagnostics in Chrome, and found that the largest amount of time (over 90% on each page) was being spent on pulling static files from Cache and rendering the page. However, if I turn off SSL on our site, this is almost instantaneous.

Any thoughts on why this would be?

4
  • Can you add a tcpdump trace? That would really help. Are you running out IPV6 in your network? I occasionally come across this issue where the sysadmin adds DNS records but doesn't enable V6 on the remote end point
    – Lmwangi
    Jun 6, 2011 at 6:55
  • We are not running IPV6, and I don't think DNS records are applicable since we're accessing the site directly (i.e. https:// 192.168.0.33/). I'll try to install wireshark or similar tool on a desktop to see if I can post a trace.
    – Beep beep
    Jun 6, 2011 at 7:15
  • what DNS servers do you use/
    – warren
    Jun 28, 2011 at 19:06
  • Doesn't seem to matter ... internal DNS, Verizon, or even when accessing the site by IP address.
    – Beep beep
    Jun 28, 2011 at 19:43

7 Answers 7

18
+25

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.

3
  • Wow, never knew about this. I'll try it out, thanks!
    – Beep beep
    Jun 29, 2011 at 22:56
  • Weird ... I wonder if Chrome handles caching on secure sites differently than IE? After running this and the Timeline in Chrome's developer's tools, it appears that the longest time is being spent processing static files from Cache. On a non-secure site, this isn't the case - it pulls the cache files almost instantaneously. For example, on one small page, it took 100ms to receive the dynamic content from the page, but then another 1.9 seconds to pull javascript from cache. In IE, this page opens up in less than .5 seconds, and when I turn off SSL it opens up even faster in Chrome.
    – Beep beep
    Jul 1, 2011 at 11:03
  • Feature has been removed. The following text is disaplayed on the Events tab: The net-internals events viewer and related functionality has been removed. Please use chrome://net-export to save netlogs and the external catapult netlog_viewer to view them.
    – MHeld
    Apr 2, 2019 at 8:31
8

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.

3
  • Good thought - our internal apps are still in development and self-signed, so maybe that is the issue. We'll be buying a real cert, maybe that will make a difference.
    – Beep beep
    Jun 6, 2011 at 16:47
  • Well, disregard then. This issue would be with signed certs from a real CA, but the CA turns out to be crappy one. This is probably not your issue then.
    – songei2f
    Jun 7, 2011 at 7:28
  • We'll still try it out, I appreciate the feedback
    – Beep beep
    Jun 7, 2011 at 21:09
2

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

1
  • Our issue isn't that the files are being re-transmitted, but rather that pulling from cached files (in client-side memory) is really slow. I guess we'll have our internal users utilize IE.
    – Beep beep
    Jul 2, 2011 at 16:07
2

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.

1
  • 1
    Fixed the problem for me too Jan 24, 2017 at 9:01
1

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).

0

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.

1
  • The back-end is ASP.NET MVC.
    – Beep beep
    Jul 3, 2011 at 22:17
0

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.

1
  • Don't think so, since it's only in Chrome (and to an extent in Firefox). Our site is blazingly fast in IE, or in any browser if HTTPS is off. It appears to be related to pulling data from client-side cache. Chrome does so VERY slowly for an HTTPS site, but quickly for anon-https. Makes no sense to me.
    – Beep beep
    Jul 5, 2011 at 2:35

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .