New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 5 users

Issue metadata

Status: ExternalDependency
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug

Sign in to add a comment

Issue 545936: Resource Timing does not work wih Preconnect

Reported by, Oct 21 2015

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.71 Safari/537.36

Steps to reproduce the problem:
1. Use the preconnect hint
2. Measure this preconnection with webpagetest
3. Compare the start fetch with resource timing

What is the expected behavior?

What went wrong?
Resource Timing does not show the correctly the start time when the resource is preconnected

Did this work before? No 

Chrome version: 46.0.2490.71  Channel: stable
OS Version: OS X 10.10.5
Flash Version: Shockwave Flash 19.0 r0

Preconnect + Flush Early ( is the host preconnected)

Comment 1 by, Oct 21 2015

Status: Assigned

Comment 2 by, May 31 2016

Labels: -OS-Mac OS-All
mmenke@ - I dug around to look for the source here, and I speculate that the socket is considered as a socket_reused, and therefore all DNS and connect info is zero. That's all pretty deep in the net stack, so I'd love your insights as to how I can tackle resolving that issue and make sure that preconnected sockets are not considered reused for the first object that uses them.

Comment 3 by, May 31 2016

The real issue is significantly different than what I initially assumed it is. I'll dig further.

Comment 4 by, May 31 2016

Note that we also don't report negative times - all times are capped so that they are not before request_start.  I'm not sure the load timing allows other behavior, and that data is also used for HAR files, which report times as deltas, and I suspect negative times would cause things to fall over there as well (I believe HAR file generators often use "-1" to indicate a time doesn't apply - like SSL times on a non-SSL connection).

Comment 5 by, May 31 2016

Err...load timing == Navigation Timing / Resource Timing APIs.

Comment 6 by, May 31 2016

That certainly complicates things assuming request_start translates into ResourceTiming's startTime().

FWIW, I don't think that's the current issue I'm seeing, but we may hit that when reporting that value. That's also something we'd hit if we'd want to expose push promises (we recently added support for that to load timing, but that's not exposed anywhere outside of devtools UI AFAICT).

We could theoretically expose preconnect as a separate value which HAR ignores, but I'd prefer a simpler way to resolve this.

Comment 7 by, May 31 2016

> I speculate that the socket is considered as a socket_reused, and therefore all DNS and connect info is zero.

I think this is correct behavior. There are many reasons why a socket could have already been in place - e.g. reused from another tab/window, preconnect due to browser heuristics, preconnect due to hint, etc. We don't distinguish these. As far as RT is concerned, the socket was already there when we try to open the request, so (some) of the connect times are zero.

I think this is a WONTFIX.

Comment 8 by, Jun 6 2016

Status: ExternalDependency (was: Assigned)
I agree that we need to address the use-case, but it's possible that just exposing it as connectStart is not the right way to go about this. This issue is now pending spec resolution at

Comment 9 by, Dec 6 2016

Components: Blink>Loader

Comment 10 by, Mar 29 2017


Comment 11 by, Sep 7 2017

Components: Blink>PerformanceAPIs>ResourceTiming

Comment 12 by, Feb 28 2018

This is still blocked on the spec.

Comment 13 by, Jun 21 2018

Still blocked on the spec.

Comment 14 by, Oct 15

Still blocked on the spec?

Comment 15 by, Oct 15

Indeed. Since this issue is currently marked as "Level 3", we'd probably need wrap up all the issues blocking Level 2 in order to get to this one:

Sign in to add a comment