Move firstLayout, etc timings out of user_timing category |
||||||
Issue descriptionIt's quite confusing to witness user-land UserTiming strings in the same category as our inserted firstLayout, firstPaint, etc times. Perhaps those events could move into "benchmark"? It's a fairly empty category that seems to be a good match.
,
Mar 22 2016
Unsurprisingly, the issue here seems to have been that I had no idea what the heck I was doing at the time. I was trying to name the category after the W3C name for the feature, but I seemed to have messed that up. - "User timing" is the W3C's name for the user-defined marks and measures. - "Navigation timing" or "performance timing" would both be acceptable names for the predefined marks and measures. Just to make sure that I understand, you're suggesting that we move the navigation timing / performance timing marks under "benchmark" instead? What do you think about just renaming the "user_timing" category to "performance_timing"? That seems to decently encompass both the navigation timing and the user timing stuff, without making people enable two categories that they'll probably want to enable together most of the time anyhow.
,
Mar 22 2016
"user_timing" category should only be real marks and measures that were established with the User Timing API. They have custom page-defined names, so we don't want them in the same category as the perfTiming & navTiming APIs which have specified names. IMO the checkbox UX issue should be solved separately from this. For clarity of reading the data, I would suggest this: * user_timing category: all userTiming API marks and measures * perf_timing category: all navTiming and resourceTiming measurements * benchmark category: our non-specified timestamps like firstLayout, firstPaint. Hows that sound?
,
Mar 24 2016
That sounds like a reasonable plan to me. Right now, the way that user timing events are traced is kind of a mess (as described by my comment here (http://bit.ly/1UcKYVu). I think that fixing that bug is my first order of business for all of these performance timing events - I'm not really sure that I want too many people relying on them before we improve their reliability, which that bug tracks. paulirish@, could you see if http://bit.ly/1UcN3B1 is an acceptable solution to the problem as far as you're concerned?
,
Mar 28 2016
/cc tzik, kouhei
,
Feb 10 2017
,
Feb 10 2017
,
Feb 16 2017
I'm not actively working on this, unassigning myself from this one. (If this still is the issue anyone feel free to pick it up!)
,
Apr 16 2018
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot |
||||||
►
Sign in to add a comment |
||||||
Comment 1 by paulir...@chromium.org
, Mar 19 2016