- From: Xiaoqian Wu <xiaoqian@w3.org>
- Date: Fri, 5 May 2017 00:34:03 +0800
- To: public-web-perf <public-web-perf@w3.org>
- Message-Id: <AC02158A-E2FA-45FE-B6BF-C807E9305939@w3.org>
Hi all, The minutes of this week’s call are available as: and in a plain text format as below. Next meeting will be on 10 May. Many thanks to our scribe - Yoav. ========= Web Perf WG weekly call 03 May 2017 See also: IRC log Attendees Present plh, yoav, spanicker, Todd, xiaoqian, igrigorik, nicj, cvazac, hurleyzhang Regrets Chair igrigorik Scribe yoav Contents • Topics • TPAC • F2F? • testing • verifying references • Long Tasks • prompt to unload • Summary of Action Items • Summary of Resolutions • adopt a dual spec/testing process for webperf specs TPAC igrigorik: let's tackle administration. TPAC in November. We're there, but not sure on days plh: we're targeting Monday/Tuesday ... No public announcement yet, but there's a Wiki igrigorik: the week of November 6th <plh> https://www.w3.org/2017/11/TPAC/ igrigorik: you're still echoing... ... Are we interested in a F2F? toddreifsteck: I like the idea but want to see a clear agenda before yoav: I can try to get us meeting space at Akamai's SC office around Fluent igrigorik: let's start a doc with ideas we want to discuss ... I'll draft a proposal for an agenda and we can discuss on next meeting spanicker: Last year's F2F was great as preparation for TPAC and made TPAC a lot more productive igrigorik: agreed plh: testing! tests affect how specs are deployed and we need a more agile approach to them ... other groups don't commit anything without a related spec change, and it seems fairly successful ... I think we should adopt such an approach as well because our specs are poorly tested and not necessarily up to date ... doesn't mean a full test suit when writing a doc, but followup commits should be backed up by tests yoav: such a change has short-terms costs, but I agree that the long term benefits outweigh it toddreifsteck: I imagine on each PR, a "do you believe this requires a test update" question. Is that the case? plh: yeah. either provide a test, or a link to an existing test that covers the change already (or a good reason for lack of tests) ... and avoid merging the change before tests exist cvazac: you're flying blind when writing that test code plh: yeah, it's probably shouldn't be a requirement for FPWD, but apply afterwards cvazac: maybe have multiple levels of tests? igrigorik: WPT doesn't support that well. tip of tree is always latest plh: It's ok if some tests fail igrigorik: we have general consensus. Thumbs up? *Thumbs up* igrigorik: since we're talking about testing, there's discussion around verifying references sometimes references to other specs change and there's no infra to verify that there's a current link checker, but verifies that the file exists, but doesn't verify the concept yoav: bikeshed may have solved that problem plh: bikeshed requires a setup. Both are using specref which supports more advanced linking both rely on a DB igrigorik: who maintains the DB? plh: specref have hooks that automatically grab updates in the linked specs <plh> https://github.com/w3c/respec/wiki/data--cite yoav: we cannot rely on published versions of whatwg specs. (e.g. Fetch) plh: not sure how specref updates for non-w3 orgs igrigorik: when linking to editor's drafts and then publish, the TRed version still contains links to editor's drafts ... we need to do more research here spanicker: Google folks are using bikeshed, maybe there's value to consistency igrigorik: not sure that's valuable to rewrite everything to bikeshed, but we can look into that yoav: we can also talk to marcosc and see if respec can somehow solve our issues igrigorik: Next! Long Tasks spanicker: Ran an origin trial, had meetings with partners: Soasta, Google ads and YouTube lessons learned: no major surprises. is this API a good signal for responsiveness? yes. Enables to polyfill TTI and other responsiveness metrics otherwise, youtube found that in many cases they're video playing was blocked behind many short tasks due to browser scheduler problems and even in cases where long tasks were the issue, it was hard to attribute that to specific code spanicker: would be interested to link long tasks with related input events is the API a good signal for 3rd party jank? yes. Google ads were very happy with what it gave, enables them to avoid sending some ads to certain devices soasta were happy with cross-origin iframe attribution script URLs will be good to expose, also particular scripts in cases where there are multiple contexts NicJansma: events blocked by lang tasks would give us a "this task caused user pain" aspect toddreifsteck: it may cause false exclusion of long tasks which presumably don't block events (even if they cause user pain) spanicker: we should keep that in mind toddreifsteck: did you think of the model where we report the full chain of events, tasks and render, like Ben proposed? spanicker: we thought about it, but want to avoid a monolithic API. Long task is one piece. Connecting input to events is another, and the third is detecting slow frames toddreifsteck: and if we ship all three, we can connect them in JS? spanicker: we should make sure they are connectable yoav: and we can later create a higher level API, if needed spanicker: planning to move pieces of v2 into v1 yoav: if no compat issues, makes sense to me spanicker: maybe we can start shipping those parts in a few months igrigorik: can we talk about prompt to unload? toddreifsteck: when testing unload time, alert windows can delay them we can test that using unload and chaining a bunch of windows *specific NavTiming testing discussion ensues* igrigorik: out of time. The next sync in 2 weeks? spanicker: Google I/O! toddreifsteck: maybe sync in a week? igrigorik: WFM! Next sync on May 10th! ========= -xiaoqian > On 2 May 2017, at 7:47 AM, Ilya Grigorik <igrigorik@google.com> wrote: > > Hangout: https://hangouts.google.com/hangouts/_/chromium.org/webperf-wg <https://hangouts.google.com/hangouts/_/chromium.org/webperf-wg> > > WIP agenda for this week's call: > https://docs.google.com/document/d/10dz_7QM5XCNsGeI63R864lF9gFqlqQD37B4q8Q46LMM/edit#heading=h.62162xtkumt2 <https://docs.google.com/document/d/10dz_7QM5XCNsGeI63R864lF9gFqlqQD37B4q8Q46LMM/edit#heading=h.62162xtkumt2> > > If you have other topics you'd like to discuss, please leave a comment on the agenda—the doc is open to everyone.
Received on Thursday, 4 May 2017 16:34:16 UTC