New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
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:
|
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
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
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
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
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
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
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
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
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 <bnc@chromium.org> Commit-Queue: Noam Rosenthal <nrosenthal@chromium.org> Cr-Commit-Position: refs/heads/main@{#1094571}
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 <bnc@chromium.org> Commit-Queue: Noam Rosenthal <nrosenthal@chromium.org> Cr-Commit-Position: refs/heads/main@{#1094571}
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 <bnc@chromium.org> Commit-Queue: Noam Rosenthal <nrosenthal@chromium.org> Cr-Commit-Position: refs/heads/main@{#1094571}
…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 <bnc@chromium.org> Commit-Queue: Noam Rosenthal <nrosenthal@chromium.org> Cr-Commit-Position: refs/heads/main@{#1094571} -- wpt-commits: e75f154bb894b0e2bf78cf1ac04e1cbecedebdc6 wpt-pr: 37984
…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 <bnc@chromium.org> Commit-Queue: Noam Rosenthal <nrosenthal@chromium.org> Cr-Commit-Position: refs/heads/main@{#1094571} -- wpt-commits: e75f154bb894b0e2bf78cf1ac04e1cbecedebdc6 wpt-pr: 37984
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". |
Since we've added early hints, now TTFB in RUM, which maps to
responseStart
means 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: