Re: [12/14/16] webperf group call @ 10AM PST

Minutes of this call: https://www.w3.org/2016/12/14-webperf-minutes.html <https://www.w3.org/2016/12/14-webperf-minutes.html>

Plain text:

WebPerf Group Call

14 Dec 2016

See also: IRC log

Attendees

Present
igrigorik, plh, Todd, Nolan, yoav, xiaoqian
Regrets
Chair
igrigorik
Scribe
plh
Contents

 • Topics
  • RIC
  • Resource Timing
  • Nav timing 2
  • Beacon
  • Preload
  • next meeting
 • Summary of Action Items
 • Summary of Resolutions
RIC

igrigorik: few more issues open
... https://github.com/w3c/requestidlecallback/issues/

todd: I'll take a look at them

igrigorik: we have tests, we have 2 implementations (Ch, Ff)
... so ok to move to CR?

Todd: I didn't have serious look at it
... probably not looking before March

RESOLUTION: RIC to move to CR

igrigorik: I'll follow on intersectionObserver
... should close the 2 remaining issues before we publish the CR

Resource Timing

https://github.com/w3c/resource-timing/pull/83

igrigorik: refining the definition of responseStart for HTTP 1 and HTTP 2

Yoav: for 100 continue, I thought we said the first response to the last request...

igrigorik: you could have a preflight, so first response of the information response

todd: looks good to me
... will probably need some testing. will create a separate issue

igrigorik: ok. won't apply to L1. ie L2 and up.

<xiaoqian> https://www.w3.org/2016/04/RT-testing/single-entry-per-resource.htm
Plh: for L1, we're good to go otherwise to move PR I think

https://w3c.github.io/test-results/resource-timing/all.html

xiaoqian: didn't get test results for Safari yet

Yoav: might be possible to get some.

https://w3c.github.io/test-results/resource-timing/less-than-2.html

<yoav> https://github.com/w3c/web-platform-tests/pull/2919
Yoav: this test is relying on onload

Plh: I'll fix that up

RESOLUTION: wrap this up and send to PR

RT L2

igrigorik: we have a few issues, pull requests for tests
... can we close the old pull request from plh?

xiaoqian: what about the tests we no longer need?

todd: we have a pull request where you've done some work

Plh: +1 to close it down

igrigorik: so, this clear out our queue
... some missing stuff for Ff but close to have 2 implementations
... ok to move to CR?

RESOLUTION: RT L2 moves to CR

Nav timing 2

<igrigorik> Tests: https://github.com/w3c/web-platform-tests/pull/4262
Todd: this is not a blocker but we have some edge cases to test

yoav: I reviewed the document related to the tests
... bunch of things that need to be included

igrigorik: probably would need a separate bug
... yoav, review the current PR and merge if you're ok with it
... we need for TAO
... https://github.com/w3c/navigation-timing/issues/58
... we'll repurpose this one to make it general for all tests

<igrigorik> https://github.com/w3c/navigation-timing/issues/50
igrigorik: what happens if the page doesn't load?

Nick: we want to know when requests are initiated
... part of our attempt to come up with metrics for single page apps
... "in-page navigation"
... we need to be aware on all networking activities
... we can't know if there is something outstanding on the network
... early, we talked about fetch observers...

igrigorik: there is a need for them, but it's related to #50...

Nick: we'd like to get incremental updates, intermediate timestamps

igrigorik: nav timing expose the same record and you can just query it
... one argument was to have one entry per timestamp....
... or emit the record when it's created and update that entry

Nick: but it's a polling mechanism...

Todd: maybe we can deliver the partial record early and then again at onload
... delivering the same record multiple times isn't a bad thing necessarily

Plh: or attach an update event to the record?

Nick: would still need to deliver the record at onload in any case

igrigorik: feels like there is a couple of different solutions. we're bouncing around a larger problem
... let's follow on the list
... my understanding is that it's problematic not to resolve that for NT L2

Todd: Edge adds the nav entry at the start of the navigation

igrigorik: interesting

Todd: this became an issue for performance observers

Beacon

igrigorik: the PR is fine but missing tests
... I'll look into it

Preload

igrigorik: we've got tests from Yoav

yoav: please review. translated from Blink and complemented by unit tests
... let me know if anything is broken

igrigorik: I made a few comments
... for the missing ones, open new bugs

yoav: ok
... one issue is removal of href, rel, or link preload itself
... I opened an issue for that

igrigorik: I assert that the html spec already covers it

yoav: only when added, not when it's removed

igrigorik: we can't say MUST, because browsers are browsers
... so, SHOULD, ABLE TO, ...

yoav: but then it's not a proper test...

Plh: please check with the WPT folks

igrigorik: 'as' is started to get used
... but it gets misused

yoav: a missing 'as' is an empty fetch destination
... so we only connect it to XHR or fetches
... or anything to SRC directive
... but people finds it confusing
... they double it down as a consequence and triggered refetching
... [missed]

igrigorik: the whole concept of destination is new and requires nuanced understanding of the security model
... maybe we can just fire console errors

yoav: the console warning is emitted 3 seconds after onload once that resource remains unused

igrigorik: devs are not aware of 'as' and makes mistake, we issue warning. we could require the attribute but that would be unique

[some back and forth on the default behavior of as]

yoav: can we poll the usage out there to see what's better?

igrigorik: ok, we'll continue the discussion on github. I'd like to get Anne or Domenic opinions as well

next meeting

[by email]

[adjourned]

Summary of Action Items

Summary of Resolutions

 • RIC to move to CR
 • wrap this up and send to PR
 • RT L2 moves to CR
[End of minutes]

> On 14 Dec 2016, at 5:04 PM, Yoav Weiss <yoav@yoav.ws> wrote:
> 
> Another one on Preload:
> Define resource abortion when link element or `rel` are removed - https://github.com/w3c/preload/issues/82 <https://github.com/w3c/preload/issues/82>
> On Wed, Dec 14, 2016 at 12:49 AM Ilya Grigorik <igrigorik@google.com <mailto:igrigorik@google.com>> wrote:
> Hangout: https://hangouts.google.com/hangouts/_/chromium.org/webperf-wg <https://hangouts.google.com/hangouts/_/chromium.org/webperf-wg>
> 
> --- Agenda:
> requestIdleCallback
> Review: https://github.com/w3c/requestidlecallback/pull/50 <https://github.com/w3c/requestidlecallback/pull/50>
> Next steps to push to CR? <https://github.com/w3c/requestidlecallback/issues/48>
> Resource Timing L2
> Review: clarify responseStart
> https://github.com/w3c/resource-timing/pull/83 <https://github.com/w3c/resource-timing/pull/83>
> Review WPT tests
> https://github.com/w3c/web-platform-tests/pull/2919 <https://github.com/w3c/web-platform-tests/pull/2919>
> https://github.com/w3c/web-platform-tests/pull/402 <https://github.com/w3c/web-platform-tests/pull/402>
> Can we close this one, now that https://github.com/w3c/web-platform-tests/pull/4266 <https://github.com/w3c/web-platform-tests/pull/4266> has landed?
> Next steps to push to CR <https://github.com/w3c/resource-timing/issues/82>?
> Navigation Timing L2
> Review tests PR: https://github.com/w3c/navigation-timing/issues/49 <https://github.com/w3c/navigation-timing/issues/49>
> Discuss https://github.com/w3c/navigation-timing/issues/50 <https://github.com/w3c/navigation-timing/issues/50>
> Note: NT2 now available behind experimental flag in Chrome
> Beacon
> Review next steps on: https://github.com/w3c/beacon/pull/39 <https://github.com/w3c/beacon/pull/39>
> Next steps to push to CR? <https://github.com/w3c/beacon/issues/36>
> Preload
> Require "as" attribute: https://github.com/w3c/preload/issues/80 <https://github.com/w3c/preload/issues/80>
> Review WPT tests: https://github.com/w3c/web-platform-tests/pull/4316 <https://github.com/w3c/web-platform-tests/pull/4316>