Introduction

As web applications grew in scale and the volume of resources they handle exploded, the structural limitations of HTTP/1.1 became increasingly apparent. HTTP/2 emerged in 2015 to overcome these limitations, minimize communication latency, and improve overall web performance.

HTTP/2 retains the fundamental building blocks of HTTP/1.1 (methods, status codes, URIs, etc.) while radically redesigning the data transmission layer to eliminate bottlenecks.

Structural Limitations and Bottlenecks of HTTP/1.1

HTTP/1.1 enforces strict response ordering within a single TCP connection. Pipelining never gained widespread adoption, so browsers had to open multiple connections to achieve any degree of parallelism. This design worked well enough in the early days of the web, but it causes significant performance degradation in modern, resource-heavy environments.

HOL (Head-Of-Line) Blocking

Because of the sequential processing model, if an earlier request takes too long or its response payload is excessively large, all subsequent requests in the queue stall until that earlier response completes.

Redundant Header Overhead

HTTP/1.1 transmits heavy plain-text headers with every single request and response. When exchanging dozens of resources, headers like Cookie and User-Agent, which remain identical across requests, are sent repeatedly, wasting significant network bandwidth.

Limitations of Client-Side Workarounds

Browsers adopted various techniques to work around these constraints: image sprites, CSS/JS concatenation, domain sharding and multiple connections to increase parallelism, and HTTP pipelining. However, none of these addressed the root cause. In many cases, they added resource management complexity and placed unnecessary connection overhead on servers.

Core Technologies and Changes in HTTP/2

HTTP/2 replaces the legacy sequential, text-based transmission model with new mechanisms designed to maximize performance.

Binary Framing Layer

HTTP/2 introduces a binary framing layer between the HTTP application layer and the TCP transport layer.

Where HTTP/1.1 transmits messages as newline-delimited plain text, HTTP/2 splits every message into smaller units called frames and encodes them in binary. This layer enables consistent message boundary parsing and makes it possible to multiplex requests and responses at the frame level.

Multiplexing

The binary frames travel over virtual channels called streams. Multiplexing leverages these streams to exchange multiple requests and responses in parallel, regardless of order, over a single TCP connection.

Even though frame-level data from different streams is interleaved during transmission, each frame carries a stream identifier that allows the receiver to reassemble the original messages. This largely eliminates the request-level serialization problem of HTTP/1.1, since a slow response on one stream no longer blocks other streams from making progress. That said, as long as HTTP/2 runs on TCP, a packet loss still affects all streams on the same connection, so transport-layer HOL blocking does not fully disappear.

Header Compression via the HPACK Algorithm

HTTP/2 introduces the HPACK algorithm to dramatically reduce header size.

Both the client and server maintain index tables (a static table and a dynamic table) that track previously exchanged header fields. For headers that duplicate a previous request, only the index value is sent instead of the full string. New or modified values are compressed with Huffman coding before transmission. As a result, the total volume of header data drops dramatically.

Stream Prioritization

When multiplexing transmits numerous resources in parallel, some files are more critical to rendering, such as the main CSS or core JS files. HTTP/2 provides the ability to assign weights and dependencies to each stream for priority control. However, despite being part of the specification, implementation differences across servers and browsers limited its effectiveness. The latest HTTP/2 standard (RFC 9113) has effectively deprecated the original prioritization scheme.

Changes in Frontend Optimization Strategies

The adoption of HTTP/2 goes beyond a simple speed boost; it fundamentally changes how frontend optimization works.

Thanks to multiplexing, splitting resources into smaller pieces no longer carries the same penalty it did under HTTP/1.1. Techniques like forcibly concatenating CSS or JS into a single large bundle or combining images into sprites are now lower-priority optimizations than before. Domain sharding, where browsers distributed requests across multiple domains to circumvent per-host TCP connection limits, is also no longer recommended.

A Note on Server Push

In the early days of HTTP/2, Server Push attracted attention as a feature that allows the server to proactively send resources the client has not yet requested. In practice, however, the server cannot accurately determine the browser’s cache state, turning Server Push into an anti-pattern that wastes bandwidth. Modern browsers have been dropping support for this feature, and the current recommendation is to use 103 Early Hints, which lets the client proactively prepare resources on its own.

Enabling HTTP/2 from a Server Configuration Perspective

In the Java ecosystem, Spring Boot enables HTTP/2 with no application code changes, simply by adding the following property to the configuration file.

server:
  http2:
    enabled: true

However, most modern browsers do not support unencrypted cleartext HTTP/2 (h2c) and only accept HTTP/2 over a secure connection (h2). Therefore, any web server or externally facing reverse proxy (Nginx, HAProxy, etc.) that communicates directly with browsers requires an SSL/TLS certificate. (Of course, for internal segments behind a proxy or service-to-service communication with non-browser clients, cleartext h2c remains an option.)

Operational Considerations

Enabling the setting alone does not guarantee that HTTP/2 benefits materialize. If a reverse proxy or CDN sits in front of the application, the actual negotiation may terminate at that layer, and requests may reach the backend over HTTP/1.1. In this case, even though the browser shows HTTP/2, the origin server may observe different connection counts and header handling than expected.

The first thing to verify is whether HTTP/2 negotiation actually occurs between the client and the edge layer. Check the Protocol column in the browser DevTools Network tab, or run curl -I --http2 https://example.com to quickly inspect the response headers. When testing locally or in staging, TLS is often absent, which means the browser does not use encrypted HTTP/2 (h2). Assuming HTTP/2 is active based on configuration alone can be misleading.

In environments with a reverse proxy, it is also worth confirming exactly how far the proxy handles HTTP/2. A common setup terminates HTTP/2 between the client and the proxy while keeping HTTP/1.1 between the proxy and the application. In such cases, understand precisely which segment benefits from multiplexing and header compression when interpreting performance results.

Wrapping Up

HTTP/2 improves the traditional communication model by encoding data in binary instead of plain text and transmitting split frames in parallel over a single connection. This design significantly reduces the request serialization and redundant header overhead that plagued HTTP/1.1, making complex client-side workarounds far less necessary. That said, the actual performance gains vary depending on TLS configuration, proxy placement, and where negotiation takes place, so rather than assuming the protocol upgrade alone solves everything, it helps to verify which specific segments see reduced bottlenecks.