See this test: http://www.webpagetest.org/result/130624_70_16f865cad8e256bec2fbcb208d5561bb/1/details/
The first request is reporting a start offset of 1.847 seconds. The DNS lookup is occurring immediately at time 0 and only lasts 0.03 seconds. Also note that the CPU utilization is very high during this time.
What could be causing this gap between DNS lookup and initial connection?
I began to notice this pattern in other tests of HTTPS sites.
That’s pretty bizarre. My initial guess would have been around OCSP or CRL checks but it looks like it is being done before the actual socket is connected.
I grabbed a tcpdump: CS Personal on cloudshark.org and it does look like it is all OCSP related. It’s possible that it remembers that it is going to need to verify since I no longer clear out the cert caches and it is trying to do it as soon as possible. Strange because it used to not bother verifying if it had done it recently.
Could be something specific to EV certs.
We switched our site to be HTTPS only, and have been plagued by this problem since then. On IE and on Safari we are seeing a reportedly slow performance from some of our user. None of us can reproduce it locally, but it is 100% reproducible using webpagetest.org. The problem manifests as gap in waterfall.
Here is an example:
http://www.webpagetest.org/result/140929_9M_13KR/1/details/
Note that the gap exists on every single connection (us, Google Maps, CDN, etc). What can be causing this gap?
Any insight into this would be much appreciated - even suggestions on how to narrow it down. We have used WPT to significantly improve our overall performance but, same as above, we have a large gap between the DNS Lookup and the Initial Connection. This is so big as a % of overall that there seems little point in continuing to improve other areas of performance until this is fixed.
Example here:
http://www.webpagetest.org/result/140929_VV_1BD8/1/details/
I’m out of ideas on how to take this forward…
@lbutler, Firefox is the easiest way to see what is going on with OCSP validation checks since the requests show up in the waterfall: http://www.webpagetest.org/result/141001_7Y_NW0/1/details/
The gap looks to be from cert revocation checks so the only way to get rid of it is to enable OCSP stapling on your server (or use a CDN that supports stapling).
Thanks for the Firefox tip, Patrick. It is amazing how much time is spent on OSCP checks given all the third party requests our site is making.
I was curious if there’s any more insight in terms of how to prevent this. Are there any new techniques?
Suddenly started happening on my measurements on private instance of WPT, but we don’t see it on the public instance. This has me scratching my head.