Http gzip压缩对移动设备有用吗？

我想知道是否有人知道gzip压缩在移动设备上是否比在台式计算机上更有用

手机会使用更多电池吗？ 还是会因为节省带宽而节省一些？ 在这些有限的设备上，页面加载速度会更快还是解压缩速度慢

压缩后的数据是否真的到达了终端用户，还是3G提供商在某处对其进行了解压缩？（对不起，这可能是个愚蠢的问题）

---

谢谢。

这根本不是一个愚蠢的问题

正确的贸易有利于GZip

---

事实证明，Lempel-Ziv解压非常便宜（与压缩非常不同），而带宽通常非常昂贵，尤其是对于漫游用户，而且还需要大量电池电量和传输时间。

这始终取决于瓶颈在哪里

• 如果它是一个非常弱的cpu，什么都可以 这给它带来了更大的负担 糟糕
• 如果是您的网络连接， 压缩数据传输是一个巨大的挑战 性能提升
• 在任何情况下，蓄电池上的应变都是可以忽略的

在今天的移动设备中，cpu的能力肯定弱于台式pc，但通常足以进行gzip压缩和解压缩。在大多数情况下，瓶颈将是网络连接，因此gzip压缩肯定是有用的。然而，很少会有相反的情况发生

---

你只需要用一点常识看看我的答案是否适用于你的特殊情况；-）

您可能还想调查的一个问题是，您正在考虑的移动浏览器是否支持压缩。例如，我刚刚检查了BlackBerry Storm发送的请求头，但它没有发送任何“接受编码”头，这意味着服务器不应发送回压缩响应。

此外，在拥挤的地区，带宽可能非常有限，除了昂贵的if漫游。那么你认为解压过程使用的电池比额外的传输成本要少？最终用户收到的压缩数据呢？@savagman-当然。与通过无线电接口传输额外数据所用的功率相比，CPU解压数据所用的功率很小。至于漫游，货币成本可能在每兆字节美元的范围内。是的，数据会被压缩到用户手中——移动运营商故意解压数据并使其更大是疯狂的，因为这会使他们的网络过于拥挤。@Gros:一般原则是这样做（基准测试和概要文件）。为了进行比较，请尝试将带有url前缀的json文件的gzip长度与不带url前缀的gzip json进行比较。在实践中，与从多个不同域（如果它们不都在同一个域上）获取的开销相比，这一差异是没有意义的。谢谢，这看起来很有趣！到达最终用户的压缩数据呢？有趣的一点！如果您发送gzip压缩文件，它肯定会以同样的方式传输给收件人。如果您使用gzip压缩进行http传输，途中的“中继”站应该根本不关心消息内容，并将其保持不变ged也是。（他们为什么要浪费自己的cpu时间来增加转发包的带宽使用率？）是的，我想更可能是相反的。你说得对，很好。但是Apache自动为我解决了这个问题。：-）