Long SSL connection in Chrome on repeat visit

Hi all,

I’m seeing an odd (at least I think it’s odd) repeat visit on Chrome


It’s more pronounced on our local webpagetest instance, but looking at the netlog, the same kind of behaviour is apparent; an ssl connection is made for the page and then for a load of other ssl domains that the page references, which seems to hold up the TTFB of the page and all the subsequent metrics

My question is is this standard behaviour? It really is skewing all our repeat visit metrics, which are actually turning out to be longer than the first visit


Quick sanity check, can you try testing with the “Dulles Thinkpad” test location? It has a boatload more CPU power and will show how much of the issue is because of being CPU bottlenecked.

It is standard behavior for Chrome to be opening all of the connections early, that is part of the network predictor logic that learns as you browse but it’s not supposed to negatively impact the actual loading. It might be able to be disabled for testing purposes using a command-line (not sure though).

Thanks for the reply Patrick

Re-run in Dulles,


Pretty much the same results, repeat view start render is now slightly slower than first. Seems to be gaps in the waterfall

Interesting that it should not be effecting anyone else though…

I am seeing something similar as well. In the repeat view, some of the SSL negotiations take very long time and it appears to delay the overall page rendering. Sometimes, it is so bad that repeat view is taking more time than the first view.