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

Issue 545936 link

Starred by 5 users

Issue metadata

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



Sign in to add a comment

Resource Timing does not work wih Preconnect

Reported by guilherm...@gmail.com, 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 (cia.gov is the host preconnected)

http://www.webpagetest.org/result/151017_D8_c663212218280d06c36563a58acc2489/1/details/

http://ec2-54-207-109-100.sa-east-1.compute.amazonaws.com/projetos/workshop/flush/preconnect.php
 

Comment 1 by y...@yoav.ws, Oct 21 2015

Owner: y...@yoav.ws
Status: Assigned

Comment 2 by y...@yoav.ws, May 31 2016

Cc: mmenke@chromium.org
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 y...@yoav.ws, May 31 2016

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

Comment 4 by mmenke@chromium.org, 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 mmenke@chromium.org, May 31 2016

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

Comment 6 by y...@yoav.ws, May 31 2016

Cc: igrigo...@chromium.org
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.
> 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 y...@yoav.ws, 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 https://github.com/w3c/resource-timing/issues/58
Components: Blink>Loader

Comment 10 by addyo@chromium.org, Mar 29 2017

Cc: addyo@chromium.org
Components: Blink>PerformanceAPIs>ResourceTiming
This is still blocked on the spec.
Still blocked on the spec.
Still blocked on the spec?
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: https://github.com/w3c/resource-timing/issues?q=is%3Aopen+is%3Aissue+milestone%3A%22Level+2%22

Sign in to add a comment