Contact emails
Summary
Previously, we always dispatched PerformanceEntries to PerformanceObservers, via a simple PostTask. We propose to switch to dispatching these entries during idle times, or 100ms after they’ve been queued, whichever comes first.
The spec encourages this new behavior:
“The performance timeline task queue is a low priority queue that, if possible, should be processed by the user agent during idle periods to minimize impact of performance monitoring code.”
We propose initially not postponing first-paint and first-contentful paint entries, as these are the biggest contributors to risk #2 below. Once we’ve shipped this initial change, we’ll ship a separate change to postpone paint timing entries.
Motivation
There are two independent motivations for this change:
Discourage web developers from relying on these timestamps to make decisions on site behavior.
Improve performance by not processing PerformanceEntries during performance critical times.
Risks
Interoperability and Compatibility
There are two primary risks:
This change impacts the ordering of performance entries. This could break performance monitoring for sites which make invalid assumptions about event ordering. This is fairly unlikely, and the breakage most likely wouldn’t be user facing, so I believe this is a risk worth taking.
Postponing the dispatch of entries means that developers will miss some PerformanceEntries they previously received, due to users navigating away before the entries are dispatched. This may negatively impact their metrics collection. We have no insight into this, and will need to rely on bug reports, and reaching out to specific analytics providers to gather data on the negative impact here.
Edge: PerformanceObserver hasn’t shipped yet.
Firefox: Doesn’t delay dispatch.
Safari: Doesn’t delay dispatch.
Web developers: No known opinions.
Ergonomics
This makes PerformanceObservers somewhat less predictable, which is part of the objective. Developers shouldn’t be relying on these APIs to make user facing decisions, only for analytics purposes.
Activation
Not relevant, as this changes the implementation of an existing API.
Demo Link
This demo queues a PerformanceEntry with a busy main thread, and displays when the entry is processed. Before this change, Chrome normally displayed ~30ms, and it now displays ~120ms.
Debuggability
No additional debugging support is needed.
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Yes.
Is this feature fully tested by web-platform-tests?
All PerformanceObserver tests verify this functionality:
Link to entry on the feature dashboard
https://www.chromestatus.com/feature/4993617147985920
Requesting approval to ship?
Yes.
Contact emails
Contact emails
Summary
Previously, we always dispatched PerformanceEntries to PerformanceObservers, via a simple PostTask. We propose to switch to dispatching these entries during idle times, or 100ms after they’ve been queued, whichever comes first.
The spec encourages this new behavior:
“The performance timeline task queue is a low priority queue that, if possible, should be processed by the user agent during idle periods to minimize impact of performance monitoring code.”
We propose initially not postponing first-paint and first-contentful paint entries, as these are the biggest contributors to risk #2 below. Once we’ve shipped this initial change, we’ll ship a separate change to postpone paint timing entries.
Motivation
There are two independent motivations for this change:
Discourage web developers from relying on these timestamps to make decisions on site behavior.
Improve performance by not processing PerformanceEntries during performance critical times.
Risks
Interoperability and Compatibility
There are two primary risks:
This change impacts the ordering of performance entries. This could break performance monitoring for sites which make invalid assumptions about event ordering. This is fairly unlikely, and the breakage most likely wouldn’t be user facing, so I believe this is a risk worth taking.
Postponing the dispatch of entries means that developers will miss some PerformanceEntries they previously received, due to users navigating away before the entries are dispatched. This may negatively impact their metrics collection. We have no insight into this, and will need to rely on bug reports, and reaching out to specific analytics providers to gather data on the negative impact here.
Edge: PerformanceObserver hasn’t shipped yet.
Firefox: Doesn’t delay dispatch.
Safari: Doesn’t delay dispatch.
Web developers: No known opinions.
Ergonomics
This makes PerformanceObservers somewhat less predictable, which is part of the objective. Developers shouldn’t be relying on these APIs to make user facing decisions, only for analytics purposes.
Activation
Not relevant, as this changes the implementation of an existing API.
Demo Link
This demo queues a PerformanceEntry with a busy main thread, and displays when the entry is processed. Before this change, Chrome normally displayed ~30ms, and it now displays ~120ms.
Debuggability
No additional debugging support is needed.
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Yes.
Is this feature fully tested by web-platform-tests?
All PerformanceObserver tests verify this functionality:
Link to entry on the feature dashboard
https://www.chromestatus.com/feature/4993617147985920
Requesting approval to ship?
Yes.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHTsfZAJvV8o_3e2Zz%3DC52dW5fQ3brE91hw56fEiULygLTFjrQ%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHTsfZBz%2B3OXvbM5JyCR5_B60LWjNNSQB1BYc6%3DGXS6moxoVvQ%40mail.gmail.com.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY-yY2jW0oFMsxeV5XM7-oPWiUVipOB%3Dv4rHaTUyecvV2w%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHTsfZBz%2B3OXvbM5JyCR5_B60LWjNNSQB1BYc6%3DGXS6moxoVvQ%40mail.gmail.com.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/164fa710-eef9-4983-aca1-576016e6ee6a%40chromium.org.
PhistucK, I'm claiming that developers should ONLY rely on performance monitoring APIs for measuring performance. We've seen some cases where developers try to identify if a connection is slow based on PerformanceEntry's, and modify site behavior on the fly. This is the behavior we'd like to discourage (though we should provide other tools for identifying when a "light" version of a site should be served).
Rick, I actually hadn't seen the takeRecords proposal, thanks for pointing it out. There are several methods of accomplishing the goal here: performance.getEntries(), or relatively soon, registering a new performance observer with the buffered flag. takeRecords is certainly nicer than those approaches.We don't want to delay this work arbitrarily long, as the longer we leave this the more likely developers are to start depending on the current behavior. I'm following up off-thread here with others in the web perf space, and will see what folks think.
The spec recommends this delay, but we haven't had recent discussion around this with other vendors. I've kicked off a thread here to get input from other browser vendors, and will follow up here once we've received some feedback.
Regarding testing, the spec doesn't require that entries are delayed, so we shouldn't be enforcing this. I referenced those tests as they provide coverage that the API functions correctly, viewing the delay of performanceEntry dispatch as an implementation detail.
Philip, the common mode of failure here is that developer analytics starts missing data it depends on, which we really can't detect. There's a small class of bugs where developers are misusing the API and end up relying on the order of PerformanceEntry's across multiple entryTypes which we could potentially detect, but my intuition is that it's extremely rare. Most cases where this could cause failure will be flaky today.
Contact emails
Summary
Previously, we always dispatched PerformanceEntries to PerformanceObservers, via a simple PostTask. We propose to switch to dispatching these entries during idle times, or 100ms after they’ve been queued, whichever comes first.
The spec encourages this new behavior:
“The performance timeline task queue is a low priority queue that, if possible, should be processed by the user agent during idle periods to minimize impact of performance monitoring code.”
We propose initially not postponing first-paint and first-contentful paint entries, as these are the biggest contributors to risk #2 below. Once we’ve shipped this initial change, we’ll ship a separate change to postpone paint timing entries.
Motivation
There are two independent motivations for this change:
Discourage web developers from relying on these timestamps to make decisions on site behavior.
Improve performance by not processing PerformanceEntries during performance critical times.
Risks
Interoperability and Compatibility
There are two primary risks:
This change impacts the ordering of performance entries. This could break performance monitoring for sites which make invalid assumptions about event ordering. This is fairly unlikely, and the breakage most likely wouldn’t be user facing, so I believe this is a risk worth taking.
Postponing the dispatch of entries means that developers will miss some PerformanceEntries they previously received, due to users navigating away before the entries are dispatched. This may negatively impact their metrics collection. We have no insight into this, and will need to rely on bug reports, and reaching out to specific analytics providers to gather data on the negative impact here.
Edge: PerformanceObserver hasn’t shipped yet.
Firefox: Doesn’t delay dispatch.
Safari: Doesn’t delay dispatch.
Web developers: No known opinions.
Ergonomics
This makes PerformanceObservers somewhat less predictable, which is part of the objective. Developers shouldn’t be relying on these APIs to make user facing decisions, only for analytics purposes.
Activation
Not relevant, as this changes the implementation of an existing API.
Demo Link
This demo queues a PerformanceEntry with a busy main thread, and displays when the entry is processed. Before this change, Chrome normally displayed ~30ms, and it now displays ~120ms.
Debuggability
No additional debugging support is needed.
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Yes.
Is this feature fully tested by web-platform-tests?
All PerformanceObserver tests verify this functionality:
Contact emails
Summary
Previously, we always dispatched PerformanceEntries to PerformanceObservers, via a simple PostTask. We propose to switch to dispatching these entries during idle times, or 100ms after they’ve been queued, whichever comes first.
The spec encourages this new behavior:
“The performance timeline task queue is a low priority queue that, if possible, should be processed by the user agent during idle periods to minimize impact of performance monitoring code.”
We propose initially not postponing first-paint and first-contentful paint entries, as these are the biggest contributors to risk #2 below. Once we’ve shipped this initial change, we’ll ship a separate change to postpone paint timing entries.
Replying on this thread, as it seems to have already accumulated critical mass of the replies...It is not 100% clear from your intent if this applies to entries included in the timeline as well as observed entries. I assume from your reference to the task queue that it is not, but could you clarify that?
Further comments inlineOn Fri, Nov 24, 2017 at 8:01 PM Tim Dresser <tdre...@google.com> wrote:Contact emails
Summary
Previously, we always dispatched PerformanceEntries to PerformanceObservers, via a simple PostTask. We propose to switch to dispatching these entries during idle times, or 100ms after they’ve been queued, whichever comes first.
The spec encourages this new behavior:
“The performance timeline task queue is a low priority queue that, if possible, should be processed by the user agent during idle periods to minimize impact of performance monitoring code.”
We propose initially not postponing first-paint and first-contentful paint entries, as these are the biggest contributors to risk #2 below. Once we’ve shipped this initial change, we’ll ship a separate change to postpone paint timing entries.
Motivation
There are two independent motivations for this change:
Discourage web developers from relying on these timestamps to make decisions on site behavior.
Wouldn't Web developers still be able to make decisions based on the contents of the entries, rather than on their timing?
Improve performance by not processing PerformanceEntries during performance critical times.
That makes sense for PerformanceObserver as the API makes it easier for the developer to handle the entries as they are queued. Since such handling can take a long time, it might be better to pick idle times for such handling.
Risks
Interoperability and Compatibility
There are two primary risks:
This change impacts the ordering of performance entries. This could break performance monitoring for sites which make invalid assumptions about event ordering. This is fairly unlikely, and the breakage most likely wouldn’t be user facing, so I believe this is a risk worth taking.
So, the ordering in which PerfObserver fires for different entry types?Could you clarify what you mean here?The ordering that I'd be most worried about is not the ordering of entry handlers but ordering of PerfObservers with onload handlers. Right now, that ordering is not specified, but may be relied on in some ways.e.g. it's fairly probably there are scripts out there that assume that all observers have arrived by the time `window.onload` fires. The resulting breakage is likely not to be user facing, but it would still be breakage.
Postponing the dispatch of entries means that developers will miss some PerformanceEntries they previously received, due to users navigating away before the entries are dispatched. This may negatively impact their metrics collection. We have no insight into this, and will need to rely on bug reports, and reaching out to specific analytics providers to gather data on the negative impact here.
I have a feeling that the `takeRecords` approach Rick mentioned would be able to properly mitigate both these concerns, as we can advocate for its use before collecting all entries (either on `onload` or on visibility changes).
Edge: PerformanceObserver hasn’t shipped yet.
Firefox: Doesn’t delay dispatch.
Safari: Doesn’t delay dispatch.
Web developers: No known opinions.
Ergonomics
This makes PerformanceObservers somewhat less predictable, which is part of the objective. Developers shouldn’t be relying on these APIs to make user facing decisions, only for analytics purposes.
Activation
Not relevant, as this changes the implementation of an existing API.
Demo Link
This demo queues a PerformanceEntry with a busy main thread, and displays when the entry is processed. Before this change, Chrome normally displayed ~30ms, and it now displays ~120ms.
Debuggability
No additional debugging support is needed.
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Yes.
Is this feature fully tested by web-platform-tests?
All PerformanceObserver tests verify this functionality:
I share Rick's confusion regarding these tests. They are testing the current behavior, right?Also, can we test the unpredictable variant? If so, how?