| Summary: | Implement WebTiming feature. | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Pavel Feldman <pfeldman> |
| Component: | WebCore Misc. | Assignee: | Tony Gentilcore <tonyg> |
| Status: | RESOLVED CONFIGURATION CHANGED | ||
| Severity: | Normal | CC: | ap, bburg, ddkilzer, jchaffraix, jdapena, joepeck, laszlo.gombos, peter, sam, simonjam, tonyg |
| Priority: | P2 | ||
| Version: | 528+ (Nightly build) | ||
| Hardware: | All | ||
| OS: | All | ||
| URL: | http://dev.w3.org/2006/webapi/WebTiming/ | ||
| Bug Depends on: | 38924, 41332, 41437, 41442, 41525, 41533, 41564, 41815, 41816, 41824, 42006, 42018, 42034, 42282, 42303, 42313, 42432, 42433, 42434, 42435, 42473, 42477, 42512, 42607, 42772, 42797, 43083, 46301, 46302, 46306, 48919, 48920, 48922, 48923, 48924, 49101, 49294, 50400, 50943, 51200, 53305, 55068, 58354, 59448, 62689, 84705 | ||
| Bug Blocks: | |||
I don't think this needs to be tied to the Inspector, but maybe it should be? Here is how I can see this implemented. - Report this timing information into inspector controller along with the timeline figures. - Capture the data even when InspectorController is not enabled. - Seed window.pageTiming getter function into the global object from within inspectedWindowScriptObjectCleared callback. It seems better to just have the data recorded on the WebCore::Page or Document, or something. And have a real DOM binding to expose it (no injection.) We don't do any injection like you describe for real DOM API. The core Web Timing implementation is now working and enabled for the chromium port. I'm leaving this bug open to track the 4 remaining bugs to enable Web Timing for the gtk, mac, qt and win ports. It is exposed as window.webkitPerformance as I suspect the spec still has a little bit of evolving to do. At some point, I expect this will become window.performance. For reference, here are links to IE9's announcement of window.msPerformance and Mozilla's bug for window.mozPerformance: - http://blogs.msdn.com/b/ie/archive/2010/06/28/measuring-web-page-performance.aspx - https://bugzilla.mozilla.org/show_bug.cgi?id=570341 - WEB_TIMING is enabled by default on all ports. - `performance` APIs are available on all ports. Lets close this umbrella bug! *** Bug 96107 has been marked as a duplicate of this bug. *** |
<< Pasting proposal details below >> User latency is an important quality benchmark for Web Applications. While JavaScript-based mechanisms can provide comprehensive instrumentations for user latency measurements within an application, in many cases, they are unable to provide a complete end-to-end latency picture. For example, the following Javascript shows the time it take to fully load a page: <html> <head> <script type="text/javascript"> var start = new Date().getTime(); function onLoad() { var now = new Date().getTime(); var latency = now - start; alert("page loading time: " + latency); } <script> </head> <body onload="onLoad()"> <!- Main page body goes from here. --> </body> </html> The script calculates the time it takes to load the page after the first bit of JavaScript in the head is executed, but it does not give any information about the time it takes to get the page from the server. To address the need for complete information on the user experience, this document introduces the Timing interface. This interface allows JavaScript mechanisms to provide complete client-side latency measurements within applications. With the proposed interface, the previous example could be modified to provide information about user's perceived page load time. The following script calculates how much time has elapsed since the occurance of a navigation event, such as the mouse click on a link. <html> <head> <script type="text/javascript"> function onLoad() { var now = new Date().getTime(); var latency = now - window.pageTiming.navigationTime; alert("User-perceived page loading time: " + latency); } <script> </head> <body onload="onLoad()"> <!- Main page body goes from here. --> </body> </html>