我很好奇在 Web 服务器中使用用户代理检测来确定将哪个版本的 JavaScript 资源发送到客户端的利弊。
特别是,如果某些 Web 浏览器本身支持某个功能,而其他浏览器需要详细的 JavaScript 解决方法,那么最好将解决方法提供给每个人并仅在客户端需要时才运行它,或者仅将解决方法提供给需要的浏览器它并向其余部分发送一个围绕本机功能的薄包装?
第二种方法可能会出现什么问题,它们是否会超过支持浏览器的较小响应的好处?
我很好奇在 Web 服务器中使用用户代理检测来确定将哪个版本的 JavaScript 资源发送到客户端的利弊。
特别是,如果某些 Web 浏览器本身支持某个功能,而其他浏览器需要详细的 JavaScript 解决方法,那么最好将解决方法提供给每个人并仅在客户端需要时才运行它,或者仅将解决方法提供给需要的浏览器它并向其余部分发送一个围绕本机功能的薄包装?
第二种方法可能会出现什么问题,它们是否会超过支持浏览器的较小响应的好处?
RequireJS
您可以使用(或类似的)按需加载“可选”内容。
1)在页面加载...用小测试测试功能(Modernizr)
2)如果测试成功,使用native,如果失败,使用RequireJS加载你的其他资源
3) 利润。
这确实假设您不介意额外的 http 请求....这些测试、加载、重复过程中的太多可能会减慢速度,而不仅仅是包含一个大 (r) 文件,因此它取决于大小写,但绝对是合理的中间地带...
通常,向所有客户端发送一份 javascript 副本并让 javascript 本身进行功能检测以确定如何最好地处理每个浏览器是一个更好的解决方案。这具有以下优点:
这在 Pro 或 Con 中都没有,但从 SEO 的角度来看,您应该考虑 Googlebot 将始终看到“解决方法”版本。(我假设这是默认的,当没有识别到用户代理时)
我之所以这么说是因为我看到几个网站在实现基于用户代理/cookie 的自定义 JS 规则时进行了尝试。
回到您最初的问题,我建议使用单一版本方法 - 仅仅是因为它更易于管理并且不需要您跟踪脚本的多个版本。
@BLSully 在这里(+1)也提出了一个很好的观点,即这将导致额外的 HTTP 请求。您的整体网站速度可能会直线下降,或者任何收益都会大大减少。
你可以做很多更好的事情来加速 - 如果这确实是你的目标......
另一种可能性(无需额外的 http 请求)是使用用户代理标头来发送不同版本的内容。查看有关此主题的设备图集文章或查看有关在野外使用此技术的参考文章。
我认为是专业人士:
缺点: