ResourceTiming and preconnect about resource-timing HOT 8 CLOSED

IMO a link element (or header) that results in dns-prefetch, prefetch, preconnect or preload should show up as a separate entry in ResourceTiming with the appropriate initiatorType. Only the relevant timing fields will be set up.

For dns-prefetch and preconnect, the values apart from startTime should all be 0 unless Timing-Allow-Origin is set. This will, at the very least, give the site developer an indication that pre* happened on the page.

getEntriesByName("...") would return multiple entries if a pre* as well as a regular download happened, each would have the appropriate initiatorType.

from resource-timing.

That's a fairly indirect way of measuring the benefits. FWIW, I think that browser heuristic preconnects should also be exposed. Would enable interesting RUM analysis that may say "Site X is faster on browser Y because of the browser's preconnect heuristics" (which can enable site Y to add more preconnect directives to compensate for other browsers and enable other browsers to try and catch up)

from resource-timing.

See my comment on https://bugs.chromium.org/p/chromium/issues/detail?id=545936#c7

I don't think we should do anything special here. A preconnect has the same effect as reusing an existing connection; we should report zero's.

from resource-timing.

Maybe this doesn't belong at the current connect{Start,End} properties, but we need to address the "What is preconnect doing for my site for real users?" use case. Let's discuss in the F2F.

from resource-timing.

My expectation is a reduction in the resource timing's time spent in connect and TLS when preconnect is applied. This should be visible in A/B testing on 1st load of a freshly loaded browser on all platforms in all engines but PLT2 is likely to benefit from various engine's hinting mechanisms......

from resource-timing.

The problem with having it as a separate entry is that a dns-prefetch or a preconnect do not result in any way for the server to indicate a Timing-Allow-Origin. It would also make observable the fact that the browser actually complied with the hint.

The only way I can think of working around both these issues is to only insert the PerformanceEntry for the preconnect once it was used by an actual resource, and use the TAO info of that request to decide which information to include.

In our case, the lack of connection establishment timing for a fetch if a preconnect was used causes us to lose valuable telemetry.

from resource-timing.

A preconnect is not a fetch. Closing, feel free to open with new info.

from resource-timing.

Also, this was discussed at the WG's TPAC meetings, and there was consensus that this is not a required addition. So closing SGTM

from resource-timing.