user1165428
user1165428

Reputation: 51

Navigation Timing API Fallback

I want to use the Navigation Timing API to serve large resources if needed. The one problem is Safari which doesn't support it.

I challenge you, fellow and likely more experienced developers, to show me cases where the following code would not work as expected

We detect support for the API and then have a few fallbacks which, yes, unfortunately have to do some UA sniffing to provide large resources to older versions of IE and desktop Safari.

if (typeof performance != null) {

    // Navigation Timing API is Supported

    if (performance.timing.responseEnd - performance.timing.requestStart < 500) {

        // Connection is fast enough to provide large resources.

    }

} else {

    // Navigation Timing API is NOT supported

    if ( !navigator.userAgent.match(/iPhone|Android/) ){

        // Browser is either desktop Safari, Safari on iPad, or IE 8,7,6
        // Assume a fast connection. Provide large resources

    }

}

If the browser does not meet any of these conditions, it is either Mobile Safari on iPhone or an older version of Android and we are forced to just give it mobile-first resources.

Now, TEAR ME A NEW ONE. If this is terrible approach, I really want to know.

The only issue I see right now is that any desktop site without JS would get mobile resources.

Upvotes: 4

Views: 2094

Answers (1)

Jamis Charles
Jamis Charles

Reputation: 6039

Here's a polyfill for it from one of the w3c guys who worked on the spec: http://nicj.net/usertiming-js/

I would recommend that as a cleaner approach.

Update:
I've been using this method in production with decent success. http://blog.patrickmeenan.com/2013/07/measuring-performance-of-user-experience.html#comment-form

https://gist.github.com/pmeenan/5902672#file-user-timing-js

I would also look into boomerang.js for bandwidth detection:
https://github.com/lognormal/boomerang http://www.youtube.com/watch?v=gy1DTBMOA74

Upvotes: 4

Related Questions