Participants
Jeremy Roman, Carine Bournaz, Colin Bendell, Amiya Gupta, Noam Helfman, Barry Pollard, Noam Rosenthal, Lucas Pardue, Alon Kochba, Benjamin De Kosnik, Nic Jansma, Patrick Meenan, Yoav Weiss, Ian Clelland, Steven Bougon, Andrew Galloni,
Minutes
Admin
- Nic: Last meeting before TPAC, hoping to see many in person and remote
- … Went through the topic proposals, and have a proposed agenda
- … Anyone interested to talk or has a proposal, please review the agenda
- … Still have a few open slots, but still things we didn’t put into the agenda, so please review
- … Michal proposed doing a webperf debugging workshop, thinking of doing that on Thursday afternoon, after hours
- … We’ll give it a try, and see how it goes
- … We’ll figure out if we can stream/record it as well
- … Had a few folks that said they’d join, so please update the attendees list
- … 2 joints meetings with APA and PING to discuss
- … Aggregated reporting - Want to talk about how we could potentially report cross-origin data in aggregate
- … VC solution - we’re staying with the same meeting as our bi-weekly calls
- … Next meeting - 4 weeks from now, September 29th
Add delivery type to PerformanceResourceTiming
- Jeremy: Essentially proposes adding a delivery type
- … Interested in doing navigational prefetch, and there’s no way for developers to tell that a resource is prefetched
- … Initial version would allow us to indicate that a resource was delivered from the cache which is currently only exposed through transferSize
- … An attribute on resource timing entry, with either an empty string or a “cache” value
- … Planning to add an additional enumerator for “prefetch”
- … Won’t be difficult to test through WPT
- Nic: No concerns from me, but would be great to have a more explicit signal for cached vs. non-cached
- Katie: +1
- Nic: Any TAO restrictions?
- Jeremy: For the cache signal, it’s exposed through transfer size, which is TAO restricted
- Nic: For RUM, for same-origin and TAO we have transfer size, and otherwise we have timing related heuristics. Would be great to know explicitly in those other cases
- Ian: Is it useful if you can’t see it cross origin?
- Jeremy: For my use case, it is. For other resources, I don’t know if exposing it is risky. Transfer size exposes more information
- … I’d be OK with making it TAO restricted, but would be good to have people that know about those restriction to chime in
- … For the document prefetch case, it’s not a concern
- … It feels to me like you can get most of this info from timing, especially when browsers are partitioning caches, that seems safe. But not sure.
- Noam H: can share somewhat related cases for transfer type. Needed to differentiate SW cache fetch from other fetches. We actually needed to see if it was precompiled bytecode from the cache
- … we were looking for ways to determine if a resource came from the SW code cache
- Noam R: RE TAO, there’s another issue to move transfer size to be CORS protected rather than TAO protected. But delivery type is more tied to the fetch. Would need to be TAO protected
- … For additional information, I suggest to use server timing and add that to the resource as part of the caching. Consider your SW to be your server
- NoamH: Thoughts on precompiled bytecode cache vs. regular resource? In SW in Chromium, if the resource is in the SW cache, it’s eagerly compiled to bytecode
- … we don’t have a way to know if that actually happens or not
- NoamR: Yeah, that’s not currently observable
- Yoav: Noam said that transferSize should be CORS protected, and I agree to a large extent, but you said this should be TAO protected? I’m not sure what we’re defending against here?
- … Given that there are already strong heuristics whether a resource is in your partitioned cache
- … It would be interesting to think about the tradeoffs, maybe the answer is TAO? But to me it’s not immediately obvious
- NoamR: Yes let’s think about it further, I don’t have an immediate answer
- Katie: One thing that has been frustrating is we can use these fallback heuristics figuring out how many resources for cache vs. network, but Safari doesn’t return any of that information. Curious if just this “from cache” flag would be something that Safari would be willing to opt into.
- … For data analysis it’s very important to understand how things are in cache vs. network
- Alex: I definitely hear you. I’m preparing remarks to present at TPAC and raised an issue on the spec, that we should talk about more at TPAC. I proposed allowing UA to only expose first party transfer size with no way of opting in at TPAC.
- … Believe it would be controversial.
- Yoav: no strong objections, and need to figure out opt-in
- Alex: I wouldn’t say “no strong objections”
Consider adding finalResponseHeaders{Start|End} times
- Noam: Came from the next issue on the agenda - Early Hints makes our life confusing. TTFB is ambiguous - Time to A First Byte
- … responseStart is the time when you get the first response headers
- … With early hints, that time is reached earlier
- … But there are more timestamps that are not exposed in ResourceTiming
- … Whenever you get a non-continuation response
- … And whenever the header is done and you start receiving the body
- … So the proposal is to expose those timing that are more precise, and have the site and RUM provider determine what is TTFB
- Colin: also include the time to the first byte of the body? Can be different than the response header end
- Nic: Would apply to regular responses as well
- Colin: exactly
- Lucas: Totally agree with Colin. Easy to assume there’s no gap, but there are cases where that’s not true.
- … When doing H2 prioritization when the data frames are flushed early with the headers, but the body gets delayed. It’s important to get that right, and when we can’t do that, the metrics can get skewed.
- … Fully support adding timing to the body. Right thing to do
- Giacomo: Want to add a new timing where the status code 200 is arriving? If that’s the goal calling these final response header can be a future issue when/if we add more headers in between the 103 response and the 200 response
- NoamR: If we’d change, we’ll see. Hard to foresee the future, but we can bikeshed the name
- … “final” sounds descriptive
- Colin: 1xx and 3xx can impact the definition of what’s final. Could we have the body start before the request ends? Can we assume that the headers frames land before the data frames start?
- Lucas: I was asking a similar question on the issue. The ordering in terms of HTTP is well-defined. 1XX has been around for a while. We should align with HTTP terms of what’s “final”.
- … Also in terms of ordering, you get 0 to many 1XX responses, then final response, body and trailer
- … On the wire things can get out of order, but the UA processing them would need to reorder them
- … At the app layer, we’d need to read all the headers first, then body, then trailers
- … Needs to be properly defined, but don’t foresee problems
- Colin: Good call of not having the to reflect the network ordering, but the app
- NoamR: Also how this works in the Fetch spec
- Barry: Diverging from the issue. First real 1xx response header, first 200 response header and then response body.
- .. We don’t care about 103 end or multiple 103s?
- NoamR: Fetch doesn’t support multiple 103s - others are ignored
- Barry: 200 timings are the ones that people want, but need to agree on what’s being added
- NoamR: First 1XX, 200 and the body
- Nic: Same question as the last PR. protected by TAO/CORS? Seems similar to response start
- NoamR: Seems like something that should be TAO protected
- … Also related to aggregated reporting - may make sense to move some metrics to aggregated reporting
- Colin: There is a colloquial definition of response start as the final response header start.
- … I’d prefer to have a different metric for the 1XX response
- Yoav: 100 responses always set the responseStart
- Colin: We’ve had 10 years of assuming 1XX are not a thing
- NoamR: Doesn’t the world change once we have Early Hints? They allow you to already download subresources, which is significant
- … In a way they are equivalent to the head of your document
- … So that maps better to the responseStart definition
- Lucas: If you go to the logical conclusion - 100 continue means something special
- … 103 can be safely ignored, so developers can game TTFB by sending useless 103s
- … Need some consideration for what this means
- NoamR: Once we have those new metrics, it’d be less gameable
- Lucas: With the new metrics, we can do that. We’d be able to retrain the community about what these things mean
- Nic: So in summary - didn’t hear a ton of pushback on it. Need to explore what we should define as the “first bytes”, headers for Early Hint or the “final” content’s headers
- … Looking for additional feedback?
- NoamR: Want to flesh out any objections. The main question is which one of them should be responseStart
- … If no real objections, we can move towards a PR
- Nic: SG. Would post a summary to the issue
- Issue 181
- Colin: Impact of change management. New metrics solve part of the problem, but need systems to change. Should match the current colloquial understanding to ensure the consistency of the metrics.
- Nic: Continue discussion in that ticket
Expose LCP renderTime in non-TAO cross-origin images, when it doesn't reflect the image decoding time
- Yoav: Already discussed, but want to make progress on
- … Various cases where LCP is hidden, because TAO is not enabled
- … But render time itself doesn’t expose anything about the image, because it’s not rendered when it’s decoded
- … Diff between render and decode time typically notes how long the decode time, which can expose info in cross-origin resources
- … But in some cases, LCP can be shown outside of the typical path, e.g. via JavaScript or A/B testing cases, or whenever the real render time is lower than the FCP. Whenever this condition is met, it means the render time of the image doesn’t expose anything about the image, just the FCP
- … If everyone agrees, and there’s nothing major we’re missing here, what I’m proposing is to move ahead in exposing renderTime w/out TAO if it’s less than FCP
- … If time when it was ready to be rendered is less than when it’s less than when anything is painted to the screen, it’s safe to expose it
- … There may be additional cases, but this is a bare minimum
- … Or should I run this through my security folks?
- Benjamin: Also HTML folks
- Yoav: We’re pushing this complexity to RUM providers today
- … Today LCP’s startTime is significantly lower than the FCP
- … And RUM providers flag that, throw it away, or change it
- Noam: Is it for first one, or images that come after FCP?
- Yoav: It’s mostly about the first one.
- … Continue the discussion at TPAC?