What Are HTTP/2 and HTTP/3 and Why They Matter

The evolution of the HTTP protocol

HTTP or Hypertext Transfer Protocol is the foundation of web communication. Understanding the protocol matters for choosing the right hosting. Every time you open a web page, your browser sends an HTTP request to the server which responds with the requested content. HTTP/1.1 introduced in 1997 served the web for nearly two decades but with the growing complexity of modern sites its limitations became increasingly obvious. Today's sites load on average 70 to 100 resources per page including HTML, CSS, JavaScript, images, and fonts, and HTTP/1.1 wasn't designed for such intense communication.

HTTP/2 was released in 2015 in response to these limitations, bringing revolutionary changes in how the browser and server communicate. HTTP/3 introduced in 2022 goes a step further by replacing the TCP protocol with QUIC for even faster and more reliable connections. Understanding these protocols matters for anyone working in web development or hosting because they directly affect site speed and performance.

HTTP/1.1 and its limitations

How HTTP/1.1 works

HTTP/1.1 uses a text format for request and response headers and works on a request-response principle. The browser sends a request for one resource, waits for the response, then sends the next request. This is known as the head-of-line blocking problem where one slow request blocks all the other requests behind it. To work around this limitation, browsers open multiple parallel TCP connections to the same server, typically 6 to 8 connections, but every connection requires a separate TCP handshake and TLS negotiation which consumes time and resources.

HTTP/1.1 workarounds

Web developers have used various tricks for years to work around HTTP/1.1 limitations. Domain sharding is a technique where resources are distributed across multiple subdomains so the browser can open more parallel connections. CSS sprites combine many small icons into one large image to reduce the number of requests. Concatenation merges multiple JavaScript or CSS files into one large file. Inlining embeds small CSS or JavaScript blocks directly into HTML. All these techniques complicate site development and maintenance and become unnecessary with HTTP/2.

The HTTP/2 revolution

Multiplexing

The most important innovation of the HTTP/2 protocol is multiplexing which enables sending multiple requests and responses simultaneously over a single TCP connection. Instead of waiting for a response before sending the next request, the browser can send all requests at once and the server responds as soon as it has data ready. This eliminates head-of-line blocking at the application level and dramatically speeds up loading pages with many resources. One connection replaces the need for 6 to 8 parallel connections which saves memory and processor time on both sides.

Header compression with HPACK

HTTP/1.1 sends headers as uncompressed text with every request. Cookie headers can be several kilobytes large and are sent with every request to the same server. HTTP/2 uses the HPACK algorithm for header compression which maintains a table of previously sent headers and sends only the differences. This reduces header size by 85 to 95 percent which is particularly significant for sites with large cookies or many custom headers.

Server Push

The Server Push feature allows the server to proactively send resources to the browser before the browser explicitly requests them. For example when the browser requests an HTML page, the server can immediately send the CSS and JavaScript files it knows will be needed. This eliminates the delay between parsing the HTML and sending requests for related resources. In practice, Server Push must be used carefully because overly aggressive pushing of resources can consume bandwidth for resources the browser already has in cache.

Binary format

HTTP/2 uses a binary format instead of the HTTP/1.1 text format. The binary format is more efficient for parsing because computers naturally work with binary data, more error-resistant because it has a clearly defined frame structure, and more compact because it doesn't waste bytes on text delimiters and whitespace. Every HTTP/2 message is split into frames that belong to a specific stream, and multiple streams are multiplexed over a single connection.

Stream prioritization

HTTP/2 allows the browser to assign a priority to each request. CSS files that block page rendering can get a higher priority than images loading below the fold. The server uses these priorities to decide the order in which to send data when bandwidth can't satisfy all requests simultaneously. This results in faster display of visible page content even while all resources are still loading.

HTTP/3 and the QUIC protocol

The TCP problem

Although HTTP/2 solves many problems at the application level, it still uses TCP for transport. TCP has its own head-of-line blocking problem because if one packet is lost, all packets behind it must wait until the lost packet is resent and received. In HTTP/2 where all streams share a single TCP connection, the loss of one packet blocks all streams even those whose packets have successfully arrived. On unstable networks like mobile or WiFi networks this can be a significant problem.

QUIC protocol

HTTP/3 replaces TCP with the QUIC protocol developed by Google which runs over UDP. QUIC implements reliable data delivery independently for each stream, meaning packet loss in one stream doesn't block other streams. QUIC also integrates TLS 1.3 encryption directly into the transport protocol, eliminating the need for a separate TLS handshake. The result is faster connection establishment because the QUIC handshake combines transport and cryptographic parameters into one step.

Zero Round Trip connection

QUIC supports 0-RTT (Zero Round Trip Time) connection establishment for repeat visits. When the user revisits a previously visited site, QUIC can start sending data immediately without any handshake using cryptographic parameters from the previous session. This is particularly significant for mobile users who often switch between WiFi and mobile networks because the QUIC connection survives an IP address change thanks to the Connection ID instead of identification by IP address and port.

Connection migration

A TCP connection is defined by a pair of IP addresses and ports, meaning the connection breaks when the IP address changes. When a mobile user switches from WiFi to mobile network, all TCP connections break and must be re-established. QUIC uses the Connection ID for connection identification instead of IP address which enables smooth migration between networks without data transfer interruption. The user doesn't notice the transition and the site continues to load without interruption.

Performance in practice

Speed measurements

In practice HTTP/2 brings a 15 to 50 percent improvement in load speed compared to HTTP/1.1, depending on site complexity. Sites with many small resources have the most benefit because multiplexing eliminates the overhead of opening multiple connections. HTTP/3 brings an additional 5 to 15 percent improvement under ideal conditions, but on unstable networks with frequent packet loss the improvement can be 30 percent or more thanks to eliminating head-of-line blocking at the transport level.

Core Web Vitals impact

HTTP/2 and HTTP/3 directly improve Core Web Vitals metrics Google uses for ranking. Check your site's performance. Largest Contentful Paint improves because resources load faster in parallel. First Input Delay decreases because JavaScript downloads and executes faster. Cumulative Layout Shift improves because fonts and images load faster, reducing content shifts. Time to First Byte improves with HTTP/3 thanks to faster connection establishment.

How to enable HTTP/2 and HTTP/3

Server support

HTTP/2 requires an HTTPS connection (a valid TLS certificate) because all modern browsers support HTTP/2 only over TLS. Most modern web servers including Nginx, Apache, and LiteSpeed support HTTP/2 with simple configuration. For Nginx it's enough to add the http2 parameter in the listen directive. Apache requires enabling the mod_http2 module. HTTP/3 requires support for the QUIC protocol which is currently offered by Nginx with the quic module, LiteSpeed, Cloudflare, and other CDN providers.

Protocol check

You can check which HTTP protocol your site uses through Chrome DevTools. Open the Network tab, right-click on the column header, add the Protocol column, and refresh the page. You'll see h2 for HTTP/2 or h3 for HTTP/3 next to each request. Online tools like KeyCDN HTTP/2 Test and HTTP/3 Check enable quick checking without installing tools.

Conclusion

HTTP/2 and HTTP/3 are significant improvements that bring faster site loading, better user experience, and better Google ranking. HTTP/2 multiplexing, header compression, and server push eliminate many limitations of the old HTTP/1.1 protocol. HTTP/3 with the QUIC protocol solves packet loss problems and connection migration, especially useful for mobile users. At BeoHosting all hosting plans support HTTP/2 and our advanced plans also include HTTP/3 support for maximum site performance.