30685 2009-10-22 12:03:35 -0700 Implement WebTiming feature. 2017-07-24 13:33:53 -0700 1 1 1 Unclassified WebKit WebCore Misc. 528+ (Nightly build) All All RESOLVED CONFIGURATION CHANGED http://dev.w3.org/2006/webapi/WebTiming/ P2 Normal --- 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 1 pfeldman tonyg ap bburg ddkilzer jchaffraix jdapena joepeck laszlo.gombos peter sam simonjam tonyg oldest_to_newest 156964 0 pfeldman 2009-10-22 12:03:35 -0700 << 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> 156965 1 timothy 2009-10-22 12:04:51 -0700 I don't think this needs to be tied to the Inspector, but maybe it should be? 156967 2 pfeldman 2009-10-22 12:10:28 -0700 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. 156968 3 timothy 2009-10-22 12:13:23 -0700 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. 253801 4 tonyg 2010-07-20 10:32:34 -0700 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 1275484 5 joepeck 2017-02-10 12:26:29 -0800 - WEB_TIMING is enabled by default on all ports. - `performance` APIs are available on all ports. Lets close this umbrella bug! 1331720 6 bburg 2017-07-24 13:33:10 -0700 *** Bug 96107 has been marked as a duplicate of this bug. *** 1331722 7 bburg 2017-07-24 13:33:53 -0700 *** Bug 61138 has been marked as a duplicate of this bug. ***