我最近遇到了一个仍然无法克服的问题。
因此，我有一个用 WordPress 编写的市场。在开发过程结束后，我尝试优化速度，因为该网站天生就加载许多资源。
我使用了WpFastestCache，它为我生成了 .htaccess。问题是这样的：
当
mod_deflate和mod_expires启用时，我得到了相当不错的资源加载时间，但是 TTFB 却很长（大约 10 秒！）。当
mod_deflate和mod_expires被禁用时，TTFB 会降至几乎为零，但我会获得巨大的资源加载时间。
这是常见情况还是特殊情况？
答案1
鉴于您在启用压缩和禁用压缩时都遇到问题，听起来问题的根本原因不是压缩，而是其他地方。
您解释了启用/禁用压缩时症状如何变化。然而症状的变化只是很小的变化，而这种变化正是大多数压缩方案所期望的。
当您禁用压缩时，您会看到响应的第一部分生成得很快。完全有可能，响应中快速生成的部分是一个包含独立于用户数据的静态内容的标头，这可能是它生成得如此之快的原因。问题在于数据源需要很长时间才能生成其余的输出。
一旦引入压缩，症状就会改变。很可能标头数据会很快传送到压缩代码，但为了提高性能，压缩代码会等待更多数据，然后再将数据发送到客户端。因此，少量数据会在该缓冲区中停留一段时间。
一些 API 允许生成数据的代码指示压缩代码刷新缓冲数据，如果在此处使用，则可能使症状看起来与未压缩设置中的症状相同。但如果迄今为止生成的数据本身没有用处，则刷新缓冲区是不值得的。
您应该研究的是为什么发送最后一个字节需要这么长时间。我猜如果您尝试测量发送最后一个字节的时间，无论是否压缩，结果都大致相同。
服务器的负载如何？
如果服务器负载很高，这可能表明它正忙于执行 CPU 密集型任务以响应所接收的请求。这也可能表明服务器需要大量 I/O（通常可以通过添加更多 RAM 来减少）。
如果服务器负载较低但响应速度仍然很慢，这通常表明它正在等待与另一台服务器的网络通信（可能是 DB 或 DNS 服务器响应速度很慢）。这也可能表明您的代码中存在错误。
如果您无法从服务器负载、网络流量检查或日志文件中推断出导致速度缓慢的原因，则您可能需要向应用程序添加更多日志记录，以便了解它在这么长时间内所做的事情。