On Tue, May 24, 2011 at 8:14 AM, Maciej Stachowiak <m...@apple.com> wrote: > > On May 23, 2011, at 8:16 AM, Patrick Mueller wrote: > > > On 5/20/11 12:46 PM, Alexey Proskuryakov wrote: > >> What incentive will users have to enable it? For other privacy sensitive > >> features (be it cookies or geolocation), there is a clear benefit to gain > >> from them. > > > > This is a developer-mode feature. There is no direct incentive for end > > users to enable something like Resource Timing. However, it's not hard to > > imagine a site suggesting that people could enable Resource Timing, and > > have that timing information sent back to the site for analysis, much the > > same way many programs today allow users to opt-in to sending diagnostic > > information back to a server somewhere. > > Hi Patrick, > > I may have misunderstood the feature, but I don't think that is the intent. I > believe that Resource Timing and Navigation Timing are meant to be on in a > normal user configuration. Websites can then make use of these APIs to get > real-world performance data in the field, from users' machines. > > If the feature was meant to be opt-in and for developers only, then that > would greatly reduce my concerns. > > Perhaps someone more familiar with these APIs can explain the design. >
Yes, Maciej is correct. The use case is for performance monitoring rather than as a developer tool. In a dev environment, the Inspector already provides all of these details and more. However, a web page's performance characteristics may vary significantly with network conditions, geographic location, browser, OS, hardware, server load etc. A developer may be able to simulate a few of these in a controlled dev environment, but that doesn't necessarily accurately represent what real world users experience. For instance, imagine you invested in a more expensive CDN which claims to serve your static resources closer to your users. It would seem wise to have some way to monitor that this CDN actually improves user performance. That would be difficult to convince yourself of with dev tools alone. Today, many websites employ some form of performance monitoring. The problem is that only a limited picture can be obtained by timing existing events in JS. The intent of this API is to allow websites to obtain a more complete picture of the page's performance. The concern is that this may inadvertently expose side channel information. My hope is that we can trim down the API to the point where there is no new exploitable side channel information so that this can be enabled by default. -Tony _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev