HTTP/2 #

Page load speed is one of the deciding factors in a modern application’s success. Slow pages trigger high user bounce rates and can lower our site’s SEO ranking in search engines. However, no matter how hard we optimize backend code or configure caching, we’ll always hit a performance ceiling if we’re still using an outdated network protocol.

The HTTP/1.1 protocol released in 1997 wasn’t designed to handle the complexity of modern web pages that require loading hundreds of assets (like images, JavaScript, CSS, and fonts) simultaneously. To solve this problem, HTTP/2 arrived with radical changes to how data is transmitted over the network. In this article, we’ll thoroughly discuss HTTP/1.1’s structural weaknesses, HTTP/2’s revolutionary features (like multiplexing and HPACK), how to enable it on both old and new Nginx, its impact on traditional web optimization techniques, and a look at the future with HTTP/3 over QUIC.

HTTP/1.1’s Main Problems: Head-of-Line Blocking and Connection Limits #

To understand why HTTP/2 is much faster, we need to look back at the fundamental problems of HTTP/1.1:

  1. Serial Queuing (Head-of-Line Blocking / HOLB): In HTTP/1.1, browsers can only send one request and receive one response at a time over a single TCP connection. If the first request (e.g., a large JavaScript script) takes a long time to process, subsequent requests (like a logo image) get blocked and must queue up.
  2. Parallel Connection Limits: To speed up page loading, modern browsers work around this by opening up to 6 parallel TCP connections per domain. However, this brings new problems:
    • Opening a new TCP connection requires repeated handshake processes (TCP three-way handshake), adding network latency.
    • Drains resources (CPU and memory) on our server to manage thousands of active TCP connections from many users simultaneously.
    • If a page needs 60 assets, those assets must load gradually in 10 queue waves (6 assets per wave).

Here’s a visual comparison of the asset loading flow between HTTP/1.1 and HTTP/2:

flowchart TD
    subgraph HTTP1["HTTP/1.1 (Serial Queue & 6-Connection Limit)"]
        Client1["Browser Client"]
        Server1["Nginx Server"]
        Client1 -- "Connection 1: Request CSS (Waiting)" --> Server1
        Client1 -- "Connection 2: Request JS (Waiting)" --> Server1
        Client1 -- "Connections 3-6: Request Images (Waiting)" --> Server1
        Client1 -. "7th asset blocked (HOLB queue)" .-> Client1
    end

    subgraph HTTP2["HTTP/2 (Parallel Multiplexing in 1 Connection)"]
        Client2["Browser Client"]
        Server2["Nginx Server"]
        Client2 -- "One TCP Connection (Stream 1: CSS, Stream 2: JS, Stream 3: Image, Stream N...)" --> Server2
        Server2 -- "Sends Responses in Parallel All at Once" --> Client2
    end

    classDef browser fill:#1e293b,stroke:#3b82f6,color:#ffffff;
    classDef server fill:#0f172a,stroke:#10b981,color:#ffffff;
    class Client1,Client2 browser;
    class Server1,Server2 server;

HTTP/2’s Key Features: Jumping Past Network Limits #

HTTP/2 solves the limitations above without changing the basic semantics of HTTP (GET/POST methods, status codes, headers, and URIs stay the same). HTTP/2 changes how data is formatted and transmitted using the following technologies:

1. Binary Framing Layer #

Unlike HTTP/1.1, which uses plain text format (slow to parse and prone to spacing errors), HTTP/2 uses a binary format (binary framing). All messages are split into small parts called Frames (like Headers Frames and Data Frames). This binary format is much faster for Nginx and browsers to parse, and minimizes transmission errors.

2. Multiplexing (One Connection for All Assets) #

This is the most important feature. Within a single open TCP connection, browsers can send hundreds of requests in parallel without waiting for each other. Each request is sent in a separate virtual binary channel called a Stream. Frames from different streams are sent interleaved through that single TCP connection, then reassembled intact at the receiving end. No more Head-of-Line Blocking queues!

3. Header Compression (HPACK) #

HTTP headers (like Cookie, User-Agent, and Referer) are often large and sent repeatedly on every asset request. HTTP/2 uses the HPACK compression algorithm, which creates static and dynamic index tables on both sides (browser and server). If the same header is sent repeatedly, HTTP/2 only sends its index ID (not the original text string), significantly saving bandwidth, especially for mobile traffic.

4. Stream Prioritization #

Because all assets are sent through one shared connection, browsers can assign priority weights (for example: critical layout-forming CSS files get high priority, while images at the bottom of the page (footer) get low priority). Nginx processes and sends high-priority assets first so websites appear faster to users.

Enabling HTTP/2 in Nginx #

Since Nginx version 1.9.5, HTTP/2 support has been available natively. However, the way to write it changed in the latest Nginx versions. We must adjust the configuration according to the Nginx version installed on our server.

Step 1: Check Our Nginx Version #

Run the following command in the server terminal to find out the Nginx version:

nginx -v

Step 2: Write the Correct HTTP/2 Directive #

A. For Nginx 1.25.1 and Above (Modern Way) #

Since Nginx 1.25.1, the http2 parameter on the listen directive has been deprecated. Nginx introduced a new separate directive named http2:

server {
    listen 443 ssl;
    server_name example.com;

    # Enable HTTP/2 using the separate directive
    http2 on;

    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    
    # ... rest of the configuration
}

B. For Nginx 1.25.0 and Below (Old Way) #

On older Nginx versions, we enable HTTP/2 by adding it as an argument to the listen directive:

server {
    # Add the http2 parameter directly on the listen line
    listen 443 ssl http2;
    server_name example.com;

    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    
    # ... rest of the configuration
}

Why Does HTTP/2 Require HTTPS? #

Per the standard specification (RFC 7540), HTTP/2 actually supports unencrypted connections (cleartext HTTP/2, known as h2c). However, for internet user privacy security, all major browsers (Chrome, Firefox, Safari, Edge) only use HTTP/2 over encrypted connections (HTTPS via TLS).

Therefore, enabling HTTP/2 in Nginx is only useful when placed in a server block listening on an SSL port (port 443). If we try to set it up on plain port 80, browsers will automatically downgrade (fallback) to plain HTTP/1.1.

Verifying HTTP/2 Is Working #

After we configure and reload Nginx (sudo systemctl reload nginx), we must verify that browsers are really using the HTTP/2 protocol.

1. Testing Using curl (Via Command Line) #

We can use the curl utility with the --http2 flag to check response headers:

curl -I --http2 https://example.com

Look at the first line of the response. If HTTP/2 is active, the response will show HTTP/2 or h2 instead of HTTP/1.1:

HTTP/2 200
server: nginx
date: Tue, 16 Jun 2026 12:00:00 GMT
content-type: text/html; charset=UTF-8

2. Testing Using Google Chrome DevTools #

  1. Open Google Chrome and access our site via HTTPS.
  2. Right-click on the page, select Inspect to open DevTools, then go to the Network tab.
  3. Right-click on the table header row (e.g., on the Name or Status column), then check the Protocol column to display it.
  4. Reload the page. In the Protocol column, we should see the value h2 for all assets loaded from our server.

Tuning HTTP/2 Parameters in Nginx for Maximum Performance #

Although enabling HTTP/2 with http2 on; already gives an instant speed boost, we can tune several Nginx parameters to optimize web server performance under heavy load.

Here are the main tuning directives we can add inside the http or server block:

1. keepalive_requests (Very Important) #

This directive determines the maximum number of requests that can be served over one TCP keepalive connection before the server closes it.

  • Default: 100 (on old Nginx versions) or 1000 (on new Nginx).
  • Recommendation: 1000 to 10000.
  • Reason: Because HTTP/2 sends all assets through a single TCP connection in parallel, the 100-request limit is very easily exceeded. If the limit is reached, Nginx forcibly closes the TCP connection and forces browsers to handshake again. Raise this value to at least 1000 to keep the connection alive during complex page loads.
# Put it in the http or server block
keepalive_requests 2000;

2. http2_max_concurrent_streams #

This directive limits the number of parallel request streams that can run simultaneously within one HTTP/2 connection.

  • Default: 128.
  • Recommendation: Keep 128 for general security, or raise to 256 if our site serves SPA (Single Page Application) apps that make massive background API queries.
  • Reason: Limiting streams prevents Denial of Service (DoS) attacks where attackers try to flood the server by opening millions of parallel streams within a single TCP connection.
http2_max_concurrent_streams 128;

3. http2_chunk_size #

Determines the maximum size of response body data that Nginx splits before sending it as HTTP/2 data frames.

  • Default: 8k (8 Kilobytes).
  • Tuning: A smaller size (e.g., 4k) can lower initial rendering latency because browsers receive page-forming data faster. Conversely, a larger size (like 16k) can increase throughput (total transfer speed) for large file delivery.
http2_chunk_size 8k;

The Web Optimization Paradigm Shift with HTTP/2 #

For web developers, the arrival of HTTP/2 changes many traditional optimization rules we’ve been following in the HTTP/1.1 era. Some techniques once considered best practices are now anti-patterns (counterproductive) when used with HTTP/2:

1. Domain Sharding (Anti-Pattern) #

  • HTTP/1.1 era: Because browsers limit to 6 connections per domain, we split static assets to different subdomains (e.g., images.example.com, css.example.com) to trick browsers into opening additional connections.
  • HTTP/2 era: This practice is harmful. HTTP/2 works best when all assets are sent through a single TCP connection so stream priority negotiation and HPACK compression work fully. Domain sharding instead forces browsers to open many slow new TCP connections. Stop Domain Sharding!

2. Aggressive File Bundling (New Trade-Off) #

  • HTTP/1.1 era: We combined dozens of JavaScript files into one large file (bundle.js) to minimize the number of HTTP requests.
  • HTTP/2 era: Sending many small files is no longer a problem thanks to multiplexing. Sending one big file is actually harmful because if we only change one line of JavaScript code, users’ browsers are forced to re-download the entire large file. With small files, browsers only download the changed file and use local cache to the fullest.

3. CSS/Image Sprites (Less Relevant) #

  • HTTP/1.1 era: Combining dozens of small icon images into one large image file (sprite) to minimize requests.
  • HTTP/2 era: No longer provides significant performance impact. We’re advised to separate icon images so browser memory doesn’t load images that aren’t needed on a particular page.

Why Server Push Should Be Ignored? #

HTTP/2 introduced a feature called Server Push. This feature lets the server proactively send assets (like CSS or JS files) to the browser before the browser requests them.

For example, when the browser requests index.html, Nginx knows the browser will definitely need the style.css file. Nginx can send that CSS file along with the HTML file without waiting for the browser to parse the HTML document and request it.

In Nginx, Server Push is enabled with the configuration:

location = /index.html {
    http2_push /css/style.css;
}

Why Was This Feature Abandoned? #

Although it sounds promising, Server Push has a fatal design flaw: the server doesn’t know whether the browser already has that file in its local cache. As a result, the server often sends the CSS file repeatedly on every page visit, wasting user bandwidth needlessly.

Because of this, modern browsers (including Google Chrome and Chromium-based browsers since version 106) have completely removed Server Push support. Writing http2_push configuration in Nginx today has no effect on modern browsers.

Instead, use standard HTML elements to give loading hints:

<link rel="preload" href="/css/style.css" as="style">

Looking to the Future: HTTP/3 and QUIC #

Although HTTP/2 solved Head-of-Line Blocking at the HTTP level (Layer 7), this protocol still has weaknesses at the transport level (Layer 4) because it runs over TCP.

If one TCP data packet is lost or corrupted along the way due to bad network conditions, the TCP protocol pauses the entire data transmission to request retransmission of the lost packet. As a result, all streams within one HTTP/2 connection get delayed too. This is called TCP Head-of-Line Blocking.

To solve this problem, HTTP/3 arrives by completely dropping the TCP protocol and switching to QUIC, which runs over UDP.

Protocol Stack Comparison:
HTTP/1.1 & HTTP/2:  [ Application: HTTP ] -> [ Transport: TCP ] -> [ Network: IP ]
HTTP/3:             [ Application: HTTP ] -> [ Security: TLS 1.3 ] -> [ Transport: QUIC (UDP) ] -> [ Network: IP ]

In HTTP/3 (QUIC), losing one data packet on one stream only delays that specific stream, while other streams keep sending data without interruption.

Experimental HTTP/3 Configuration in Nginx #

Since Nginx 1.25.0, HTTP/3 (QUIC) support has been merged into the mainline codebase, but it’s still experimental and requires a special Nginx compilation with a TLS library supporting QUIC (like BoringSSL or quictls).

Here’s an example Nginx configuration if our server already supports HTTP/3:

server {
    # Port 443 TCP for HTTP/1.1 and HTTP/2
    listen 443 ssl;
    # Port 443 UDP for HTTP/3 QUIC (using reuseport)
    listen 443 quic reuseport;

    server_name example.com;

    # Enable HTTP/2 and HTTP/3
    http2 on;
    http3 on;

    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    # Tell browsers that HTTP/3 is available on port 443 UDP
    # The Alt-Svc (Alternative Service) header is mandatory
    add_header Alt-Svc 'h3=":443"; ma=86400';

    # ... rest of the configuration
}
  • listen 443 quic reuseport: Opens a UDP socket on port 443 with the reuseport feature to efficiently distribute QUIC packets across all Nginx worker processes.
  • add_header Alt-Svc: Because browsers always initially connect via TCP, we must send this header to tell browsers to switch to the faster HTTP/3 UDP connection on subsequent visits.

Summary #

  • Queue-Free Multiplexing: HTTP/2 cuts the serial queue (Head-of-Line Blocking) by sending many assets in parallel over a single TCP connection.
  • Match Your Nginx Version: Use the modern http2 on; directive if using Nginx 1.25.1 or newer, or the listen 443 ssl http2; parameter on older versions.
  • HTTPS Is Required: All modern browsers only support HTTP/2 implementations running over encrypted HTTPS connections.
  • Avoid Legacy Practices: Stop using old optimization techniques like Domain Sharding because they’re counterproductive to how HTTP/2’s single connection works.
  • Server Push Is Dead: Don’t use Server Push; use the <link rel="preload"> HTML tag, which is fully supported by all browsers.
  • QUIC/HTTP/3: UDP-based HTTP/3 will eliminate TCP weaknesses in the future; make sure your server is ready to switch when QUIC module support is stable.

← Previous: SSL Configuration Optimization   Next: Basic Auth →

About | Author | Content Scope | Editorial Policy | Privacy Policy | Disclaimer | Contact