根据用户代理提供JavaScript

10

我对使用用户代理检测来确定要发送哪个JavaScript资源版本到客户端的优缺点很感兴趣。

特别是,如果某些Web浏览器本地支持某项功能,而其他浏览器则需要冗长的JavaScript解决方案,那么是将解决方案提供给所有人并在需要时只在客户端运行它好呢,还是只向需要它的浏览器提供解决方案,并向其余浏览器发送对本地功能进行封装的简单代码更好呢?

第二种方法可能会出现哪些问题,它们是否会超过为支持的浏览器减小响应体积的好处?


5
在客户端执行的好处是可以使用特性检测,而服务器端只能进行UA字符串嗅探(而且通常不成功)。 - Bergi
那么,将特征检测代码发送到客户端,然后根据需要动态请求解决方法是否值得呢?支持浏览器的好处是否可以弥补非支持浏览器的额外往返所带来的负担? - Joel Micah Donovan
1
由于浏览器缓存的效率以及相对较小的 JavaScript 大小来解决特定问题,额外的往返动态加载少量 JavaScript 很少有价值。 - jfriend00
4个回答

3
您可以使用RequireJS(或类似工具)来按需加载“可选”内容。

1)在页面加载时,使用小型测试(例如Modernizr)检测功能。

2)如果测试成功,则使用本地资源;如果失败,则使用RequireJS加载其他资源。

3)获得收益。

这种方法假设您不介意额外的HTTP请求……过多的测试、加载和重复过程可能比包含一个大文件更加拖慢速度,所以情况因案而异,但是肯定存在合理的折中方案。

2
通常,将您的javascript发送给所有客户端,并使javascript本身进行特征检测以决定如何最好地处理每个浏览器,这是更好的解决方案。这具有以下优点:
  1. 与浏览器检测相比,特征检测更准确且前向兼容,即使您从未见过的浏览器也是如此。
  2. 您可以为所有浏览器获取一个javascript副本,这通常更易于测试和部署,并且不需要服务器端分发逻辑。
  3. 开发一个通用的javascript集合,以适应客户端条件通常比开发N个站点javascript版本要容易得多。

我不认为第三点是正确的,你首先根据一个标准开发一个通用的代码集,然后为那些古怪的浏览器开发单独的填充模块。 - Bergi
@Bergi,为特定功能提供polyfills是可以的,但将它们单独提供会使开发、部署和测试变得不必要而且复杂。这些东西几乎总是很小的,只需将它们全部包含在内,并使用特性检测在客户端选择所需的一个即可,这样更简单。 - jfriend00

1

从SEO的角度来看,这并不是利弊问题,但你应该考虑到Googlebot总是会看到“workaround”版本。(我假设这是默认版本,在没有识别出User-Agent时)

我之所以在这里说这个,是因为我看到有几个网站在实施基于用户代理/cookie的自定义JS规则时遭受了重创。

回到你最初的问题,我建议使用单一版本方法——因为它更易于管理,而且不需要你跟踪多个脚本版本。

@BLSully在这里提出了一个很好的观点(+1),即这将导致额外的HTTP请求。你的整个网站速度可能会下降,或者任何收益都将大大减少。

如果这确实是你的目标,那么有许多更好的加速方法可以选择...


GoogleBot在Chrome上浏览。当然,您需要一个聪明的UA-String -> Engine-Version映射;但是为所有未识别的客户端(如SE爬虫)提供“不支持JS”的纯HTML版本也不错 :-) - Bergi

0

另一种可能性(无需额外的http请求)是使用用户代理标头发送不同版本的内容。请查看设备地图文章或查看有关在实际应用中使用此技术的引用文章。

我认为优点如下:

  • 向客户端发送较少的内容(特别适用于移动设备)
  • 浏览器将使用较少的资源,而不需要为其编写不必要的代码

缺点:

  • 需要维护各种版本的JavaScript
  • 用户代理解析是一个不断变化的目标

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接