W3C home > Mailing lists > Public > public-web-perf@w3.org > October 2015

[minutes] 20151026 Web Performance face-to-face

From: Philippe Le Hegaret <plh@w3.org>
Date: Thu, 29 Oct 2015 03:07:11 +0900
To: public-web-perf <public-web-perf@w3.org>
Message-ID: <56310ECF.7040407@w3.org>
Available at

   http://www.w3.org/2015/10/25-webperf-minutes.html

Text version:

                Web Performance Working Group Face-to-face

26 Oct 2015

    See also: [2]agenda, [3]IRC log

       [2] https://bit.ly/perf-tpac15
       [3] http://www.w3.org/2015/10/25-webperf-irc

Attendees

    Present
           Yoav, plh, Ilya, Todd, Ryosuke, Alex (afternoon),
           Xiaoqian (afternoon), Bartek, Mark (morning)

    Regrets
    Chair
           Ilya & Todd

    Scribe
           Yoav

Contents

     1. [4]Overview
     2. [5]HR timing 2
     3. [6]Performance Timeline
     4. [7]Memory API
     5. [8]Intersection Observer
      __________________________________________________________

Overview

    igrigorik: 10000 feet view of WebPerfWG

    [9]https://docs.google.com/document/d/1ZKW9N0cteHgK91SyYQONFuy2
    ZW6J4Oak398niTo232E/edit

       [9] 
https://docs.google.com/document/d/1ZKW9N0cteHgK91SyYQONFuy2ZW6J4Oak398niTo232E/edit

    High resolution time is the foundation of the WebPerf APIs

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

    igrigorik: translateTime recently added to HRT

    <plh> [10]https://w3c.github.io/hr-time/

      [10] https://w3c.github.io/hr-time/

    igrigorik: 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

    [11]http://www.w3.org/TR/performance-timeline-2/

      [11] http://www.w3.org/TR/performance-timeline-2/

    PerformanceObserver was added. It enables to subscribe to
    notifications about various metrics

    ResourceTiming: pretty simple and not many recent updates

    [12]https://w3c.github.io/resource-timing/

      [12] https://w3c.github.io/resource-timing/

    Navigation Timing is being refactored to be based on resource
    timing

    [13]https://w3c.github.io/navigation-timing/

      [13] https://w3c.github.io/navigation-timing/

    igrigorik: 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

    igrigorik: user timing, some cleanups but no major changes

    Server-timing - no implimentations today

    todd: the main blocker there is trailer headers

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

    [14]http://www.w3.org/TR/server-timing/

      [14] http://www.w3.org/TR/server-timing/

    mnot: there is pushback about supporting trailers in browsers

    <plh> fun fact:
    [15]https://w3c.github.io/server-timing/#the-performanceservert
    iming-interface actually defines an interface called
    "ServerTiming"

      [15] 
https://w3c.github.io/server-timing/#the-performanceservertiming-interface

    igrigorik: 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

    igrigorik: 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

    igrigorik: 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

    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

    rniwa: 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

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

    igrigorik: 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

    igrigorik: 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

    igrigorik: 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

    rniwa: maybe developer tools could help us there

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

    igrigorik: plh has a implementation document

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

    igrigorik: 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

    igrigorik: 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

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

    on mobile you should listen to page visibility rather than
    onunload

    igrigorik: 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

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

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

    <plh> Yoav: how about visibility metrics? need paint observers?

    <plh> rniwa: interested as well. we don't know what's important
    for each page

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

    igrigorik: 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

    igrigorik: 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

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

    igrigorik: 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

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

    igrigorik: it can be polyfilled

    plh: who is exposing performance.now in workers?

    igrigorik: 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 [16]https://github.com/w3c/hr-time/pull/14

      [16] https://github.com/w3c/hr-time/pull/14

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

    <plh> 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

    <plh> The term <dfn>current document</dfn> refers to the
    Document object returned by Window.odocument

    <plh> The term <dfn>current document</dfn> refers to the
    Document object returned by Window.document

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

      [17] 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

Performance Timeline

    plh: the biggest issue is from resource timing and navigation
    timing

    in both we have "clear" which when based on PerfTimeline does
    nothing

    <plh> [18]https://pad.w3ctag.org/p/pt-buffer

      [18] https://pad.w3ctag.org/p/pt-buffer

    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

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

    btu 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

    igrigorik: 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

    rniwa: 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?

    rniwa: 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

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

    igrigorik: 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

    rniwa: 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

    igrigorik: 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

    igrigorik: 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*

    igrigorik: 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

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

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

    igrigorik: 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

    igrigorik: 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

    conclusions:

    * Some buffering is required in order to not miss events

    * onload gives us the ability to register to PerfObservers from
    async scripts

    * opt-in would save us from having to measure and queue

    * Mandatory inline script registrations would allow us to
    buffer significantly less

    * There's a problem there if we have multiple PerfObservers
    registering

    igrigorik have taken a screenshot of the whiteboard

Memory API

    <ToddReifsteck> Memory info API thoughts from
    Ilya--[19]https://docs.google.com/document/d/1tFCEOMOUg4zmqeHNg
    1Xo11Xpdm7Bmxl5y98_ESLCLgM/edit#

      [19] 
https://docs.google.com/document/d/1tFCEOMOUg4zmqeHNg1Xo11Xpdm7Bmxl5y98_ESLCLgM/edit

    igrigorik: 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

    igrigorik: 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

    igrigorik: 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

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

Intersection Observer

    slightlyoff: 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?

    slightlyoff: Only to an approximation

    plh: iframes?

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

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

    slightlyoff: time is relative to the generator which may be the
    compositor

    there can be some skew

    igrigorik: about privacy and timing attack

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

    slightlyoff: 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

    rniwa: 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

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

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

    slightlyoff: the times are not correlated

    igrigorik: 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

    rniwa: 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

    slightlyoff: 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

    rniwa: 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

    slightlyoff: they poll frequently in order to avoid data loss

    igrigorik: 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

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

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

    rniwa: could we agregate the data?

    igrigorik: 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

    slightlyoff: 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

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

    <igrigorik>
    [20]http://www.webpagetest.org/breakdownTimeline.php?test=15102
    6_HS_DQ1&run=2&cached=0

 
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

    rniwa: 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

    igrigorik: Let's add some of this to frame timing, and then see
Received on Wednesday, 28 October 2015 18:07:18 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 28 October 2015 18:07:19 UTC