Re: WebPerfWG call - September 1st 2022 @ 10am PT / 1pm ET

Minutes are now available:

     Linked to from our WebPerf WG Agenda document 
     Published to the web-performance Github meetings page 
     ... and copied below:


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,



  * 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
  * … 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
  * … 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
  * 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?

- Nic

On 8/31/2022 4:01 PM, Nic Jansma wrote:
> Hi everyone!
> On the agenda 
> <> 
> for our next call (September 1st @ 10am PT / 1pm ET) we will discuss:
>   * TPAC 2022 Agenda
>   * Issues:
>       o ResourceTiming: Add delivery type to PerformanceResourceTiming
>         <>
>       o ResourceTiming: Consider adding
>         finalResponseHeaders{Start|End} times
>         <>
>       o NavigationTiming: Clarify how PerformanceTiming.responseStart
>         relates to Early Hint responses
>         <>
>       o LCP: Expose LCP renderTime in non-TAO cross-origin images,
>         when it doesn't reflect the image decoding time
>         <>
> *<>*
> If you have additional items, please add them to the agenda 
> <>.
> Join us <>!
> - Nic @NicJ

Received on Thursday, 8 September 2022 19:03:54 UTC