基于用户代理的JavaScript服务

我很好奇在web服务器中使用用户代理检测来确定要发送给客户端的JavaScript资源版本的利弊

特别是，如果一些web浏览器本机支持某个功能，而另一些浏览器则需要详细的JavaScript解决方案，那么最好是向所有人提供该解决方案，并仅在客户端需要时运行它，还是只向需要它的浏览器提供该解决方案，并向其他浏览器发送本机功能的精简包装

第二种方法可能会出现什么问题，它们是否会超过支持浏览器响应较小的好处？

您可以使用

RequireJS

（或类似工具）按需加载“可选”内容

1） 页面加载时。。。通过小测试测试功能（Modernizer）

2） 如果测试成功，请使用本机，如果失败，请使用RequireJS加载其他资源

3） 利润

---

这确实假设您不介意额外的http请求……过多的测试、加载和重复过程可能会降低速度，而不仅仅是包含一个大（r）文件，因此它取决于大小写，但肯定有合理的中间立场……

通常，更好的解决方案是向所有客户端发送一份javascript副本，并让javascript本身进行功能检测，以决定如何最好地处理每个浏览器。这有以下优点：

功能检测比浏览器检测准确得多，向前兼容得多，即使是使用您以前从未见过的浏览器

您可以为所有浏览器获得一个javascript副本，这通常更易于测试和部署，并且不需要服务器端分发逻辑

开发一套通用的javascript以适应客户端条件通常比开发N个独立版本的站点javascript容易得多

---

这并不是赞成或反对，但从SEO的观点来看，你应该考虑Google将永远看到“解决方案”版本。（我假设这是默认的，当没有用户代理被识别时）

我之所以这么说，是因为我看到一些网站在实施基于用户代理/cookie的自定义JS规则时大做文章

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

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

在加速方面，你可以做很多更好的事情——如果这确实是你的目标

另一种可能性（无需额外的http请求）是使用用户代理头发送不同版本的内容。看一看关于这个主题的文章，或者看一看关于这个主题的参考文章

我认为有以下优点：

• 发送到客户端的内容量（特别是移动设备，这很好）
• 浏览器将使用不需要代码的资源

缺点：

• 需要维护不同数量的javascript版本
• 用户代理解析正在移动目标

---

客户端的优点是可以使用功能检测，而只有服务器端的UA字符串嗅探是可能的（通常不成功），那么，是否值得向客户端发送功能检测代码，然后在需要时动态请求解决方法？支持浏览器的好处是否证明了非支持浏览器的额外往返是合理的？因为浏览器缓存的效率和解决特定问题的相对较小的javascript大小，所以动态加载少量javascript很少值得额外往返。我不认为#3是真的，您首先根据一个标准开发一个通用代码集，然后为该标准开发单独的ployfill模块以解决怪癖问题browsers@Bergi，针对特定功能的多边形填充是可以的，但将它们单独提供是不必要的，并且会使开发、部署和测试复杂化。这些东西几乎总是很小的，只需将它们全部包含进来，然后选择一个功能检测客户端所需的东西就简单多了。谷歌机器人在Chrome上冲浪。当然，您需要一个聪明的UA字符串->引擎版本映射；但是为所有未识别的客户端（如SE爬虫）提供“不支持JS”-纯HTML版本也不错：-）