Page 254 - Web性能权威指南
P. 254
单。分派和控制 HTTP 请求只要几行 JavaScript 代码，而其他复杂的任务浏览器都
包办了：
• 浏览器格式化 HTTP 请求并解析响应；
• 浏览器强制施加相关的安全（同源）策略；
• 浏览器处理内容协商（如 gzip 压缩）；
• 浏览器处理请求和响应的缓存；
• 浏览器处理认证、重定向……
正因为如此，XHR 成了所有使用 HTTP 请求 / 响应模式来传输数据的一种全能又高
性能的机制。想取得需要认证的资源，且传输期间需要压缩，取得后需要缓存以备
后用？浏览器会替我们完成这一切，以及更多。作为开发者，我们只要关注自己应
用的逻辑即可！
不过，XHR 也有其自身的局限性。如前所述，XHR 标准从未考虑流式数据处理的
场景，对它的支持也有限。这就造成了通过 XHR 进行流式数据传输既低效，又不
方便。不同的浏览器还有不同的行为，有效的二进制流式传输是不可能的。简言之，
XHR 不适合流式数据处理。
类似地，也没有最好的方式通过 XHR 实时交付更新。定时轮询会导致高开销及
更新延迟。长轮询的延迟低，但每次更新仍然有开销，因为每次更新都需要一次
HTTP 请求。既想低延迟，又想低开销，除非你有 XHR 流！
于是，尽管 XHR 是一种“实时”交付的流行机制，但从性能角度说，它或许并不
是最佳选择。现代浏览器支持比它更简单也更高效的 API，比如 Server-Sent Events
和 WebSocket。事实上，除非你有特别的理由要使用 XHR 轮询，否则应该使用这
些新技术。
XMLHttpRequest ｜ 241
