从浏览器的性能角度来看，压缩http响应是否值得？

Question

浏览器可能比网络约束更接近CPU限制，对吧？ 我们有一个非常繁重的ajax应用程序，所以从浏览器的角度来看（不是服务器）也许最好不要使用压缩。

您的想法

Answer 1

完全取决于浏览器和设备。在 home 的普通笔记本电脑或台式机上，我希望网络成为限制因素。在一个连接良好的办公室，如果有任何真正的瓶颈，可能是CPU。

然后你有上网本，可能超过3G，然后是手机......

就个人而言，我会选择压缩 - 我认为它更有可能是胜利而不是瓶颈。

Answer 2

我的客户往往是小型办公室，共享互联网连接，带宽是主要考虑因素。我们的应用程序提供了相当大的页面，因此压缩产生了巨大的差异。

取决于带宽，用户数量，页面大小。

压缩和解压缩相当优化，您可以控制压缩级别。

Answer 3

嗯，一般来说，与网络速度相比，cpu周期非常便宜。除非您尝试解压缩MB数据，否则解压缩不会占用太多cpu周期。

但我想最终它取决于将要使用该网站的人。如果您确定他们有非常快速的互联网连接，那么您可能不必使用压缩。另一方面，您可以始终确保它们具有相当不错的CPU。

Answer 4

不使用压缩的最常见原因是它放在服务器上的CPU负载（对于动态页面）。通常这是一个更大的问题，因此我假设平均台式PC上的CPU负载可以忽略不计（除非你想使用bz2）。

Answer 5

如果压缩对服务器造成很大负担和/或压缩率很差（例如20K页压缩到19K），那么我会考虑将其关闭。除非您的用户与服务器的连接速度非常快，低延迟，否则浏览器几乎肯定会受到网络限制。

我还会考虑HTTP缓存技术 - 它们非常高效，使用AJAX更是如此。这样可以节省服务器和客户端的带宽和CPU周期 - 无需重新请求，重新生成，重新传输，重新解析和重新保存已有的内容。

Answer 6

见Yahoo's best practices for making web pages fast。 特别是Gzip Components结论：

  

尽可能多地压缩文件类型是减少页面重量和加速用户体验的简便方法。

Answer 7

与压缩相比，减压是一个非常快速的过程。即使是弱CPU（如移动设备中的CPU）也可以在几乎任何时间内有效地解压缩GZIP（ZIP，Deflate等）。压缩数据是一项艰巨的任务。通过使用压缩，您将增加服务器负载......并且增加的水平并不总是可以忽略不计。通常，它是在服务器端的带宽使用和CPU使用之间的权衡。对于客户端，它通常不起作用，除非因特网访问非常慢（例如移动电话连接）。但是，只有text / html / css / js可以被有效压缩，你在网页上找到的大多数其他数据（例如大量的图像）根本无法压缩;所以，如果我们谈论的网页有8 kb的网页数据，并且网页本身加载了200多kb的图像数据，那么忘记压缩，它几乎不会给你买任何东西。

Answer 8

浏览器下载的任何脚本或内容只需要解压缩就可以了，从那时起它已经处于解压缩状态（唯一的例外是如果你正在做一些奇怪的HTTP头，比如Cache-控制：禁止商店。

它的解压缩速度比下载速度快 - 瓶颈不太可能是解压缩。

即使是稍微老一点的低速计算机也可能以每秒50 MB以上的速度对GZIP进行解压缩，这需要至少410Mbps（即410,000kbps）的网络速度才能饱和。

我更关心像IE6（SP2之前版本）这样的错误浏览器，它们要求压缩内容但在某些情况下无法处理它，比如压缩CSS时。