【问题标题】:php - Do backend compression/decompression algorithms have any noticeable impact on perceived client-side page load speeds?php - 后端压缩/解压缩算法对感知的客户端页面加载速度有任何明显影响吗?
【发布时间】:2026-02-06 13:10:01
【问题描述】:

我不确定 SO 是否是这个问题的正确位置,所以如果这是错误的论坛,请不要太苛刻:)

我们公司正在寻求提高页面加载速度,到目前为止我们已经做了很多标准的事情(使用缓存、CDN、删除任何不必要的代码/CSS、使用原始 JS 代替 jQuery 等)。

我正在阅读 here 关于 gz 压缩算法的内容。其中一位贡献者 (robin) 强调说 gzdeflate()gzcompress() 的速度一样快,但 gzinflate() 的速度始终是 gzuncompress() 的两倍。

如果我们使用这些 Zlib 函数之一压缩/解压缩静态 HTML,我怀疑(整个页面加载过程的)后端执行组件甚至不会被用户注意到。但是可能会注意到 1MB 的 HTML 被提供为 800kB 的 HTML。

我的问题是:使用自定义压缩/解压缩算法执行后端脚本是否会对最终用户的页面加载速度产生影响,即使压缩/解压缩算法非常复杂? (函数调用多,后端脚本本身规模大,大量使用substr_count()等不便宜的函数)

【问题讨论】:

  • PHP 代码中发生的任何事情都不会影响页面压缩速度。据我所知,启用压缩后,PHP 会缓冲所有输出,并在输出发送到客户端之前对其进行压缩。唯一会使实际压缩变慢的是增加要压缩的字节数。
  • 我的标题不好......意味着客户端而不是客户端大小:)
  • @Mike 所以如果你有一些神奇的方法将 1MB 文件压缩到 10 个字节,但它需要一个脚本需要 1 秒来执行(极端示例但试图说明一点)用户不会在页面加载速度中注意到这一点了吗?
  • 如果理论上可以将 1 MB 压缩到 10 个字节,用户可能不会注意到整体情况,因为开始下载 1 MB 文件可能至少需要 1 秒。但是,如果您将页面加载速度增加 1 秒以仅节省几 KB,那么人们就会开始注意到它。但同样,这是理论上的。您的页面几乎永远不会是 1 MB 的 HTML(如果有,可能是有问题),并且您无法将 1 MB 压缩到 10 个字节。

标签: php zlib compression


【解决方案1】:

假设您已经在使用压缩/解压缩方法,我会说:不。 压缩率相似,您可以根据 CPU 使用情况选择算法,但回答问题时,最终用户不会注意到一些额外的位。最昂贵的操作是“第一个字节的时间”(TTFB)。

您可以在 chrome 开发工具中进行自己的基准测试,这里是 link

通过查看使用 Google、Facebook、Twitter 等大型网站的压缩类型来参考。

【讨论】: