RESOLVED CONFIGURATION CHANGED Bug 30685
Implement WebTiming feature. 
https://bugs.webkit.org/show_bug.cgi?id=30685
Summary Implement WebTiming feature.
Pavel Feldman
Reported 2009-10-22 12:03:35 PDT
<< 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>
Attachments
Add attachment proposed patch, testcase, etc.
Timothy Hatcher
Comment 1 2009-10-22 12:04:51 PDT
I don't think this needs to be tied to the Inspector, but maybe it should be?
Pavel Feldman
Comment 2 2009-10-22 12:10:28 PDT
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.
Timothy Hatcher
Comment 3 2009-10-22 12:13:23 PDT
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.
Tony Gentilcore
Comment 4 2010-07-20 10:32:34 PDT
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
Joseph Pecoraro
Comment 5 2017-02-10 12:26:29 PST
- WEB_TIMING is enabled by default on all ports. - `performance` APIs are available on all ports. Lets close this umbrella bug!
Blaze Burg
Comment 6 2017-07-24 13:33:10 PDT
*** Bug 96107 has been marked as a duplicate of this bug. ***
Blaze Burg
Comment 7 2017-07-24 13:33:53 PDT
*** Bug 61138 has been marked as a duplicate of this bug. ***
Note You need to log in before you can comment on or make changes to this bug.