- From: Nic Jansma <nic@nicj.net>
- Date: Thu, 8 Sep 2022 15:03:38 -0400
- To: public-web-perf <public-web-perf@w3.org>
- Message-ID: <2cb7eb0f-6396-8f97-dd59-6a450526cf98@nicj.net>
Minutes are now available:
Linked to from our WebPerf WG Agenda document
<https://docs.google.com/document/d/10dz_7QM5XCNsGeI63R864lF9gFqlqQD37B4q8Q46LMM/edit#>
Published to the web-performance Github meetings page
<https://w3c.github.io/web-performance/meetings/>
... and copied below:
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
* https://github.com/w3c/resource-timing/pull/343
<https://www.google.com/url?q=https://github.com/w3c/resource-timing/pull/343&sa=D&source=editors&ust=1662665493083762&usg=AOvVaw1vHaHfGR1QnBjfMh_ogfX3>
* 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
* https://github.com/w3c/resource-timing/issues/345
<https://www.google.com/url?q=https://github.com/w3c/resource-timing/issues/345&sa=D&source=editors&ust=1662665493088948&usg=AOvVaw39O3qT7-DeWroxmA0XPSNy>
* 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
* https://github.com/w3c/largest-contentful-paint/issues/91
<https://www.google.com/url?q=https://github.com/w3c/largest-contentful-paint/issues/91&sa=D&source=editors&ust=1662665493096561&usg=AOvVaw0aW7JVZKkiOw3LiHPjX69a>
* 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
https://nicj.net/
@NicJ
On 8/31/2022 4:01 PM, Nic Jansma wrote:
> Hi everyone!
>
> On the agenda
> <https://docs.google.com/document/d/10dz_7QM5XCNsGeI63R864lF9gFqlqQD37B4q8Q46LMM/edit?pli=1#heading=h.osvewfb7hvdz>
> for our next call (September 1st @ 10am PT / 1pm ET) we will discuss:
>
> * TPAC 2022 Agenda
> * Issues:
> o ResourceTiming: Add delivery type to PerformanceResourceTiming
> <https://github.com/w3c/resource-timing/pull/343>
> o ResourceTiming: Consider adding
> finalResponseHeaders{Start|End} times
> <https://github.com/w3c/resource-timing/issues/345>
> o NavigationTiming: Clarify how PerformanceTiming.responseStart
> relates to Early Hint responses
> <https://github.com/w3c/navigation-timing/issues/181>
> o LCP: Expose LCP renderTime in non-TAO cross-origin images,
> when it doesn't reflect the image decoding time
> <https://github.com/w3c/largest-contentful-paint/issues/91>
>
> *<https://github.com/w3c/resource-timing/issues/304>*
>
> If you have additional items, please add them to the agenda
> <https://docs.google.com/document/d/10dz_7QM5XCNsGeI63R864lF9gFqlqQD37B4q8Q46LMM/edit?pli=1#heading=h.osvewfb7hvdz>.
>
> Join us <https://meet.google.com/agz-fbji-spp>!
> - Nic https://nicj.net/ @NicJ
Received on Thursday, 8 September 2022 19:03:54 UTC