Bug 98636

Summary: [Web Inspector] Performance Timeline Panel metabug
Product: WebKit Reporter: pdeng6 <pan.deng>
Component: Web Inspector (Deprecated)Assignee: Nobody <webkit-unassigned>
Status: RESOLVED INVALID    
Severity: Normal CC: pfeldman, seokju.kwon, simonjam, tonyg
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
description of proposal PerfTimelinePanel none

Description pdeng6 2012-10-08 02:03:43 PDT
For W3C specs, Performance Timeline[1], Resource Timing[2] and User Timing[3] are now in CR, Navigation Timing[4] is already in PR. Those specs provide unified and easily access interface to measure kinds of timing information, including resource fetch, user self-defined timestamps etc. Base on them, we can enhance web inspector to provide visualization of these timings in a timeline panel, which can help web developer identify performance bottleneck.

[1] http://www.w3.org/TR/2012/CR-performance-timeline-20120726/
[2] http://www.w3.org/TR/2012/CR-resource-timing-20120522/
[3] http://www.w3.org/TR/2012/CR-user-timing-20120726/
[4] http://www.w3.org/TR/2012/PR-navigation-timing-20120726/
Comment 1 pdeng6 2012-10-15 02:04:53 PDT
Created attachment 168652 [details]
description of proposal PerfTimelinePanel

Attached graph is the basic description of 'PerfTimeline' panel, which is the client of W3C performance timing specs.
this panel give an overview of navigate/resource timing info and user defined timing, I think it's helpful to web developers.
currently, I leveraged characters of Timeline Panel, like OverViewPane, PopOvers, typefilter etc.
Comment 2 pdeng6 2012-10-15 02:08:20 PDT
@pfeldman, how do you think of this? :)
Comment 3 Pavel Feldman 2012-10-31 22:36:18 PDT
I don't see how this is different from the Timeline itself. We should not confuse a) debugging / instrumentation capabilities and b) web-facing API for client side instrumentation. The standards you are mentioning are (b). If (b) provides something that it missing in the Timeline or Network tabs, we should file explicit requests and consider adding it there.
Comment 4 pdeng6 2012-11-01 02:13:40 PDT
(In reply to comment #3)
> I don't see how this is different from the Timeline itself. We should not confuse a) debugging / instrumentation capabilities and b) web-facing API for client side instrumentation. The standards you are mentioning are (b). If (b) provides something that it missing in the Timeline or Network tabs, we should file explicit requests and consider adding it there.

Thanks for your comments,
I know there are similar functionalities in network and Timeline panel. The 'PerfTimeline' panel was thought to be a visualization tool for web performance timing user...

For network panel, is it possible that we have a OverviewPane line Timeline panel? It will be easy to select resources we care. And can we show more resource load time breakdown when popover a resource bar? Like DNS time, connect time.
For timeline panel, can we integrate user timing API? Developer who use performance.mark and performance.measure also get the overview. I feel user’s mark are even better than providing all JS events.

Thanks
Pan
Comment 5 Pavel Feldman 2012-11-01 02:44:29 PDT
Since web apis are standardized, it is better to come up with a single viewer in a form of a content script or extension that would uniformly visualize perf data from all browsers.

We don't expect customers to optimize their sites against performance api - they have true instrumentation in the inspector for that. Making them use only perf data from api is a step back for them. Performance API should be rather used to collect stats from the wild. Even regression testing should use inspector protocol instead.

As for missing features in the inspector, please file them as separate bugs. For example, dns info is already available on bar hover on some ports (chromium). And console.timeStamp will appear on timeline.
Comment 6 pdeng6 2012-11-01 22:44:18 PDT
(In reply to comment #5)
> Since web apis are standardized, it is better to come up with a single viewer in a form of a content script or extension that would uniformly visualize perf data from all browsers.
> We don't expect customers to optimize their sites against performance api - they have true instrumentation in the inspector for that. Making them use only perf data from api is a step back for them. Performance API should be rather used to collect stats from the wild. Even regression testing should use inspector protocol instead.

Thanks, I guess the reason we shall not keep this panel is similiar functionality existed in other tabs, rather than they are api. Same story on web storage and indexDB, right :)

> As for missing features in the inspector, please file them as separate bugs. For example, dns info is already available on bar hover on some ports (chromium). And console.timeStamp will appear on timeline.

I will file in new bug entry, thanks for your help.

Pan
Comment 7 Pavel Feldman 2012-11-01 22:57:25 PDT
> Thanks, I guess the reason we shall not keep this panel is similiar functionality existed in other tabs, rather than they are api. Same story on web storage and indexDB, right :)

It is both, although you are right that duplication is more important.

IndexedDB and AppCache are implemented using native instrumentation that is not available via web-facing API. If there was a reliable way of implementing them on top of web-facing api, we would consider forming them as extensions. Btw, you could put your extension into a separate tab in the inspector at least in Chrome. See chrome.devtools.* extensions API for that. You can access window's performance object from there via async eval api.