Re: API draft proposal: DOM Timing

> On Jun 13, 2018, at 6:05 AM, Timothy Dresser <tdresser@chromium.org> wrote:
> 
> Given appropriate quantization (perhaps to the nearest 8ms or so?), I think we can ensure this leaks no more information than rAF + setTimeout(0) even if we do report when painting has finished.

Quantization alone won’t be enough but I’m fine with ting it to rAT timing.

> We've found that in Chrome, with the first paint and first contentful paint APIs, even using the time when our main thread is done painting isn't accurate enough, because in some real cases, we'll end up with hundreds of milliseconds of compositing cost.

Since the composing cost isn’t something we can measure in iOS, this is sort of irrelevant for us.

> In order for developers to be confident that they're making their page better for users, and not just shifting work around between accounted and unaccounted parts of the pipeline, I think it's important that we provide a timestamp which is as close as possible to when pixels hit the screen.

I tend to agree with this principle but what you're currently proposing is not implementable due to security concerns as well as architectural limitations.

- R. Niwa

> On Tue, Jun 12, 2018 at 7:06 PM Ryosuke Niwa <rniwa@apple.com> wrote:
>> 
>> > On Jun 12, 2018, at 12:33 PM, Gilles Dubuc <gilles@wikimedia.org> wrote:
>> > 
>> > I'm glad to see that a similar proposal is already in the works!
>> > 
>> > DOM attributes would only be workable for us if the overhead of watching a couple of elements is negligible. Due to current limitations in our caching stack, we would have to serve the attribute to all visitors, even if we're only interested in measuring performance for 1 every 1000 pageviews (which is the default RUM measurement ratio we're applying at the moment).
>> 
>> Having to constantly run query selectors to match an element is incredibly more expensive than recording the timing of an element which has this element.
>> 
>> > The reduced overhead requirement forcing the use of attributes sounds logical. If the remaining overhead of watching via attributes isn't negligible, it would be nice to be able to enable or disable the watching altogether via a response header, which we could serve to a portion of our visitors, while keeping the HTML identical for everyone. Or via JS at the very least, even though that would need to be render-blocking JS. A killswitch probably makes more sense, as most users of the API would probably be fine with the attribute alone triggering the behavior and serving different HTML to different visitors to achieve a sampling behavior.
>> 
>> I don’t think the overhead of recording the timing of painting would be all that expensive.
>> 
>> Another tricky aspect of this proposal would be avoiding the leaking of any information such as visited link state.  Perhaps we can use the time at which the browser started / is ready to paint as opposed to when the painting has finished.
>> 
>> - R. Niwa
>> 
>

Received on Wednesday, 13 June 2018 21:27:39 UTC