How HTTP/2 Header Compression and Server Push Boost Web Performance

In the previous article we covered HTTP/2’s binary framing and multiplexing; this article introduces the remaining two features: header compression (HPACK) and server push.

Header compression

Server push

Header Compression

In HTTP/1.x each request carries header fields as plain text, wasting bandwidth especially with cookies. HTTP/2 uses the HPACK compression format, which combines static Huffman coding and a shared header table to reduce the size of header blocks.

HPACK defines a static table of common header fields (e.g., :method, :path, :scheme) that both client and server know. When a header value matches an entry, the client can send only the index, e.g., Index=2 for :method=GET , saving bytes.

<code>+-------+-----------------------------+---------------+
| Index | Header Name                 | Header Value  |
+-------+-----------------------------+---------------+
| 1     | :authority                  |               |
| 2     | :method                     | GET           |
| 3     | :method                     | POST          |
| 4     | :path                       | /             |
| 5     | :path                       | /index.html   |
| 6     | :scheme                     | http          |
| 7     | :scheme                     | https         |
| 8     | :status                     | 200           |
... (truncated) ...
+-------+-----------------------------+---------------+</code>

If a header value is not present in the static table, HPACK falls back to Huffman encoding of the literal value. For example, the path /post/20180811-http2_in_go_1.html is encoded using Huffman coding and occupies 25 bytes, which is still smaller than the raw string for typical cases.

HPACK also maintains a dynamic table per connection. When a new header is transmitted, both client and server add the Header Name + Header Value pair to the dynamic table, assigning it a new index (e.g., Index=76). Subsequent requests can reference this index, reducing the transmission to a single byte.

Server Push

Server Push allows the server to initiate additional responses without explicit client requests. After the client requests GET /index.html , the server can push related resources (CSS, images) using PUSH_PROMISE frames, eliminating the need for separate round‑trips.

<code>&lt;!DOCTYPE html&gt;
&lt;html&gt;
&lt;head&gt;
  &lt;link rel="stylesheet" href="push-style.css"&gt;
&lt;/head&gt;
&lt;body&gt;
  &lt;h1&gt;hello, server push&lt;/h1&gt;
  &lt;img src="push-image.png"&gt;
&lt;/body&gt;
&lt;/html&gt;</code>

The PUSH_PROMISE frame contains a promised stream ID and a header block describing the resource to be pushed. The client may accept the push or reject it with an RST_STREAM frame.

Using the h2c command‑line client, we can observe the sequence of frames: the initial GET request, followed by PUSH_PROMISE frames for streams 2, 4, 6, 8, each delivering Header and Data frames, and finally END_STREAM flags marking completion.

Stream State Machine

HTTP/2 streams transition through states such as idle, open, half‑closed, and closed. The reserved state is used for streams created by PUSH_PROMISE and does not count toward the active stream limit, allowing the server to push resources even when the concurrency limit is reached.

Understanding these mechanisms helps developers leverage HTTP/2 to reduce latency and bandwidth usage in web applications.