- From: Yoav Weiss <yoav@yoav.ws>
- Date: Fri, 21 Sep 2018 07:22:23 +0200
- To: public-web-perf <public-web-perf@w3.org>
- Cc: Ilya Grigorik <igrigorik@google.com>, Todd Reifsteck <toddreif@microsoft.com>
- Message-ID: <CACj=BEiZKrDjCuFuCx9aUv9JkqGwLB3qzYqAJEmJGUg=0q_KSw@mail.gmail.com>
Minutes from the call are now available <https://docs.google.com/document/d/e/2PACX-1vTeWnJPdL3FuSDgdab-ZO1yRrdj8oIqRMUPYQubVm-oJWPEjLJm4djxv9Tnkn7nIdwBiWqo-HEFq7j8/pub> . Copied here for safe-keeping: WebPerfWG - Triage call Sep 20th 2018 - minutes 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 <https://www.google.com/url?q=https://www.w3.org/2004/01/pp-impl/45211/join&sa=D&ust=1537510756793000> . Resource Timing 1. https://github.com/w3c/resource-timing/pull/163 <https://www.google.com/url?q=https://github.com/w3c/resource-timing/pull/163&sa=D&ust=1537510756793000> 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 <https://www.google.com/url?q=https://github.com/w3c/resource-timing/issues/164&sa=D&ust=1537510756795000> 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 <https://www.google.com/url?q=https://www.stevesouders.com/blog/2014/11/25/serious-confusion-with-resource-timing/&sa=D&ust=1537510756796000> 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 <https://www.google.com/url?q=https://github.com/w3c/resource-timing/issues/161&sa=D&ust=1537510756797000> (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 <https://www.google.com/url?q=https://github.com/w3c/resource-timing/issues/160&sa=D&ust=1537510756799000> (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 <https://www.google.com/url?q=https://github.com/w3c/preload/issues/127&sa=D&ust=1537510756801000> 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 Published by Google Drive <https://docs.google.com/a/yoav.ws/>–Report Abuse <https://docs.google.com/a/yoav.ws/abuse?id=e/2PACX-1vTeWnJPdL3FuSDgdab-ZO1yRrdj8oIqRMUPYQubVm-oJWPEjLJm4djxv9Tnkn7nIdwBiWqo-HEFq7j8> –Updated automatically every 5 minutes On Wed, Sep 19, 2018 at 9:40 AM Yoav Weiss <yoav@yoav.ws> wrote: > Hey all, > > As discussed on the last call, let's talk this Thursday about the various > issues needs triaging and resolving. > > Tentative agenda > <https://docs.google.com/document/d/10dz_7QM5XCNsGeI63R864lF9gFqlqQD37B4q8Q46LMM/edit?usp=sharing> > : > > - > > Preload > - > > 14 open issues <https://github.com/w3c/preload/issues> > - > > 2 shipping implementations (but tests don’t look good) > - > > Resource Timing > - > > PR - fire resourcetimingbufferfull async > <https://github.com/w3c/resource-timing/pull/163> > - > > Untriages issues > - > > https://github.com/w3c/resource-timing/issues/164 > - > > https://github.com/w3c/resource-timing/issues/161 > - > > https://github.com/w3c/resource-timing/issues/160 > - > > ??? > > > Please let me know if there's any other issues you'd like to discuss. > > See you on the call! :) > Yoav > >
Received on Friday, 21 September 2018 05:23:02 UTC