Join GitHub today
Log User Timing API entries for Profiler nodes in the production+prof… #15260
React uses the User Timing API to mark and measure time spent working on various things for development builds. This can be a useful source of information when it comes to cross-referencing browser performance traces. We avoid doing this in production mode though, due to the performance overhead of using the API.
I believe that we could make an exception for our profiling bundles and log measurements for
Here's an initial pass at this. This change has a minimal impact on the development bundle behavior- (including the
ReactDOM: size: 0.0%, gzip: 0.0%
Details of bundled changes.
What's the contract (expectation of continued support) of this API? Is it only useful if it's reliable and can be counted on? If it heavily loses its usefulness when it's not reliable and we can't keep it reliable, then it might be more a source a noise than not.
We have a plan to start reconciling deeper in a tree instead of starting from the root, especially for pings and "retries" where we know it can't affect surroundings. In that scenario, we could skip past the Profiler nodes. We could still patch up profiling data (the inclusive time) by backtracking after the fact, but that wouldn't show in the timeline as wrapped. This optimization would also affect the DEV mode but since we're including everything there it might be a bit more obvious that we're cutting out a few levels.
This is a good question. To be honest, I didn't intend to suggest a contract here really. It just seemed like this would offer some potentially useful additional data points for some of our real world users.
It seems like this is pain point / a gap for users currently though. If you'd like, I think I could put together an alternate proposal that's a bit more robust to the deep re-rendering concern.