HTTP header compression is already available in HTTPS with TLS. You can compress the headers and the data as one GZIP stream. You can even use the content of a

HTTP header compression is already available in HTTPS with TLS. You can compress the headers and the data as one GZIP stream. You can even use the content of a previous response to further compress a subsquent response. (In other words, HTTP-level compression is like a ZIP file, where each document is compressed individually, whereas TLS-level compression can be made to work like a tar.gz, where all documents are compressed as a single stream, maximizing sharing.) For maximum efficiency, you need HTTP keepalive (but that is true even without using TLS compression). Firefox just recently added support for this. Apache has had support for it for a while, depending on how your OpenSSL is configured. If browsers and web servers implemented the combination of NULL encryption cipher + NULL authentication code, then you could use TLS just for compression, without having to pay the cost of cryptographic operations. However, browser makes don't want to do this because they are afraid that users think "https://.. https://... means secure" when "https://.. https://... just means TLS+http, which may or may not have useful security properties. Also, server admins usually don't want to enable long-lived connections because Apache's default way of handling them is stupid. They don't know that load balancers, servers like nginx, and other configurations of Apache do not have the same problems. This is made worse by the fact that all the advice on the internet states that keepalive is bad.