_ gaq.push ([’_ trackPageLoadTime’])是如何工作的？

Edit: As of November 16th 2011, the _trackPageLoadTime function has been deprecated and its functionality has been set as a default setting. (Functionally speaking, it has gone from being an opt-in feature to being an opt-out feature.)

_setSiteSpeedSampleRate is the new function for setting the sample rate on this feature; its default value is 1 (as in 1%). To opt out of using this the Site Speed feature, you have to pass a 0 to this function:

_gaq.push(["_setSiteSpeedSampleRate", 0]);

From the Google Analytics Help Center:

This report currently supports the following browsers: Chrome, Internet Explorer 9 and previous versions of Internet Explorer with the Google Toolbar installed. More specifically, the Site Speed reports require browsers that support the HTML5 NavigationTiming interface or have the Google Internet Explorer toolbar installed

So, it doesn't implement its own timer, like many prior homeback solutions had, to figure out how long it takes a page to load. Instead, it uses a new HTML5 feature, currently only supported in the above listed cases, called NavigationTiming.

EDIT: This is now supported in Firefox 7

(Important to note that it doesn't run on every load; instead, it currently samples around 2% of pageviews, though it is configured to try to track all page loads on 10% of visits; as more browsers support the NavigationTiming API, you can expect the total sampled percentage to begin to get closer to 10%.)

This interface is accessed under the DOM object window.performance (or, in earlier versions of Chrome, window.webkitPerformance), using the timing attribute (so, window.performance.timing). The object stores measured values of all of the key page load event times, and Google Analytics subtracts 2 of the more important outer values to judge page load speed.

For a load of Mashable.com without cache, here's an example of what it measures (in Chrome 11):

timing = {
connectEnd: 1306677079337,
connectStart: 1306677079337,
domComplete: 1306677083482,
domContentLoadedEventEnd: 1306677081765,
domContentLoadedEventStart: 1306677081576,
domInteractive: 1306677081576,
domLoading: 1306677079478,
domainLookupEnd: 1306677079337,
domainLookupStart: 1306677079337,
fetchStart: 1306677079337,
loadEventEnd: 1306677083483,
loadEventStart: 1306677083482,
navigationStart: 1306677079337,
redirectEnd: 0,
redirectStart: 0,
requestStart: 1306677079394,
responseEnd: 1306677079669,
responseStart: 1306677079476,
secureConnectionStart: 0,
unloadEventEnd: 0,
unloadEventStart: 0
}

Those numbers are epoch milliseconds, or milliseconds since January 1, 1970. I have not seen any documentation as to which values they subtract to generate their values, but from a cursory inspection of the ga.js, it looks like it is loadEventStart-fetchStart:

h&&h[c]!=k&&h.isValidLoadTime?b=h[c]:e&&e[a]&&(b=e[a].loadEventStart-e[a].fetchStart);

For the above sample, that means it would record 4.14 seconds in the _trackPageLoadTime call.

From the W3C Navigation Timing spec:

fetchStart attribute

If the new resource is to be fetched using HTTP GET or equivalent, fetchStart must return the time immediately before the user agent starts checking any relevant application caches. Otherwise, it must return the time when the user agent starts fetching the resource.

loadEventStart attribute

This attribute must return the time immediately before the load event of the the current document is fired. It must return zero when the load event is not fired yet.

For curious parties, the ordering appears to be as follows:

connectStart, connectEnd, domainLookupStart, domainLookupEnd, fetchStart, navigationStart, requestStart, responseStart, domLoading, responseEnd, domContentLoadedEventStart, domInteractive, domContentLoadedEventEnd, domComplete, loadEventStart, loadEventEnd

For the 0 values listed:

unloadEventStart and unloadEventStart show the times for the previous page load's unloading (but only if that page has the same origin as the current one.)

redirectEnd and redirectStart measure the latency added if there was an HTTP redirect in the page load chain.

secureConnectionStart appears to be an optional measurement for measuring the SSL connection time.