Using the onload event is a good idea, but has drawbacks:
1. Some interesting network loads don't generate a load event (XHR,
CSS background image, CSS @import, redirect, object subresource, etc)
2. We'd like lazy loaded analytics scripts to have access to timings
even if they are loaded after othe
Using the onload event is a good idea, but has drawbacks:
1. Some interesting network loads don't generate a load event (XHR,
CSS background image, CSS @import, redirect, object subresource, etc)
2. We'd like lazy loaded analytics scripts to have access to timings
even if they are loaded after othe
On Mon, Apr 26, 2010 at 10:07 PM, Zhiheng Wang wrote:
> Discussions with several browser developers suggest exporting a flattened
> data structure containing
> all the DOMTiming objects on the page. Doing so allows site developers to
> send the all the timing information
> back for analysis wit
Discussions with several browser developers suggest exporting a flattened
data structure containing
all the DOMTiming objects on the page. Doing so allows site developers to
send the all the timing information
back for analysis without travelling the entire DOM tree. It helps minimize
the observ