RE: Disparity between time bases in HighResolutionTime and ResourceTiming

On Tue, Aug 28, 2012 at 8:11 PM, James Simonsen wrote:
> I'm mostly thinking about web apps that make use of same-origin iframes. Google, Gmail, Bing,
> and Hotmail come to mind. Anytime you execute script, you need to be careful about which
> context you're in and possibly apply offsets to your now() values, lest you accidentally pass
> them across a document boundary. This is doubly messy with closures.


To do cross frame communication, you have already acknowledged the frame boundaries. At that point requesting top.performance.now() instead of performance.now() is trivial.



If you are passing performance.now() delta measurements, you also do not have to worry about the time base origins.



On Tue, Aug 28, 2012 at 8:11 PM, James Simonsen wrote:
>> On Thu, Aug 30, 2012 at 5:59 PM, Jatinder Mann wrote:
>> In the current design, you have easy access to both the time measured from the
>> start of navigation of your context and your parents. The proposed change makes
>> it difficult to measure time relative to just the start of your context's start of navigation.
>
> Agreed.

This is an obvious downside of the proposal. The proposed model limits functionality: you can only measure time relative from the root context's start of navigation, whereas the current model lets you measure time from the start of navigation of the current or any of the parent contexts.

If you recall, we spent significant time re-iterating on the Timing spec designs in order to make them simpler; this proposal unnecessarily adds additional complexity to those specs. For example, with the proposal I can't simply iterate through all of my PerformanceResourceTiming entries to see when the server response start took longer than 5000ms relative to the start of the context. Depending on whether the resource is fetched in a same-origin sub-document or not, I will need to make adjustments to remove the delay from the root document start. Also, if someone hosts my content in an iframe without my knowledge, some of the timing data returned to my server will be unexpectedly shifted out, which may confuse content owners using the Timing interfaces to measure site performance.

The Timing specs are great for post processing analysis, but with performance.now() some developers may want to make run time decisions based on time since the "start" of the context. Those timing assumptions may break the moment the same script is run in an iframe context. A library that uses the absolute performance.now() values for decisions may show different results in framed or unframed contexts (e.g., if time to first paint above the fold is greater than x, do y).

Thanks,
Jatinder