Re: API draft proposal: DOM Timing

It sounds like an element-specific "first paint" is less risky and easier
to implement for everyone. Since your new proposal has already made a lot
of concessions, maybe it makes sense to make that one as well?

I agree that it's unfortunate that we wouldn't be able to truly know when
the pixels hit the screen, which is what I was also really hoping for with
a new API in that problem domain, but visited links are a compelling
example of why that's a bad idea. And as we've seen again recently, there
are always new side-channel timing attack opportunities
<https://bugs.chromium.org/p/chromium/issues/detail?id=699028> with that
sort of information. Even if there was a special rule/fuzzing for links,
it's probably just a matter of time until someone finds a creative way to
exploit that new processing-related timing information. And if the "proper
metric" has to be fuzzed or rounded beyond recognition to be safe, it might
not provide that much value.

Maybe high compositing costs and other potential significant delays after
that first paint can be tackled separately, via a different API that would
capture worst offenders above a certain threshold, for example. Which could
indirectly give you confidence that "element first paints" measured on a
given page didn't suffer any unusually long delays until the pixels hit the
screen. In environments that can measure that.

Alternatively, your proposal could include two timings for a given element:
"first paint", and "pixels hit the screen", with the second one being
optional, letting some UAs skip implementing it if there are security
concerns or architectural limitations.

On Wed, Jun 13, 2018 at 11:27 PM, Ryosuke Niwa <rniwa@apple.com> wrote:

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