Re: API draft proposal: DOM Timing

> 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 Tuesday, 12 June 2018 23:07:05 UTC