Consider adding finalResponseHeaders{Start|End} times #345
Comments
|
What is the definition of final that we're using here? From the HTTP RFC, a server can respond to a single request with multiple interim responses (1xx) and a single final response messages (2xx through 5xx)
And do we care about measuring the arrival times of trailer field sections on the final response message? |
This definition of final :)
Perhaps this is a separate conversation, since trailers are not currently widely supported. |
Great! I support add such timing markers.
Happy for that to be spun off |
|
We should also consider also |
|
Some points from the 9/1 W3C WebPerf call:
|
|
To @colinbendell 's point in #181, instead of adding
And then also add:
Only thing I don't like about that is we don't have the equivalent opposites (e.g. |
|
We don't always need equivalent opposites, like with |
Yeah I know, but there we don't have Anyway, I'll get over it. Just looks a little odd. |
|
I agree with @tunetheweb's proposal. This focuses |
|
Please don't prefix anything with early. If we want to support interim HTTP responses, call it that. Expect the HTTP to define more 1xx codes, because its been a part of HTTP since forever. If we only want to record the time of the first interim response, that fine. But let's be clear. What these events measure. Maybe today first and last interim response are measured at the same time due to fetch. In the future, if fetch changes to support multiple interim responses, our first and last markers would be ready. |
Though guess you could in theory have a |
Updated my comment to |
HTTP 103 is defined as "Early Hints", that's where early comes from. Perhaps |
I'm against being that specific. Who knows what the future will bring. |
Perhaps when we have new features in the future we find new names for their metrics and be specific about them? |
|
The HTTP spec calls these "Informational" responses (1xx). Should we converge on this language? |
Possibly. Do we measure WebSockets this way? Should Similarly HTTP/2 also had the
I like this. |
|
Only h2c, as defined in RFC 7540, uses 101. The latest revision of HTTP/2 is RFC 9113, which as Barry points out no longer mentions this feature. In most part because browsers do not implement h2c. We should ignore this. However 101 for WebSocket upgrade over HTTP/1.1 is an actual thing, we should not ignore it and consider if WebSockets and timings are anything we care about here. 103 Early Hints is defined and is seeing use. And there are use cases for other status codes. For example, 104 is provisionally allocated for resumable upload - newly adopted in the IETF HTTP WG. That specific provisional allocation might fizzle out, but let's be open to supporting the well-defined HTTP extension point of the 1xx status ranges; if we fail to do that job, we damage its future potential. I disagree with calling things informational responses. RFC 9110 doeant use that term, instead it defines interim responses, which use informational status codes. Terminology needs to be precise and consistent unless there is a good reason to diverge. Case in point, HTTP as defined in RFC 9110 has moved away from the terms payload and body, and now consistently uses the term "content". Ideally, W3C would align. But I believe due to legacy, that such a change would be disruptive However, new things that we are discussing here have no such legacy. |
I'm not sure I follow. Section 15.2 of rfc9110 calls 1xx "informational" class of response codes. |
|
Status codes are only a piece of a response message, the other pieces include metadata (in the form of field sections) and content. RFC 9110 does not use the term "informational response" anywhere. In contrast it uses the term "interim response" 4 times to describe a non-final response that includes a 1xx( informational) class of status code. |
|
I'm in favour of using interim as it expresses the non-final and non-authoritative nature of the response. As RFC 9110 states
|
We currently don't record resource timing for WebSockets at all, but I can see the other points. The main issue I have with interim/informational is that we might not have interim responses at all (most cases...), and also in some cases we'd have more than one, and this measures only the first one. How about |
See w3c/resource-timing#345 Since early hints have landed, there are additional useful timestamps that are currently not exposed: - First interim response start (e.g. when we received a 103) as a different timestamp from the final response start (e.g. when we received the 200) - Final headers received (when the last header has been received and we're ready for the body) - First bytes of the body received The naming in whatwg#345 is not finalized yet, but it's clear that these are the 3 interesting timestamps. This PR exposes those for later use by resource timing.
|
I posted a PR for the fetch spec. It shouldn't affect the naming bike shed, we can choose the names in the subsequent resource timing PR. |
|
One thing that I'm missing from this thread is a discussion of use cases. |
It's been discussed in the WebPerfWG call. The main use case is that servers who serve early hints and might have latency before serving the final headers/body now don't have visibility as to where this latency lies. |
|
There are a few use cases behind the above discussion:
|
|
Something that might be worth noting (if not already covered) is that in some scenarios, the checkpoints could appear to have the same values at the client, even if sent and different times on the server. This is especially noticeable if the client has large TCP receive windows and reads a "batch" of data after letting it accumulate for a little while. |
|
This is now implemented in chrome behind a flag (
It applies to resource timing, but probably only useful for navigation timing entries. |
See w3c/resource-timing#345 Since early hints have landed, there are additional useful timestamps that are currently not exposed: - First interim response start (e.g. when we received a 103) as a different timestamp from the final response start (e.g. when we received the 200) - Final headers received (when the last header has been received and we're ready for the body) - First bytes of the body received The naming in whatwg#345 is not finalized yet, but it's clear that these are the 3 interesting timestamps. This PR exposes those for later use by resource timing.
Add 3 response times: - firstInterimResponseStart: the first 103 - responseHeadersEnd: All headers have been received - responseBodyStart: The body started streaming Closes #345 Depends on whatwg/fetch#1483
See w3c/resource-timing#345 for context.
|
@noamr is there a follow-up bug for the other two timing channels or should this be reopened? |
Oh this shouldn't have been closed, I changed from "Closes" to "Bug". |
…onseStart, a=testonly Automatic update from web-platform-tests Resource Timing: Expose firstInterimResponseStart This adds an entry to PerformanceResourceTiming: - firstInterimResponseStart: the time of the first early-hints header It also changes the meaning of responseStart to be the first non-informational header (non-103). Implemented for Quic, Spdy and HTTP. All behind a feature runtime flag (ResourceTimingInterimResponseTimes) Spec issue: w3c/resource-timing#345 Bug: 1402089 Change-Id: I2f050788515959e3576f3cf2bd8df13ff848090a Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4165825 Reviewed-by: Bence Béky <[email protected]> Commit-Queue: Noam Rosenthal <[email protected]> Cr-Commit-Position: refs/heads/main@{#1094571} -- wpt-commits: e75f154bb894b0e2bf78cf1ac04e1cbecedebdc6 wpt-pr: 37984
|
As discussed at TPAC 2024 (slides, minutes) the implementation of This is not just related to browsers, but also other tooling (e.g. CrUX and Lighthouse on the Chrome side). In hindsight, implementing leaving So the new proposal of this would be to:
There was also a separate, related suggestion to implement Interested to hear feedback on this. |
As a fairly well-informed web developer, I don't agree with this definition. I would have assumed what you describe, is a breaking change to the knowledge and assumptions I hold. I expect Okay. I wrote the above intentionally before I check (or argue about) what the spec says or should say. I wanted to capture what I remember as a web developer who has been interested in and actively using this data for 10 years. Of course, I have also read spec numerous times in the past, and as WebPerf WG member, attended meetings talking about these specs. If anything that means I should know better. Although my participation started after NT finalised, and I don't think I was there when NT2/Resource Timing was discussed. If I'm not alone in my understanding, do we need to consider this as de-facto required for web compat? See also w3c/navigation-timing#181 (comment) where @adardesign clearly has the same understanding of responseStart:
Anyway, let's check the specs, starting with Navigation Timing 1 API (
There is a lot of mentions of "current document" around here. Although indeed, with hindsight, it leaves it out of https://www.w3.org/standards/history/navigation-timing-2/ The famous diagram, at the version I remember:
Of course, as part of Navigation Timing 2, the details were factored out to Resource Timing, which I must admit I haven't actually read in much detail. https://www.w3.org/standards/history/resource-timing.html
So indeed, the Resource Timing spec has technically recognised 103 Early Hints for responseStart since at least 2017, very explicitly. Still, I do think there is a potential web compat argument here. I, for one would not, until now, would not have attributed much significant to "frame header bytes". I'm vaguely aware that these frames exist, and aware of how 10x is sent by the server. Yet, I simply didn't make the connection before. Do we know of cases where developers specifically expected |
It's not so much as to what they expect that value to, as to how we can ensure it's cross-browser supported. When Early Hints came on the scene that meant that Could we have set up Early Hints better and changed all the specs and implementation in advance? I think the evidence with The "fix" was to introduce The only way to fix this, that I can see, is to revert The alternative other fix is, as you suggest, to try to ensure all browser roll out So while we can argue what people think By having both definitions, RUM tooling can show what they want—including having @adardesign's graph display either |
|
@tunetheweb Thanks for explaining the cross-browser compat issue in more detail. I see now that prefering the dev expectation I described, does not actually get us an ideal outcome for sites that already adopted Early Hints. Those sites will have had their data "change" in the past already, consistently across browsers, and have had to deal with that one way or the other. There is an element here of potentially over-optimisating for early adopters, though. We should think about future audiences as well. In a few more years, the duration from "adopt use of Early Hints (break responseStart)" to "fixed responseStart and implemented firstInterimResponseStart in baseline browser usage" will be very small in retrospect. For myself, that duration will be non-existent, since I haven't adopted it yet. Thinking about when I might adopt it in the future, I'd value continuity of a long-standing metric like This could be mitigated, by updating our feature test for metric collection, to require support for |
|
As I say there are arguments from both sides as to what the “response start” or “first bytes” are. You clearly have one interpretation in mind (and it’s a perfectly valid interpretation and one that others share too!), but there are also arguments that the “first bytes” are the first opportunity for the browser to start work on loading the page. And Early Hints give you that. Personally I’m less concerned about which name is used to represent which point, than of 1) reaching compat as soon as possible and for it to be consistently applied for all implementations (including older ones) and 2) being able to measure both. If we have two time points, no matter what they are called, then implementations that implement both can be measured as such. If we have only one point (because some implementations have not implemented the second point yet) then IMHO that should be consistent (and so consistent with the older spec). The current situation is… not great IMHO. And it’s not just measuring this in browsers. Lots of other measurements of this were built on the original interpretation of the spec. For example we in Chrome didn’t update CrUX—a miss in hindsight when we implemented it in However I’m delighted to hear your input and look forward to hearing others too. Thats the entire point of asking for feedback in this issue. If lots of other people prefer to continue down the |
|
@tunetheweb Yeah, I think you make a compelling case. We can't change what older browsers do, so anyone who has adopted it already or is going to adopt it in the next year or two, will, no matter what we agree on here, have to deal with the fact that responseStart shifts to match the Early Hints response. That decision was in the past and we can't change the old implementations. The easiest to way to prevent poisioning or mixing up data, is to keep it consistent (apart from the most recent Chrome change). The flipside of this is that, usually, when new features are adopted, if you want telemetry on it, you have an incentive at that point in time, to add to or update your metric collection code. Whereas here, you need to add or update it in order to keep even what I thought I already had. That's going to confuse folks a bit, and will be a breaking change to various metrics, alerts, calculations, and visualisations and assumptions built on top of Navigation Timing. The only good news is that (apart from a generic web host or CDN doing it for you) you're likely in charge of adopting this feature on your sites. So it should be fairly easy to explain the change in relation to what you recently did, and then decide whether you like that, or whether you need to start collecting I value data being easy to explain and reason about, and you've convinced me that keeping |
|
at issue.
I don't think we need to remove |
|
As discussed offline, a non-zero Additionally, the presence of if ('firstInterimResponseStart' in PerformanceNavigationTiming.prototype) {
finalResponseHeadersStart = responseStart;
responseStart = firstInterimResponseStart;
}As opposed to the slightly more convoluted: if ('firstInterimResponseStart' in PerformanceNavigationTiming.prototype &&
!'finalResponseHeadersStart' in PerformanceNavigationTiming.prototype) {
finalResponseHeadersStart = responseStart;
responseStart = firstInterimResponseStart;
} |
|
Discussed in WebPerf WG on 31st October and agreed to the following:
The reason we're keeping When implemented in Chrome this will revert |
I believe we don't have to change anything in fetch, it's all in resource timing :) |
|
Ah yes. Updated my comment. |
responseStart now returns `firstInterimResponseStart` as before, but falls back to `finalResponseHeadersStart` if there is no interim response. Closes #345
Since we've added early hints, now TTFB in RUM, which maps to
responseStartmeans something slightly different than it did before (though technically it represents the same thing).For services that rely on final response timing, perhaps we should also expose when the final headers started arriving, and when they ended and the body started?
The text was updated successfully, but these errors were encountered: