Re: API draft proposal: DOM Timing

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