You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 and responseStart) rather than show 0 (which suggests it's before the request/response). To me, if there is no interim response then firstInterimResponseStart is the same as responseStart (because only then can you truly know there is no firstInterimResponseStart).
Or can firstInterimResponseStart happen with a redirect? In which case maybe having it set to 0 if not present and no redirects (i.e. before redirectEnd) 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?).
The text was updated successfully, but these errors were encountered:
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.
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?).The text was updated successfully, but these errors were encountered: