带 gzip 支持的预冲洗头标签
http://developer.yahoo.com/performance/rules.html
给出了最好预先冲洗头部标签。
但我有一个问题，使用 gzip 时会有帮助吗？ （我使用的是apache2）。 我认为完整的文档将一次性被 gzip 压缩，然后发送给客户。
或者是否也可以使用 gzip 以及预刷新 head 标签
http://developer.yahoo.com/performance/rules.html
There it is given it is good to preflush the head tag .
But I have a question will it help while using gzip ? (I am using apache2).
I think full document will get gziped at one shot and then send to the client.
or is it also possible to have gzip as well as pre-flush the head tag
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
已编辑
这个问题的原始版本表明我们正在处理 HTTP 标头而不是 HTML 文档中的
部分。我将在下面留下我的原始答案，但它实际上与这个具体问题无关。要回答有关预刷新文档的
部分的问题 - 虽然可以与 gzip 结合执行此操作，但如果不对 gzip 进行更精细的控制，这可能是不可能的比 Apache 提供的进程。可以将 gzip 压缩流分成可以自行解压缩的块（参见此< /a>）但是如果有一种方法可以将 Apache 的 gzip 实现控制到这样的程度，那么我不知道。这样做可能会降低 gzip 的效率，使压缩后的大小更大，并且只有当文档的
特别大（例如大于 10KB）时才值得这样做（这这是我通过阅读 gzip 如何在引擎盖下工作而得出的一个有点武断的值，并且绝对不应该被视为福音）。与 HTTP 标头相关的原始答案：
纯粹从 HTTP 协议的角度来看，而不是确切地如何在基于 Apache 的服务器上实现它，我看不出有任何理由不能预刷新标头并使用gzip 压缩主体。请记住，标头永远不会被 gzip 压缩（如果是的话，客户端如何知道它们已经被压缩过？），内容的传输编码应该不会影响您发送标头的时间。
然而，有几点需要记住：
Content-Length:标头，虽然可能，但这是不好的做法，因为这意味着您无法使用持久连接。这引出了下一点...Content-Length:标头。这是因为在压缩正文之前您不知道正文的大小，此时它已准备好发送，因此您并没有真正（从服务器的角度）预刷新标头，即使您在开始发送正文之前，请先单独发送它们。简而言之，是的，可以这样做，但没有包罗万象的“是，这样做”或“不，不这样做”的答案 - 您是否会这样做取决于每个请求以及请求的性质这是回应。
EDITED
The original version of this question suggested we were dealing with HTTP headers rather than the
<head>section on an HTML document. I will leave my original answer below, but it actually has no relevance to this specific question.To answer the question about pre-flushing the
<head>section of a document - while it would be possible to do this in combination with gzip, it is probably not possible without more granular control over the gzip process than Apache affords. It is possible to break a gzipped stream into chunks that can be decompressed on their own (see this) but if there is a way to control Apache's gzip implementation to such a degree then I am not aware of it.Doing so would likely decrease the efficacy of the gzip, making the compressed size larger, and would only be worth doing when the
<head>of a document was particularly large, say, greater than 10KB (this is a somewhat arbitrary value I arrived at by reading about how gzip works under the bonnet, and should definitely not be taken as gospel).Original answer, relating to the HTTP headers:
Purely from the viewpoint of the HTTP protocol, rather than exactly how you would implement it on an Apache based server, I can't see any reason why you can't preflush the headers and also use gzip to compress the body. Keeping in mind that fact that the headers are never gzipped (if they were, how would the client know they had been?), the transfer encoding of the content should have no effect on when you send the headers.
There are, however a couple of things to keep in mind:
Content-Length:header which while possible, is bad practice as it means you cannot use persistent connections. This leads on to the next point...Content-Length:header in this secenario. This is because you don't know what the size of the body is until you have compressed it, by which time it is ready to send, so you are not really (from the server's point of view) preflushing the headers, even if you do send them seperately before you start to send the body.In short, yes it is possible to do it, but there is no catch-all, "Yes, do it" or "No, don't do it" answer - whether you would do it depends on each request and the nature of it's response.