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.

Tim

On Tue, Jun 12, 2018 at 3:33 PM Gilles Dubuc <gilles@wikimedia.org> 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 <tdresser@google.com> wrote:
>
>> Hi Gilles!
>>
>> This is the right forum for this. See the issue here
>> <https://github.com/w3c/charter-webperf/issues/30> for a bit of
>> discussion.
>> Our most recent proposal is here
>> <https://docs.google.com/document/d/1sBM5lzDPws2mg1wRKiwM0TGFv9WqI6gEdF7vYhBYqUg/edit#heading=h.eny79fwwx642>,
>> 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 <gilles@wikimedia.org>
>> 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:
>>> https://docs.google.com/document/d/1uClbE5oVGeChekv3VB5Zg3LNorU7VkfxHmNQdFxbP8M/edit?usp=sharing
>>>
>>> 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
>>>
>>
>