Re: API draft proposal: DOM Timing

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.

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

Tim

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