Web Performance Working Group Face-to-face

26-27 October 2015

Sapporo, Hokkaido, Japan

See also: agenda, IRC day 1 log, IRC day 2 log


First Day: Yoav, plh, Ilya, Todd, Ryosuke Niwa, Alex Russell (afternoon), Xiaoqian Wu (afternoon), Bartek Kozlowski, Mark Nottingham (morning)
Second Day: Yoav, plh, Ilya, Todd, Xiaoqian Wu, Nick Doty (morning), Bartek Kozlowski (morning)
Ilya & Todd
Yoav, plh, Xiaoqian

First Day

10,000 feet view of Web Performance deliverables

Ilya: 10,000 feet view of WebPerfWG

Overview of Performance timeline
Web Performance Monitoring Overview

High Resolution Time is the foundation of the WebPerf APIs

we recently made sure that it works well with both window and worker

Ilya: translateTime recently added to HRT

Ilya: we also have a problem with people finding the old version of HRT rather than the new one
... The next big chunk is performance timeline
... PerformanceObserver was added. It enables to subscribe to notifications about various metrics
... ResourceTiming: pretty simple and not many recent updates
... Navigation Timing is being refactored to be based on resource timing
... There are fetches that are multiple fetches under the hood, and we need to figure out a way to un-mush that

todd: We need to figure out a way to so that securely

Ilya: user timing, some cleanups but no major changes
... Server-timing - no implimentations today

todd: the main blocker there is trailer headers

Ilya: without trailers a lot of the use cases are lost

mnot: there is pushback about supporting trailers in browsers

Ilya: we could just expose certain headers (e.g. server timing) there, and not generic support for exerything

todd: ServerTiming can be done, but would be more interesting with trailers

Ilya: server timing spec has been stable for a while, but we could convert it to performance observer

todd: Agreed, but we'd need to be able to define it for the navigation request

Ilya: as long as you register the perfObserver early, you could do that

todd: would be great if there was a declarative way to do that

Ilya: FrameTiming: recently changed so that frameTiming only measured frames that exceeded their budget

The whole spec addressed a big gap that we have regarding measuring run time

Ryosuke: when we looked at frame timing, it didn't make much sense.

todd: the recent spec matches RAF much more closely, and the compositor references are now gone

Ryosuke: intersection observer could have also be used to measure something like that

Overview of Fetch optimization and reporting APIs
Web Performance fetch optimization/reporting and rendering APIs Overview

Ilya: Beacon API currently based on fetch. couple of open issues

we need to send different payloads, which may trigger CORS preflights and questions RE credentials

preload - we'd done a few loop around the track on how to determine priority. It's been addressed with hooks into fetch. Exposed as the `as` attribute

Ilya: originally, preload was part of resource hints, but now it's split into its own spec, since is has mandatory semantics

Resource hints - preconnect is shipped, and used by some Google properties

dns-prefetch, prefetch, prerender mostly retro-speccing the implemented bits

Ilya: prefetch and prerender are highly heuristic, and hard to predict as a developer when they'd kick off
... in the spec we talk about downgrading resource hints, but it doesn't look like any of the implementations do that

todd: What we've seen with internal properties, it takes them a lot of time to experiement and figure these hints out

Ryosuke: maybe developer tools could help us there

bartek: Would it be possible for regular developers which parts of the draft are implemented and shipped?

Ilya: plh has a implementation document

NEL - no current implementation in Chrome, Firefox are looking into it

Ilya: Working with Mike West on a reporting API, so that we can report NEL, CSP, HSTS and everything else

bartek: Would be interesting to have that info in DNS headers

so that the browser can know what the reporting URL is

Ilya: so once the reporting API would be in place, we'd reactor NEL based on that

requestIdleCallback - used to run some code at idle time so that it won't get in the way

todd: Page Visibility enables developers to know if the current tab is visible

there was some dicussion about out-of-view iframes, but we didn't move forward with that

todd: one last item is CPU and memory monitoring, but it can be tricky for security reasons

Ilya: we've been talking in Chrome about killing the onunload event

on mobile you should listen to page visibility rather than onunload

Ilya: and since it's broken in many browsers, we could just remove it, since devs can't rely on it

todd: this also means that the page visibility API may rise in importance

plh: we can add a section to the spec to talk about that

Ryosuke: when the users switch a task, focus and blur is changed, and currently not specified anywhere

Ilya: might be specified in the HTML spec, but not implemented in a consistent way

Yoav: how about visibility metrics? need paint observers?

Ryosuke: interested as well. we don't know what's important for each page

Other items discussed: Declarative way to improve first paint and prevent CSS blocking

Ilya: profiler API would be interesting

todd: it'd be interesting to expose how well the Web page performs on the machine it's working on

Ilya: There's a proposal for interventions in Chrome, so that the browser can break the API contracts in some cases, in order to improve the user experience

part of that is signaling to the origin that the intervention took place

which loops back to the reporting API

we could observe the lifecycle of the page and at the end send back a report

Ryosuke: it's usually more interesting to have aggregate data

Ilya: that depends. In some cases that's true, and in some cases it's interesting to have granular data

yoav: in terms of out-of-band reporting, it might be interesting to expose that to users eventually

HR timing 2: ready to ship?

plh: What do we do with the spec? there are no implementations of translateTime

Ilya: it can be polyfilled

plh: who is exposing performance.now in workers?

Ilya: Chrome is

todd: workerStart is tied to service worker, where translateTime is realted to workers in general

plh: Should we not ship translateTime in the spec?

todd: we could publish without translateTime, and then publish translateTime in the next release

plh: so we just need to make sure we have a test that tests the worker support
... so the goal is to push HR time 2 to REC, but without translateTime.

*Discussion about https://github.com/w3c/hr-time/pull/14

The term <dfn>current document</dfn> refers to the document associated with the Window object's newest Document object


The term <dfn>current document</dfn> refers to the Window object's newest Document object

Everyone: Let's just add a note referring to the bug on HTML

todd: second issue https://github.com/w3c/hr-time/issues/15

this will be resolved once we'd publish the new spec

plh: Need to do the "great renaming" where the old spec changes urls
... Also, we can push current spec to CR with translateTime "at risk" so that we can later add it in once implementations catch up

Do the great renaming on Web Perf /TR shortnames

HRT2 snapshot moves forward without translateTime

Performance Timeline: buffer or not?

plh: the biggest issue is from resource timing and navigation timing
... in both we have "clear" which when based on PerfTimeline does nothing. I wrote a pseudo polyfill on the plane
... But if we only register perfObserver at the head of HTML, you're racing and might miss some resources

todd: For frame timing, it's defined as not injecting to the timeline, but only emits performanceObserver

Ilya: We agree that all API should be based on PerformanceObserver. I think that some APIs don't need a buffer in addition to that

but in some cases, we need a buffer - especially for resource timing and keeping track of resources that may finish loading before perfObserver registration is done

todd: perhaps the way to get perfObserver on everything is to have an initial buffer, and then the first event grabs everything from that buffer and onto PerfObserver

plh: I don't think we can change getEntries() because they are heavily used

It would be interesting to polyfill them using perfObserver

todd: that makes sense.

*discussion about eliminating buffers entirely, getting an initial buffer in place, etc

plh: if we could remove the setResourceTiming size, it'd make it easier to just define a start buffer

Ilya: we could also limit buffering up until the onload event

so that users in their registration would read the buffer and then start observing from that point on

yoav: there's some race condition here if users read first and register later

plh: yeah, but if they register first, we're all good

Ryosuke: it'd much nicer to have a flag so that when you register the observer, you get all the past entries as well

todd: so that browsers that haven't implemented getEntries() (Safari/WebKit) never have to buffer after onload

plh: do we even need the flag?

Ryosuke: it makes sense for the default to be to get all the past entries
... it might be nice to be able to filter what you want recording

todd: currently you're getting an array and you can filter it

Ryosuke: in MutationObservers you can listen to a single node. It would be nice to filter based on a single resource

Ilya: Alex Russel also wants to be able to query the img resource related to a single DOM element

todd: We can tell with initiator type, but not everything

yoav: how would that data be useful? If you have multiple elements referring a resource, it's still a single entry for a single fetch

Ryosuke: anyway, it would be nice to be able to filter based on an element

todd: we can filter by name

plh: but we don't allow filtering by name on perfObserver

Ilya: It's a list, and devs can just ".filter" on it

plh: getEntriesByType("resource") was added so that you don't need to create the JS types for anything that won't go into the JS list

todd: That's not necessarily a concern today

Ilya: Nat Duca supported adding the GetEntriesBy* when we were talking about thousands of entries

for a smaller number, it might not make sense

todd: we see 3 getEntries() for every 2 getEntriesByType() for 0 getEntriesByName()

plh: We can't remove these methods, but we can move them to a historical section

todd: We should wait with deprecation until we have a replacement specced and shipped in enough browsers

plh: so let's promote perfObserver in a way that could one day used to replace getEntries*

Ilya: so let's imagine we only had perfObserver. We could tell developers to add a shim that emulates getEntries*

* Discussion on Performance Observer and {how/if} we can obsolete the getEntries* methods

* Overall discussion tends to get rid of getEntries* from perfObserver

todd: FrameTiming was defined to not buffer, but maybe in the initial buffer model we want to buffer it

Ilya: so until onload we buffer anything. We can also have some opt-in to only buffer certain types.

Ryosuke: buffering is not expensive, but measuring can be expensive so an opt-in would be useful

Ilya: FWIW, today RT and NT already measure and it works fine without huge overhead

todd: Let's separate frame timing from perfObserver for the moment and discuss that separately

Ilya: so to keep things simple, the buffer buffers everything up until onload
... to complicate things further, fetch registry might also add resource timing that is unbound

todd: that's an issue for the fetch spec to deal with

for our purposes, the "up to onload" buffer can probably be bound to 500

* Discussion about some opt-in for PerfObserver

discussion on perfObserver's buffer queueing logic

Define getEntries/clear* using the proposed polyfill


whiteboard screenshot
Brainstorming on how to eliminate performance.getEntries in the future

Memory API: any idea?

Memory info API thoughts from Ilya

Ilya: different implementations can report different things, developers might micro-optimize to implementation details

under-reporting browsers would look better

* Going over use-cases from the doc

two distinct use cases:

regression detection - seeing if your app memory usage increases over time

adaptation - serving a different, lighter version of your site to devices that cannot deal with the full version

todd: How would we register to getting memory reports?

plh: could be a performance entry

Ilya: proposal is just to get an event with a performance entry with heap size and an "underPressure" boolean
... should we add other metrics? canvas size, media buffers (if we're willing to expose it)

an underPressure event would be a signal to the app that some of their users are under memory pressure in the wild

plh: the goal is to allow the application to send a beacon up

todd: and to turn things off

another goal is to be able to send up memory increases so that apps can keep an eye on memory increases

Ilya: Another case is getting crash reports

yoav: we also need a way to detect low-end devices relatively up-front so that Web sites can load light versions of their sites for devices that can't handle more than that

plh: there would be privacy issues with exact numbers

Ryosuke: we could clip the numbers to the hundreds of MBs to avoid privacy concerns

whiteboard screenshot
Brainstorming on Memory API functionalities

Intersection Observer

Alex Russell: the proposal comes from traces of 3rd party content, what making Web sites slow, battery use & jank

A lot comes from third party that try to see where things are on screen

use cases:

dealy loading of content, with scroll events

analytics and ads networks

(forcing sync layout every 100ms or so)

the bad version of that creates plugins that measures things inside the viewport

IntersectionObserver lets you know how if an element that you care about hits the viewport

that answers this use case, plus enables lazy loading

It can report the top level viewport, or to report when the observed element overlaps another element

The information is async delivered and you might miss a thread or two

because multi-threading is hard

so you set an observer on an element and get notified when that element enters the viewport

with that you can meet the ad network guidelines, so ads can implement their thing using that

plh: Would that API be able to tell you if an element is visible?

Alex Russell: Only to an approximation

plh: iframes?

Alex Russell: There's a good chance that this would give you that

it can't cover if an element was hidden by a different element

Alex Russell: time is relative to the generator which may be the compositor

there can be some skew

Ilya: about privacy and timing attack

Ryosuke: if it's async, there's no risk for timing attack

Alex Russell: about approximation of meaningful paint, the first intersection observer may more or less correlate with the meaningful first paint

there can be delay between layout and paint in some browsers. Also images that are painted to a viewport element won't be visible to that API

Ryosuke: we could also have elements that are in the viewport but never painted due to fast scrolling
... The real metric people want is when things got painted

Alex Russell: That's a metric that we can add. File an issue on the repo

Ryosuke: It would be great to correlate that info with frame timing in order to figure out which elements trigger jank

Alex Russell: the times are not correlated

Ilya: the important thing is that you should be able to translate between that time and the current document time.

todd: We've had some push back for Page Visibility 2 on iframe visibility, but now with IntersectionObserver, maybe there's a chance to get that

Ryosuke: So the idea is the attach intersection observers to iframes if the user attached to the iframe's page visibility?

maybe, even if the async nature is making this harder

let's wait for intersection observer to be a thing before making decisions on that

TAG Review of nav-timing

Navigation Timing 2 Feedback

Alex Russell: some things are weirdly split between resource timing and navigation timing

It seems odd that there's no way to get from an element to the relevant timing. It's hard to tie the DOM and the timing back together

if there's evidence that this is something people do, it'd be good to add that back to the platform

Ryosuke: it would be nice to get a timing back from an element

todd: the theory is that most analytics poll the timeline regularly, so that instead of timers, PerfObservers would enable to receive events as they arrive

Alex Russell: they poll frequently in order to avoid data loss

Ilya: it's both. You need to observe when things have changed. Then, if you delay it too long, you may lose it
... one more issue is about resources that send more than one request: preflights, redirects

we can probably unbundle that

Alex Russell: so will the APIs continue to evolve or are they done

Ilya: they'd continue to evolve in small ways, but most of the data is there

Ryosuke: could we agregate the data?

Ilya: there are several agregation implementation out there, but they're all different so there's no single way we'd want to stardize

todd: getEntriesByType(navigation) is not implemented in Firefox and Chrome

Alex Russell: Regarding attribution, it would be significantly easier to be able to get the element(s) back from the timing entries

the list of elements could be populated at query time

todd: It's interesting to look into the use cases and see if we can limit the attribution to resources that would satisfy the use-cases

Alex Russell: it may also be interesting to attribute download initiation to other resources/timing/elements

<Ilya> http://www.webpagetest.org/breakdownTimeline.php?test=151026_HS_DQ1&run=2&cached=0

* Discussion about an API that would expose what the main thread have been doing for RUM

it's possible that just decorating frame timing with that data would be enough to get that data in the hands of users

Ryosuke: also, it's possible that GC time and layout times can be cheaply measured and exposed

exposing layout time can expose timing events if you wouldn't limit precision

todd: system profiling api is interesting, but we don't have conclusive data that it's needed

Ilya: Let's add some of this to frame timing, and then see

Second Day

Frame timing

yoav: I believe Intersection observer will help answer my RUM use cases
... still need to talk to David Baron about :visited

Ilya: looking at implementation feedback

Todd: new proposal needs to be circulated within MS
... current proposal seems acceptable

Ilya: google and firefox did implementations of the first proposal

<plh> ACTION: plh to clean up frame timing [recorded in http://www.w3.org/2015/10/26-webperf-minutes.html#action01]

<trackbot> Created ACTION-166 - Clean up frame timing [on Philippe Le Hégaret - due 2015-11-03].

Page Visibility

<plh> https://github.com/w3c/page-visibility/pull/16

Todd: you could merge the PR for the time being while still figuring if we got the right task source
... do we have tests for PV?
... our interop is weak when you include life cycles

Ilya: firefox fires a transition from visible to hidden when the page is being unloaded

plh: we need a test for prerender

<plh> ACTION: plh to look into testing prerender in Page Visibility [recorded in http://www.w3.org/2015/10/26-webperf-minutes.html#action02]

<trackbot> Created ACTION-167 - Look into testing prerender in page visibility [on Philippe Le Hégaret - due 2015-11-03].

Ilya: in FF, they fire hidden hidden in all cases

Ilya: I don't think we need to transition when it's unloaded
... we could tell devs that they should always listen to visibility events, ie background transition or close tabs
... but that's handle by pagehide
... ie we could use a combination of visitibilityState and pagehide

<plh> https://github.com/w3c/page-visibility/issues/18

Ilya: no explicit definition of when the page is unloaded
... with the new update

speculation that an example in the spec might have lead to hidden being true while a tab is being unloaded in some implementations

<plh> [discussion regarding differences between pagehide and unload]

Resolved: publish page visbility as a Working Draft

<plh> ACTION: plh to publish PV2 [recorded in http://www.w3.org/2015/10/26-webperf-minutes.html#action03]

<trackbot> Created ACTION-168 - Publish pv2 [on Philippe Le Hégaret - due 2015-11-03].


Ilya: implemented in blink. needs to get it shipped and align in the spec.
... need to talk to the webkit folks
... push and preload don't connect but there are some use cases for preload that can be resolved with push
... http://www.w3.org/TR/preload/#issue-1
... we need to define the caching more formaly
... there is magic there
... we retain the page for the navigation session if no cache is requested
... if preload is activated
... fetch needs tobe aware since the subsequent fetch will need to take it into account

yoav: in terms of interop, do prefetch live for the duration of the next navigation?

Todd: we don't do preload and preconnect yet

Ilya: for preload, it's a declarative fetch, so I don't think we're exposing anything special here in terms of security and privacy

yoav: depending on the cross origin attribute and the as, we would send credentials

Ilya: if I do a preload with as image, no credentials. if I add crossorigin, we'll add them

plh: maybe we should say that preload is equivalent to adding an image

nick: can we list what it means to be equivalent?

plh: we would be duplicating other specs by doing so.
... not the right approach imho

yoav: the only difference here is that these fetch don't block and can start early
... header based csp are taking into account

Ilya: we don't say that we process the csp headers are processed atomically

<plh> http://www.w3.org/TR/resource-hints/#security-and-privacy

yoav: csp can prevent from the preload to happen
... csp is about protecting the html, not the link headers

Ilya: if you start touse link headers, you should move the csp into link headers as well

Ilya: fetch was updated to add a check at the exit
... the ordering of link/meta between preload and csp isn't relevant. the implementation may do preemptive fetch on preload and have to discard it because of csp
... the question here because the impact on caching

Beacon: Security and Privacy

Ilya: step 10 of processing model
... the mode is "CORS"
... it means the origin you send the request must respond with two headers
... ... we don't care about the response
... we should change it not to use "CORS"
... we need to check that we're not breaking anything
... otherwise we're forcing the origin to respond with dynamic headers

Todd: indeed, it's unecessary
... for the spec, you would preflight and not send the POST

Ilya: there could be a beacon-age
... that nobody implements
... but it would force a preflight
... it also depends on the content type
... a blob would trigger a preflight

nick: form submission implies no new headers
... so due to beacon-age and content type, we're increasing the potential attack area
... servers have to accomodate POST request from crossorigin that look like post submission
... but if you get things that aren't like post submission, that's different

yoav: I've never seen crf protection as a strick headers check

nick: the conditions we have in cors. we're changing the assumption on form submissions.

yoav: can we include the beacon age in the data?

plh: no because we allow abitrary post

Todd: if we remove beacon-age and restrict to form-data, we are the same as forms

nick: it wouldn't create new attack surfaces indeed

plh: are we llike xhr then?

yoav: no, because of cors

nick: you could force cors, ie preflight request

Todd: can we make it beacon age a simple header?

nick: user agents dont preflight in case of new headers
... (according to Jonas)

Ilya: we should clarify beacon-age with respect with user agents added headers
... are user agent addefd headers treated simple headers

<plh> (that's issue 1)

Todd: should we only send form-data , even if it's a blob?

nick: that seems confusing

Ilya: I don't think we have telemetry on media type usage for beacon
... half the time, people just send a uri
... the whole payload thing isn't used

Todd: folks with more advanced payload are probably sending json

Ilya: the fetch spec doesn't do anything smart with json object

Todd: ie you're responsible for the serilization and then fetch send a string

Ilya: correct

nick: if you send a different content type, you culd incurred the preflight

Todd: cost is non-trivial

Ilya: current implementation aren't doing preflight
... if type comes from a blob

plh: so we're breaking CORS and fetch specs then

yoav: I understand when you don't arbitrary headers, but the mime types...
... I think the restriction on mime types is uncessary

plh: we should stop by the webapp secs
... and talk about this over with them

<plh> [Todd is updating https://github.com/w3c/beacon/issues/10 ]

nick: https://github.com/w3c/beacon/issues/9

nick: "This specification defines an interoperable means for site developers to asynchronously transfer small HTTP data from the User Agent to a web server."
... doesn't say what the spec does

editorial comments in this email: https://lists.w3.org/Archives/Public/public-web-perf/2014Jul/0109.html

not small and "asynchronous" doesn't quite capture what the spec is about

nick: separate privacy considerations from security considerations
... privacy concern is the browser making a request on you behalf after you closed the page
... are the users going to be aware of that?
... similar geofencing
... you might have a different IP adress
... we had a discussion about this in web platform yesterday but no conclusion
... at the very least, we should mention it in the privacy section

Ilya: we don't want to block on unload
.... ie avoid sync XHR
... you can use beacon to send things every 2 hours

Todd: with beacon-age, you have the ability to send it much later
... but no one implements it

nick: we need some guidances to implementrs on what to tell the users when sending a quest after the close

yoav: how is that different from background syncs in service workers?

nick: same issue :)

Todd: it may be simplier to spec it down for the short term

Ilya: agents could pile up beacons to wait for the next network request

Ilya: perharps we should more clearly define beacon-age?
... what are the use cases for beacon age?

nick: the processing model speaks about multiple attempts

Todd: but with service workers, it seems handled now

plh: at the minimum, we should say it's sent after the close

nick: even if we say it's equivalent to an existing practice, it would affect users

nick: do UAs have the option to desactivate beacon?

plh: no, like we don't have the option to desactivate XHR. Beacon is generic, not restricted to telemetry data

Ilya: we limit body size in chrome

nick: if it's only used for telemetry, what do you do in private mode?
... you might want to add a note in privacy sectio that you considered the case of giving the user the ability to desactivate beacons and decided against it.
... I'm not sure you want to say that the user can't have the ability to deactivate it, just because it's obviously true that user agents can turn off beacon functionality or do whatever the user wants
... but you could explain why you're not putting conditions on when Beacon is used, because you think there is an advantage to users on the whole

Ilya: btw, our size limit is 64Kb

(Beacon needs more work on Blob and preflight/cors)

Network Error Logging

looking at the open issues

ilya: how are the NEL requests treated? client requests?
... NEL. you as an origin have registered to receive error reports
... some site embeds your widget, and you want to know when your social media widget has failed to load
... but if the embedding site has a service worker that intercepts requests
... the service worker might pass through the request, which might fail
... the report shouldn't be sent to the embedding site owner, but to the widget owner
... any other report should be treated as client requests which bypass service workers

todd: should we go over network error logging in more detail?

ilya: lots of things could go wrong: DNS failures, route issues, etc. you as a site owner have no way to observe that this failure happened
... large vendors have nodes around the world that will ping their site to try to identify these failures and work around them
... NEL is supposed to notify you that we have failed to reach your site
... specify a report-uri on a first successful reach, the report-uri should be a different domain, on a different subnet, etc.

Bartek: would be good to have more than one endpoint

ilya: yes, we do support that, with fallback through the list
... modified after HSTS, can note that it applies to all subdomains as well
... a well-structured report of failure, including the resolving IP address

Bartek: have a list of items in notes that I would like in addition

todd: would be great to have those as Github issues

ilya: are the errors that we define here reasonable?
... this is restricted to HTTPS origins, and the report location must also be HTTPS

[note, "trustworthy origins" is out of date terminology]

ilya: noticed that we have multiple places in the Web platform that are delivering reports
... would like to extract that into one common thing, a group of report uris
... then other specs can reference this to say, "queue a report to group Security"

todd: privacy questions regarding these general out of band reporting mechanisms?

Nick Doty: sure, it was debated regarding csp, for example

plh: we could say for this spec, the user agent should provide a way to disable NEL
... worth it to mention in the NEL spec that user agents should provide a way to disable NEL reports
... question about whether SHOULD or MAY

ilya: the out of band reporting just has general restrictions, like clearing the cache
... but for particular specs that have reporting, they should specify when to send requests, when they might not want to
... the general out of band reporting is just under mkwest's repo for now

Bartek: what if we have reporting list not as a fallback, but simultaneous to more endpoints for auditing purposes?

ilya: could you do that yourself?

Bartek: you could, and it would be more efficient, but auditors might want independent reports
... for example, if ads are served from within our origin

ilya: the fact that the user agent delivers it doesn't make it provably, just a convenience
... wouldn't want to open it up to a very large list

Bartek: potentially lack of trust between parties

todd: if there are particular regulatory requirements, that might make it easier
... what if we had a concrete number: 2 or 3

Nick Doty: can we provide the assumption that error reporting uri's should be common across users? if so, it would make it easier to detect abuse for supercookies

ilya: there are use cases where you would want the value to differ, between regions, for example

Bartek: could also have the report-uri in the DNS record (as a TXT record, say)
... as a fallback if you never successfully reached the server

ilya: interesting, please raise

todd: could ship with a pre-loaded list in browsers, like with HSTS pre-load list

Bartek: dns should be considered as a fallback, just in case you can't load the policy on first load

[humorous tangent about how much policy can be pushed into DNS records]

ilya: don't typically load all DNS TXT records

Nick Doty: but would only need to when you had a network failure
... DNS doesn't give you the security of HTTPS

ilya: yeah, so DNSSEC?
... some information is reported that others wouldn't have received


<xiaoqian> primer -> http://siusin.github.io/perf-timing-primer/

<Ilya> Andy's waterfall repo: https://github.com/andydavies/waterfall

<Ilya> https://github.com/addyosmani/timing.js/

plh: should we use perf observers in examples?

Ilya: let's rule that we need at least one shipping implementation before we use those in the primer

Xiaoqian: should I list/describe every attribute for entries?

plh: nope. goal is intro here. folks should look at specs for list/description

For the Primer: update graphics, add links to caniuse, add link to timing.js, add one sentence or two on frame timing and server timing, then ship


Ilya: how about we allow apps to add their own performance entry objects in the timeline so that one can observe those?

Todd: that would allow the use case of adding your own payload to an entry
... sounds cool
... and it cleans up the story around clear*

plh: we should open an issue/feature request

Ilya: I'll open one

<Ilya> https://github.com/w3c/user-timing/issues/3

Ilya: but it means we would allow huge payload into the observers and those are doing deep clones...

Todd: that's actually a diff between Edge and Chrome/FF in getEntries*. Edge does a deep clone before returning the entries, others don't.

Navigation/Resource Timing: How to expose HTTP redirects?

Ilya: besides security/privacy, what's the hold?

Todd: not a high priority

Ilya: we already reveal the fact that there was at least on redirect (since we return 0)
... but we don't say how many

plh: is this what you meant? -> //TAO only Redirect Timing{ URL }

Ilya: Not exactly.

yoav: just the entries

plh: Resource Timing{
... redirectCount;
... redirect URL
... }

... if I have two with the same name

yoav: you can link everything back together
... If you go to HTTP server, we can expose it
... expose Redirect there will be a concern

todd: you couldn't make guess

plh: change 2 attrs only, redirectend and redirect start

Ilya: yeah, drop them

todd: you are also missing info about the chain

yoav: if redirect, you can change your cookie

plh: if I have a redirect in the middle

Ilya: it will take longer

plh: I won’t get url in the end, so I won’t expose that

yoav: you can measure the time you took
... if you want to avoid this expose privacy problem, you will have to remove from a lot html

todd: that’s why we hide a lot of redirects
... image people are choosing to expose, can we add the feature?
... if a website choose redirect as feature...
... can you get the data? with xhr?

Yoav: if you site tell you to expose, redirects maybe the same pattern
... TAO is already used today

Todd: Google phone has already turn TAO on

Yoav: If FB has no interest to expose TAO

Ilya: their widget do

Yoav: if we review all the redirect there, will it be private proper?
... let bring it to the Security folks

todd: strange to turn it on... go to log in server, use cookie, user redirect just not enough

Ilya: this question is a block of a lot of others
... privacy issue will be a major change to the API

todd: I'd not recommend change the API in this way, what about NT-2?

plh: unless we are told NT do not get into the buffer

todd: more entries?

Ilya: back cases are ad force users to change
... when you click those links, you are force to change

plh: any option is not to change RT and NT, and provide another entry
... listen to resource, will have to do sth to get redirect

todd: have buffer on server time

Ilya: leave it as it is
... for those new to the API, just look at Observer

Todd: yeah, historical reasons

plh: entry type for redirect will be what?

Ilya: resource
... call it a new thing?

Todd: that will cause sudden changes for redirects in timeline
... RT with TAO, if no TAO, no redirects

plh: keep redirectCount in RT

Ilya: we need a new name

plh: get a R-entry for A

Ilya: B, C will never be seem today, name for B's entry will have some info about A

plh: if a is a fetch start C

Ilya: it should be the fetch start of A

Priorities and next charter

yoav: people will assume that /TR is not the latest draft

plh: that's not true with the auto-publication system

plh: our goal is try to apply the auto-pub system and have as less worry as possible

todd: which are the spec we want to move?

plh: hr-2, pr-2

todd: pr-2 is a clean up for the failures in pr-1?
... how about RT?

plh: never shipped a level 1

todd: but 3 vendors implement it

plh: but it relies on PR-2, may need a clean-up version, but not touch the ED

Todd: User Timing? 3 implementations

plh: That's already a REC
... UT-2, same as RT, need a subset

Todd: already UT REC, not sure that's necessary to subset UT
... for the specs blocked by performance Observer, how long do we need to wait?

Ilya: We don't know the intention of Moz yet

plh: HR-2, need a test for worker. PR-2, need to clean up the test suite

Todd: We have written quite a few test in the past 6 month, we'd like to share them with W3C
... but there are a lot of spec corner cases in those cases

plh: Do we want to write test case for corner cases?
... Beacon, will need to write another python parser under w-p-t
... I will need to fire an issue, and James will add support for that

yoav: there are some blink test for Beacon. How do you get resource response in w-p-t?

plh: I wrote a test that can explain the process

Ilya: RIC, no update on implementation

Todd: It's on my list
... Beacon in apps, what if it's closed? f.ex. WebView

Ilya: Independent to vendors

Todd: Resource Hints...

plh: How can we prove implementation?
... how about a pre-fetch from the server?

todd: browsers can be triggered...

yoav: pre-connect should be a separate host

todd: need a new case for each attribute

plh: We'll need commends from WebDriver folks

Todd: pre-fetch and pre-render are implemented by Firefox

plh: Is it possible for you to write a query for the usage?

Todd: not sure
... pre-connect smells the highest one

Ilya: It isn't ready yet
... the issue refers to Fetch

todd: same as SW

Ilya: Telconf ... any complain?

Yoav: I can do later

todd: it's difficult to schedule a time from Asia and the chairs

Resolved: we meet 1 hour early for our teleconferences

todd: we should switch goal for the next charter

Ilya: we got feedback from Moz

plh: we can do some minor update, add the primer

todd: and Memory API

Ilya: we should start from use cases

yoav: let's create a report and collect use cases

Ilya: a general use case report

plh: we have a repo for WebPerf, which is a good place for that report

Summary of Action Items

$Date: 2015/10/31 08:54:18 $