[webkit-dev] Request for position on Element Timing
rniwa at webkit.org
Tue Nov 24 10:41:17 PST 2020
On Tue, Nov 24, 2020 at 8:23 AM Nicolás Peña Moreno <npm at google.com> wrote:
> Thanks for taking the time to review. I received this on my spam folder
> for some reason so apologies for the delay in replying.
> On Tue, Nov 3, 2020 at 3:31 AM Ryosuke Niwa <rniwa at webkit.org> wrote:
>> On Fri, Oct 30, 2020 at 1:58 PM Nicolás Peña Moreno <npm at google.com>
>> > Hi, I'd like to request WebKit's position on the Element Timing API,
>> which lets web developers annotate images or text whose performance they
>> care about. They can then obtain rendering timestamps from the
>> PerformanceObserver. For cross-origin images the detailed information is
>> gated on Timing-Allow-Origin. The proposed specification is at
>> https://wicg.github.io/element-timing/ and is currently shipped in
>> Chromium. Thanks!
>> Apple's WebKit team reviewed this API and we have a few
>> concerns including but not limited to:
>> - The proposed API exposes timing at which a given element is
>> painted. Implemented naively, this exposes the implementation detail of
>> what kind of compositing tiles are used on a given web page. Hiding this
>> implementation detail and recording the exact theoretical paint timing will
>> be prohibitively expensive to do on all websites.
>> Note that this only requires exposing the paint timestamp when the
> developer requires it explicitly.
I don't see how that's relevant.
> It is also implemented similarly to the 'mark paint timing' algorithm,
> which is already implemented in WebKit.
Mark paint timing is easier to implement because the granularity is for the
whole document, not per element basis. Because WebKit splits the viewport
into multiple tiles, and paint invalidation & painting is done per tile,
there isn't an easy way to isolate elements being painted from how tiles
>> - The definition of the set of owned text nodes and how they compute
>> intersectionRect seems inadequate. It's unclear what "border box" of
>> *Text* node would mean. The spec doesn't seem to ever populate "set
>> of elements with rendered text" either.
> Indeed, the border box issue is tracked on
> https://github.com/WICG/element-timing/issues/33 and
> https://github.com/w3c/csswg-drafts/issues/4197. The set is populated on
>> - The use of this API seems to incur a significant runtime as well as
>> memory cost.
>> The computations and memory should be limited to the annotated elements,
> thus not impacting developers that do not use the API. I'll send a PR to
> make that better in the spec, and additional suggestions on mitigation are
That is still a major concern since painting time is one of the most costly
operations that happens during page loads still.
- R. Niwa
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-dev