- From: Ben Maurer <ben.maurer@gmail.com>
- Date: Wed, 4 May 2016 15:10:00 -0700
- To: public-web-perf <public-web-perf@w3.org>
- Message-ID: <CABgOVa+EDxeme-L9WcUXnk3XcTM=kFYqz=TQLUab1oDLg0fysQ@mail.gmail.com>
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. 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. 1) If RenderHello renders quickly the Frame Timing API might not even have an entry for the paint that rendered that element. 2) Naively one would look for the first frame that had startTime + duration after the hello_rendered mark. However, presumably part of the frame rendering process happens off of the main thread. Therefore there might exist a frame that has an end time prior to hello_rendered but which did not actually paint the hello element. Is this use case a goal for the API? Am I missing something about how it could be used. -b
Received on Wednesday, 4 May 2016 22:10:27 UTC