CODEWITHSUNDEEP
javascriptwebserveruser-agent
Joel Micah Donovan
Joel Micah Donovan

Reputation: 321

Serving JavaScript based on User-Agent

I am curious about the pros and cons of using user agent detection in a web server to determine which version of a JavaScript resource to send to the client.

In particular, if some web browsers support a feature natively while others require a verbose JavaScript workaround, is it better to serve the workaround to everyone and run it only if it's needed client-side, or to serve the workaround only to the browsers that require it and send a thin wrapper around native features to the rest?

What problems could arise with that second approach, and might they outweigh the benefit of smaller responses for the supporting browsers?

Upvotes: 10

Views: 1246

Answers (4)

Lubo
Lubo

Reputation: 1827

Another possibility (without additional http request) is to use user agent header for sending different versions of content. Have a look at device atlas article on this topic or have a look at referenced article about usage of this technique in wild.

I see as pros:

  • lover amount of content sent to client (specially for mobile devices is this nice)
  • browser will use lover resources without code which is not needed for it

Cons:

  • various number of javascript versions need to be maintained
  • user agent parsing is moving target

Upvotes: 0

Igal Zeifman
Igal Zeifman

Reputation: 1146

This in neither Pro or Con, but speaking from SEO point of view, you should consider that Googlebot will always see the "workaround" version. (which I`m assuming is the default one, when no User-Agent was recognized)

I`m saying that here because I saw several sites take a dive, when implementing user-agent/cookie based custom JS rules.

Going back to your original question, I would suggest using a single version approach - simply because its much more manageable and does not require you to keep track of several versions of the script.

@BLSully also raised an excellent point here (+1) about the extra HTTP requests this will cause. Chances are that your overall site speed will plummet or any gains will be greatly diminished.

There are many better things you could do for acceleration - if this is indeed your goal here...

Upvotes: 1

jfriend00
jfriend00

Reputation: 707456

Usually, it is a better solution to send one copy of your javascript to all clients and have the javascript itself do feature detection to decide how to best treat each browser. This has the following advantages:

  1. Feature detection is much more accurate and forward compatible than browser detection, even with browsers you've never even seen before.
  2. You get one copy of your javascript for all browsers which is generally much easier to test and deply and requires no server-side distribution logic.
  3. Developing one common set of javascript that adapts to client conditions is generally much easier than developing N separate versions of site javascript.

Upvotes: 2

BLSully
BLSully

Reputation: 5929

You could load "optional" stuff on demand using RequireJS (or similar).

1) On Page load... test for feature with small tests (Modernizr)

2) If test succeeds, use native, if fails, use RequireJS to load your other resources

3) Profit.

This does assume you don't mind extra http requests....too many of these test, load, repeat processes can slow things down more than just including one large(r) file, so it's case dependent, but there is definitely reasonable middle ground...

Upvotes: 3

Related Questions