[webkit-dev] New Feature - Resource Timing
tonyg at chromium.org
Tue May 24 01:19:30 PDT 2011
On Tue, May 24, 2011 at 8:14 AM, Maciej Stachowiak <mjs at 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
More information about the webkit-dev