- From: Philippe Le Hegaret <plh@w3.org>
- Date: Tue, 10 Mar 2015 16:34:39 -0400
- To: public-web-perf <public-web-perf@w3.org>
Available at:
http://www.w3.org/2015/02/25-webperf-minutes.html
Summary:
- Ilya to merge his PRs for NELs
- plh to then publish a FPWD for NEL
- plh to review Performance object support PR in performance timeline
- Ilya to create a PR for ServiceWorker support in NT and RT
- plh to then update the graphics in NT and RT
- Ilya to do a PR for PerformanceObserver in Performance Timeline
Text version:
Web Performance
25 Feb 2015
Attendees
Present
plh, igrigorik, Yoav, Michael, Tobin, Todd
Regrets
Chair
plh?
Scribe
plh
Contents
* [2]Topics
1. [3]NEL PRs
2. [4]Performance timeline PR7 and related
3. [5]HRT issue 1
4. [6]add workerStart to measure ServiceWorker startup
5. [7]next steps for "PerformanceObserver"
__________________________________________________________
NEL PRs
[8]https://github.com/w3c/navigation-error-logging/pull/30
[8] https://github.com/w3c/navigation-error-logging/pull/30
igrigorik: included the 500 requests yesterday
... 4xx won't be part of it
... only 3xx
yoav: is there a mechanism for site owners to know about 404
errors?
... even they're content errors
igrigorik: 500 are already logged
... 404 can already be extracted
... shooting for the minimal here: just protocol errors
yoav: so 5xx is for gateways that may have lost the requet
along the way
igrigorik: yes
... content errors and application errors shoulnd't be included
imo
yoav: makes sense
... could be worthwhile to know that logic in the spec btw
... adding a note on why 4xx aren't there
Todd: still little ensure on 5xx
... might make it optional
... it's a little on a the boundary
igrigorik: in our current implementation, we report them. it's
convenient for folks that are using it and in fact, they'd
prefer more data but I'm pushing back
todd: I'm imagining the case where they wouldn't want to see
the 500
igrigorik: [examples like CDNs]
... to start, we could make it optional and see the experience
yoav: opt-in by apps or by implementation?
igrigorik: "user agent MAY report 5xx" and tweaks with
experience
... I'll update the proposal to make it optional and add a note
on 4xx
[9]https://github.com/w3c/navigation-error-logging/pull/29
[9] https://github.com/w3c/navigation-error-logging/pull/29
igrigorik: unregister report uris
... seveal report uris for reliability purposes
... we'd like to provide a way to remove them
... if the report uri returns a 410, that's a signal it needs
to be removed
... second case is for the user agent to GC the report URIs if
it wants to
... (such as multiple failures)
todd: does 410 need an age so that the report URI can unblock
itself?
igrigorik: not sure
... there is also retry after with the max-age
... you could respond that
... not sure if we need it in the spec
todd: don't think it's important to have in the first iteration
but could imagine scenarios for it
igrigorik: I'll open a new bug and iterate there
... can I merge the pull requests?
plh: sure
[others are ok]
igrigorik: can we rename the repo to network-error-logging
plh: can we publish the FPWD for NEL?
[no objection heard]
Resolved: NEL to FPWD
Performance timeline PR7 and related
igrigorik: looking at service worker and sync'ing our API with
it
... editorial exercise
... moved the Performance interface into PT
... so a bit of clean-up
... also in UT and RT to remove references to window
... since it's also available on worker
plh: did you move Timing-Allow-Origin as well?
igrigorik: not yet but agree to move
plh: I'll do the merge by tomorrow
HRT issue 1
[10]https://github.com/w3c/hr-time/issues/1#issuecomment-758203
53
[10] https://github.com/w3c/hr-time/issues/1#issuecomment-75820353
igrigorik: related to service worker as well
... making the timeline start consistent
... ie all start if the start of the worker (dedicated or
shared)
michael: for shared workers, you couldn't sync up a start time
... for dedicated, we were able to be more direct
igrigorik: a worker could start an other worker
michael: as long as they share the start time of the document,
it's ok
igrigorik: it seems odd to distinguish
plh: do we have implementation of hrt for worker?
igrigorik: not sure
yoav: would be valuable to have both
igrigorik shared worker doesn't have a document
scribe: could also be a push
... completely detached
igrigorik: the app can communicate the start time of the
document (as well as performance.now)
... as a follow up, would be interested to see if it's
implemented
todd: I don't think IE does support on worker
[11]http://w3c.github.io/hr-time/#sec-time-origin
[11] http://w3c.github.io/hr-time/#sec-time-origin
[...]
yoav: looks like there is code in chrome for that
... not sure if it's shipped
plh: follow on the issue thread
add workerStart to measure ServiceWorker startup
[12]https://lists.w3.org/Archives/Public/public-web-perf/2015Fe
b/0066.html
[12] https://lists.w3.org/Archives/Public/public-web-perf/2015Feb/0066.html
igrigorik: new attribute on both NT and RT
... the point at which we route the request to the service
worker
... if no SW, it returns 0
plh: can you establish the SW time with one attribute?
[13]http://w3c.github.io/navigation-timing/#h-processing-model
[13] http://w3c.github.io/navigation-timing/#h-processing-model
igrigorik: that would be the difference between workerStart and
startTime
plh: workerStart is between startTime and linkNegotiationStart?
igrigorik: correct
... I'll create a pull for it
plh: and I'll update the graphic
todd: if you do a fetch and the SW does complex network
operations, how do we report that?
igrigorik: not sure how to communicate that
... you would see alll of those in the SW
... but would be opaque to the page
... you would have to move your logic in the service woker
plh: if multiple request, what would you see?
igrigorik: almost like it came from the cache
next steps for "PerformanceObserver"
interface LazyPerformanceEntryList {
bool HasEntryType(string);
PerformanceEntryList getEntries();
PerformanceEntryList getEntriesByType(DOMString entryType);
}
getEntriesByName(DOMString entryName)?
Todd: this looks good to us
... one question: current proposal interplays with performance
timeline
... should we hook it earlier? ie performance timeline isn't
required
igrigorik: if you want all events, you register your PO right
away
yoav: can we unite the concepts and add navigation request as
well?
igrigorik: would be odd to have past timing information
... for nav timing, maight be ok, but would be odd for frame
timing
todd: can you opt-in? on document load, nav timing and RT are
all loaded for you
... with PO, i may want to use that for them
... it feels strange to come up with a new construct and not be
able to do the things we did before
igrigorik: there is overlap
[...]
scribe: NT and RT are in a special place
plh: for NT< you'll get it in the observer after the load event
igrigorik: ok. next step is to do a pull request
Received on Tuesday, 10 March 2015 20:34:41 UTC