Closed tunetheweb closed 4 months ago
Discussed in WebPerf WG on 29th Feb agreed to leave as is as this 0 time also happens for many other timings when not present (e.g. workerStart
), though admittedly it also does not for others (e.,g. domainLookupStart
- though it's arguable that DNS lookup always happens, it just might be cached so instant).
Anyway, there is precedent and the fact this serves as a useful signal whether Early Hints was used is also useful.
@tunetheweb took an action to document this on MDN but closing this for now.
MDN update PR: https://github.com/mdn/content/pull/32490
Agreed this will be helpful to keep at 0
when there is no Early Hint, as RUM providers can use this information to detect whether EH was active on a navigation.
Currently (at least by Chrome's implementation)
firstInterimResponseStart
returns 0 when there is no interim response (e.g. no 103 Early Hint). Should it?I would expect this to still fit in the resource timeline (so between
requestStart
andresponseStart
) rather than show 0 (which suggests it's before the request/response). To me, if there is no interim response thenfirstInterimResponseStart
is the same asresponseStart
(because only then can you truly know there is nofirstInterimResponseStart
).Or can
firstInterimResponseStart
happen with a redirect? In which case maybe having it set to0
if not present and no redirects (i.e. beforeredirectEnd
) is more technically correct, even if a little confusing since normally you'd expect these on the final response rather than the redirect (I'm not even sure if any browser supports 103 on redirects).On the other hand, setting it to 0 when there is no interim response does have the added advantage of making it easy to see if Early Hints are used. If we set it to the same as
responseStart
then it's difficult to differentiate between when it's not there at all and when it is there but sent at same time as the 200 (or should there always be at least 1ms gap in this case as they are processed separately?).