Chair: Yoav Weiss

Scribe: Charlie Vazac

Participants: Ryosuke Niwa, Nic Jansma, Charlie Vazac, Tim Dresser, Nicolás Peña, Panagiotis Astithas

Start by setting up next call - Next meeting is October 2nd, 11a PST

New charter announced today, we need to rejoin the wg.

Talk to your AC rep, AC rep needs to click thru the rejoining process.

Resource Timing

  1. https://github.com/w3c/resource-timing/pull/163
  1. Theoretical potential for loss of entries versus more complex processing model
  2. In PR, Yoav specified fixed size of secondary buffer, meaning we might end up dropping entries on the table
  3. Webkit model will not drop entries, but it’s more complex
  1. Amount of entries is unbound between buffer full event and ultimate clearing or increasing of the buffer size
  1. Ryosuke points out that it’s no different in MO, IntersectionObsever - unlimited entries
  2. Yoav points out that, with this pattern, the buffer could overflow to infinity
  3. Yoav argues that the processing model of Webkit is significantly more complex than what’s specified in the spec
  4. Yoav points out that this is a edge-case
  5. Ryosuke wants a way to ensure that developer will not miss any entries
  6. Yoav says that there is a bug in the spec today means we’ll always drop at least one entry
  7. Tim D. asked what is concern with complexity
  8. Yoav is concerned about spec and impl. Complexity
  9. Ryosuke says that current spec is un-implementable
  10. Yoav: do we want a simpler model with losing entries, or more complex one that doesn’t lose entries
  11. Tim D. should we see what the complex version of the spec would look like to see how bad it is?
  12. Yoav agrees to do this work in next few weeks - ACTION ITEM
  13. Panagiotis does not have feedback on this - will not be at TPAC, likely no webperf folks will be there
  14. Tim D. points out that Harald said Moz. reps might be there
  1. Untriaged issues
  2. https://github.com/w3c/resource-timing/issues/164
  1. Devtools shows “queuing” and “stalled” for some requests, but we don’t show it in RT
  2. Those values are included in duration, so they are inferable
  3. This is mostly for h1, not h2
  4. Yoav - I’m not sure this is something we want to expose, and this would be most effective on h1 stacks, as there’s no queuing related to TCP connects in most impls. of h2, they are only queued in h1 when there are no connections available
  5. Nic - is this just about tcp queuing time? Yoav - yes
  6. Steve Souders posted a few years back that the RT chunks are not additive to duration
  7. Nic - we see gaps between the chunks in RT data in the wild, browser quirks, stalls, boomerang does not expect the chunks to add up to duration
  8. Nic - we don’t try to account for ALL the time
  9. Nic - with cross origin resources, there is a gap in the data _somewhere_
  10. Yoav - because there are many queuing times, exposing them all night be messy, Nic agrees
  11. Yoav - and we can’t expose queuing time for cross origin resources without TAO
  12. Nic to comment in github issue ACTION ITEM
  13. Nic - without queuing/blocking time, we don’t know if it was network time, or time spent waiting for the network (queuing)
  14. Ryosuke - we might need a clearer definition of queuing
  15. Ryosuke - for the screenshots between the browsers, blocking and queuing might not mean the same thing
  16. Ryosuke - time spent waiting for server should be after connect start
  17. Nic - boomerang calculates blocking time as connect-end to request-start
  18. Ryosuke - what else would you get from queuing / blocking?
  19. Nic - if you don’t have TAO, you can’t know if the time was spent waiting for connection, or waiting on network
  20. Yoav - you shouldn’t/can’t know, security impl.
  21. Yoav - what the OP is trying to accomplish is available with arithmetic, does he/she need something else?
  22. Yoav - this is probably not something we want to pursue, unless we are missing something else
  23. Resolution: Nic to comment in thread, check if our understanding matches, see if the arithmetic approach suits his/her needs
  1. https://github.com/w3c/resource-timing/issues/161 (from Nicolás - @npm1)
  1. Yoav - in chromiums impl, fetch is observed, so it can’t be terminated early ??
  2. Nic - is this a fetch spec or RT spec issue?
  3. Yoav - either in RT or in fetch, we need to say “shouldn’t be observable”
  4. Yoav - but why can’t a fetch be terminated early because of RT?
  5. Yoav - [quotes relevant fetch spec bits]
  6. Ryosuke - oh, this is a gc thing
  7. Ryosuke - making RT observable makes gc observable
  8. Yoav/Ryosuke - we don’t want to do that
  9. Yoav - from the notes, RT shouldn’t be observable thru script
  10. Ryosuke - explains how one could observe gc thru RT
  11. Yoav - points out that the fetch spec defines “observability” as something thru fetch c’tor/options, this doesn’t apply to RT
  12. Ryosuke - we need to file issue in fetch
  13. Yoav - this applies to PO and perf timeline
  14. Ryosuke - does this mean sw can observe the same? Yoav - yes
  15. Action Item - Ryosuke to open issue on fetch to better clarify what is observable / observing, and to exclude RT and maybe service-workers as well
  16. Ryosuke - normative text is not what we want here
  17. Yoav - is this a blocker for L2? Ryosuke - no, just a spec bug
  1. https://github.com/w3c/resource-timing/issues/160 (from Nicolás - @npm1)
  1. Yoav - this is for h2 connection coalescing
  2. Nic - so dns-start should be earlier? Yoav - yes, non-zero
  3. Yoav - browser has to know if we resolve to same host, to see if we can coalesce, we aren’t reporting that time
  4. Yoav - this should be blocking L3
  5. Ryosuke - this is common enough, deserves non-normative text, tests for this would be tough
  6. Yoav - wpt’s have a new server that might make h2 testing possible
  7. Ryosuke - but dns lookups might not be observable
  8. Yoav - maybe just did dns happen or did it not happen
  9. Yoav - we definitely need more clarification, this could end up as a manual test
  10. Ryosuke - to do this right, wpt would need to implement a name server
  11. Yoav - dns is measurable when it’s not zero
  12. Ryosuke - but you can’t run it a second time! Name server might be caching things, is this truly a blocker for getting L2 out?
  13. Ryosuke - maybe because of the testabiilty issue, we shouldn’t consider this a blocker
  14. Yoav - we need to fix spec language, as a note, try to make it testable
  15. Ryosuke - there is no easy way to automate this testing Yoav - I agree
  16. Conclusion - spec change is blocking, test work is not - ACTION ITEM
  17. Yoav - clearing DNS cache is not cross-platform process

Preload

(Yoav - we have 14 open issues, let’s do them all in 7 minutes! jk)

  1. Issue 127 - https://github.com/w3c/preload/issues/127
  1. TLDR: SRI is not read/honored when it comes to preload requests
  2. Yoav - the browser doesn’t keep around buffers that it needs to calculate integrity of resources, this is in chromium impl
  3. Ryosuke - is this just impl issue?
  4. Yoav / Ryosuke back and forth about chromium impl.
  5. Yoav - ultimate problem is that a script would be downloaded and parsed, even if it wouldn’t have passed SRI ??
  6. Yoav - chromium folks from Japan said fixing this in (some way) would take months and months, recommendation is to included integrity on the LINK node
  7. Ryosuke - what if integrity is not specified?
  8. Yoav - then you get the double-download. The script or style will be the second one, because browser can’t know if integrity of preloaded resource is ok
  9. Yoav - double download doesn’t mean it will hit the network twice, http cache
  10. Yoav - we don’t know what webkit does - Ryosuke - we don’t have this issue in webkit
  11. Ryosuke - maybe we should allow a MAY, such that they can download again
  12. Ryosuke - is ok with asking for integrity being specified on the LINK