Closed eligrey closed 14 years ago
API described sort of over here: http://ecmanaut.blogspot.com/2010/06/google-bom-feature-ms-since-pageload.html
So I can't add this in until I can confirm exactly what these times measure, ie, what the start and end points are. I can't find any documentation relating to that, but any pointers would be appreciated.
I just added chromium.Interval
to the bug. It's a timer with a μs resolution (on non-Windows OSes) as opposed to the ms resolution of Date
. I happen to have a timer script that utilizes it, which serves as a good example.
But that still doesn't tell me what the start and end points are, ie, does it measure from page unload, beforeunload, first byte, dns lookup, tcp connect, http request, or something else and does it stop at onload, ondomcontentready, first byte, last byte or something else?
Without this information I can't reliably match it to anything else we're measuring.
Since there's no documentation on chrome.csi
and chrome.loadTimes
, you can always just check the source itself.
ok, this helps somewhat. It looks like chrome.csi().pageT
is what we want only if chrome.loadTimes.requestTime
is not null. I think I can start with that and then add more checks later as I understand it better.
Lookup w.chrome.csi() for timing information if the user is on chrome and other methods fail. Closed by adc918f683fc0f971fbd73585d235d68c7c53359
Google Chrome provides a plethora of useful methods that boomerang should make use of in their
chrome.loadTimes
andchrome.csi
APIs.chromium.Interval
could also be useful for high-resolution timing.