W3C home > Mailing lists > Public > public-web-perf@w3.org > May 2017

Minutes [was: Re: [5/3/17] webperf group call @ 10AM PST]

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


plh, yoav, spanicker, Todd, xiaoqian, igrigorik, nicj, cvazac, hurleyzhang

	• 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

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!



> 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

This archive was generated by hypermail 2.3.1 : Thursday, 4 May 2017 16:34:17 UTC