Re: API draft proposal: DOM Timing

The overhead of the attribute approach should be low enough that watching <
10 elements is effectively free, at least for Chrome's implementation.

I can't speak to overhead in other UA's.


On Tue, Jun 12, 2018 at 3:33 PM Gilles Dubuc <> wrote:

> Hi Tim,
> 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).
> 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.
> On Tue, Jun 12, 2018 at 3:33 PM, Tim Dresser <> wrote:
>> Hi Gilles!
>> This is the right forum for this. See the issue here
>> <> for a bit of
>> discussion.
>> Our most recent proposal is here
>> <>,
>> but we've had some additional discussions since last updating the doc, and
>> plan to get a more formal explainer up fairly soon.
>> Our initial proposal involved specifying elements using CSS selectors,
>> but that's definitely too high overhead.
>> We're currently planning on pushing on registration via DOM attributes.
>> On Tue, Jun 12, 2018 at 9:24 AM Gilles Dubuc <>
>> wrote:
>>> Hi everyone,
>>> I've had a rough idea for what's at the top of my wishlist in terms of
>>> client-side performance APIs that don't exist yet, and turned it into this
>>> document:
>>> This working group seems like it could be a good place for this work to
>>> happen. For now I'm soliciting feedback on the idea itself. Maybe it's
>>> nonsensical, maybe it's too hard to implement. I think there are a lot of
>>> people here who could provide valuable opinions on it. Feel free to respond
>>> directly on the document or here.
>>> Also, let me know if this is the right venue to discuss this sort of
>>> thing or if there is a better place to discuss nascent web performance
>>> browser API proposals.
>>> Thanks,
>>> Gilles

Received on Tuesday, 12 June 2018 20:00:05 UTC