On Wed, May 4, 2016 at 3:10 PM, Ben Maurer <ben.mau...@gmail.com> wrote:
> Hey guys --
>
> There was some discussion internally at FB about the frame timing API and
> that prompted a question today.
>
> Imagine the following JS code:
>
> function RenderHello() {
> ReactDOM.render(
> <Hello name="World" />,
> document.getElementById('container')
> );
> window.performance.mark('hello_rendered');
> }
>
> The developer wants to know when the Hello react component is "done" and
> so they set a performance mark once the element is inserted into the DOM.
>
Pardon my ignorance of React.. I'm looking at the docs, and it looks like
it accepts a third callback parameter [1]: "If the optional callback is
provided, it will be executed after the component is rendered or updated."
^ what does the above encompass, exactly?
[1] https://facebook.github.io/react/docs/top-level-api.html#reactdom.render
However, this isn't actually correct. The user only sees the Hello element
> once the browser paints that frame. For example, if a setTimeout() call
> executed during the frame that took 1 second the user would only see the
> element at the end of that second.
>
> This seems like a problem that the Frame Timing API would ideally help to
> solve. But it wasn't clear that it was possible to determine this via the
> API.
>
FT doesn't address this. As specced, it only lets you know if there was a
slow frame... what was painted within that frame is completely opaque.
Potentially, if we can work out the technical bits, I could see us exposing
some high-level attribution information on what may have been the cause of
the slow frame (e.g. script task, another frame, etc), but I don't think
we'll ever get to element-level insights due to technical and
privacy/security constraints.
FWIW, related discussion:
https://github.com/w3c/frame-timing/issues/53#issuecomment-206512574
