First HTTPS connection is very slow in Internet Explorer 11, what can it be?

Question

When using Internet Explorer 11 to connect to a HTTPS site of my company, the first connection is very, very slow. Usually more than 30 seconds. After this first connection, I can browse the site with no problem. The problem just happens in Internet Explorer, it works fine in Chrome and Firefox.

If after the first visit, I clear the cache and cookies, the next page load is quick. I have to close the browser and reopen it to reproduce the problem. Even if I let the browser idle for a couple of hours, the next visit is still quick. The problem is just in the first visit of a browser to this site.

Below you can see the network view of the developer toolbar:

The first connection is a HTTP connection that redirects to a HTTPS connection. This connection is very slow. The two following connections are quick. If I close my browser and visit directly the third URL via HTTPS, it will also load slowly.

Here is the Timing in the Detail view (sorry, I can't change my company browser language to English):

What can it be? How do I debug it? With this problem, it is very hard to execute automated web tests.

Solution 1

I've had the same problem as well. It happens only when the HTTPS site is being accessed on a machine without internet access and only using IE.

A workaround that i've applied on LAN would be to update IE settings as described below:

Go to IE Options, advanced tab then locate security category and uncheck “Check for publisher’s certificate revocation” and “Check for server certificate revocation”.

I've only found that workaround after seeing this post, so thanks for sharing :)

Solution 2

Since the problem happens only with HTTPS (right?) I guess that IE tries to check the revocation status of the site on the first visit. It probably caches the result, but only for the current browser session. There might be problems to reach the server responsible for the revocation (see OCSP/CRL settings inside the certificate) and thus the connection might time out. Chrome does not check revocation in most cases and Firefox might use a shorter timeout and ignore failures. You should see the attempts to get OCSP/CRL if you do a packet capture.

Comments

[Luca Ziegler]

Thank you very much this was the problem!

[albertski]

I'm having the same issue. One thing that we did is move the same exact site to a different server / URL. Both use Lets Encrypt. One server has the issue that on the first load but the other does not. If one server does not have the issue shouldn't there be a way to fix this without having to have every user update their IE settings?

[albertski]

Once I removed my site from Cloudflare the problem went away (Although I don't think the issue is Cloudflare but older versions of IE which were used by my clients).

[EIIPII]

The windows update page that is verified is described in this page: support.microsoft.com/en-ca/help/2677070/… In the case that the policy can not be updated, it is enough to make the calls to "ctldl.windowsupdate.com" fail fast.