HTTPS, HTTP/2, and HTTP/3: How Your Server Protocol Affects Speed

Your website’s speed depends on more than just how big your files are. The protocol your server uses to deliver those files, the rules governing how data travels between your server and the visitor’s browser, has a massive impact on how fast your site feels. Two identical websites with identical file sizes can perform dramatically differently based purely on the server protocol handling the delivery.

Most small business owners have no idea which protocol their server uses. Many are still running on configurations that were state-of-the-art a decade ago. Upgrading your server protocol can deliver performance improvements comparable to months of code optimization, often with a simple configuration change. There is a lot more ground to cover here, and we walk through all of it in a practical guide to Core Web Vitals and page speed.

We configure servers for speed as a core part of every website project. Here’s what each protocol does, how they differ, and what your business gains from running the latest.

The Foundation: HTTPS and TLS

Before discussing HTTP versions, we need to address the security layer that wraps all modern web traffic. HTTPS is HTTP with encryption provided by TLS (Transport Layer Security), and it’s no longer optional.

Why HTTPS Is Mandatory

• Google ranking signal. Google has used HTTPS as a ranking factor since 2014. Sites without HTTPS are at a measurable disadvantage in search results.
• Browser warnings. Chrome, Firefox, Safari, and Edge all display “Not Secure” warnings for HTTP sites. This immediately erodes visitor trust.
• Data protection. HTTPS encrypts data in transit. Without it, form submissions, login credentials, and personal information travel in plain text where anyone on the network can read them.
• Required for modern features. HTTP/2, HTTP/3, service workers, geolocation, and many browser APIs require HTTPS. Without it, you can’t use modern web technology.
• Referral data preservation. When a user clicks from an HTTPS site to an HTTP site, the referrer information is stripped. You lose analytics data about where your traffic comes from.

The TLS Handshake

The encryption HTTPS provides comes at a performance cost: the TLS handshake. Before any data transfers, the browser and server must negotiate encryption:

1. Client Hello: The browser sends its supported TLS versions and cipher suites
2. Server Hello: The server selects a TLS version and cipher suite, sends its certificate
3. Certificate verification: The browser verifies the server’s identity
4. Key exchange: Both sides agree on encryption keys
5. Finished: Both sides confirm the handshake succeeded

This process adds one to two round trips before any page data transfers. On a connection with 50 milliseconds of latency, that’s 100-200 milliseconds of overhead.

Reducing TLS Overhead

Modern configurations minimize the TLS performance hit:

• TLS 1.3. The latest TLS version reduces the handshake from two round trips to one. This single improvement saves 50-100 milliseconds on most connections. TLS 1.3 also eliminates older, less secure cipher suites.
• TLS session resumption. When a visitor returns to your site, session tickets or session IDs allow the TLS connection to resume without a full handshake. This reduces the overhead to zero round trips for returning visitors.
• OCSP stapling. Instead of forcing the browser to contact the certificate authority to verify your certificate (which adds another round trip), your server includes the verification in its response.
• Certificate chain optimization. Sending only the necessary certificates in the chain, not the entire chain plus root certificate, reduces the handshake payload size.

Getting Your SSL Certificate

SSL certificates are available free through Let’s Encrypt, which provides automated certificate issuance and renewal. There’s no legitimate reason to run an unencrypted website. Most hosting providers and platforms support Let’s Encrypt out of the box.

HTTP/1.1: Where Most Small Business Sites Still Are

HTTP/1.1 has been the backbone of the web since 1997. It works, but it has fundamental performance limitations that newer protocols address.

How HTTP/1.1 Handles Requests

Each HTTP/1.1 connection can handle one request at a time. The browser sends a request, waits for the response, then sends the next request. To work around this, browsers open multiple connections to the same server, typically 6 at a time. But this creates its own problems.

HTTP/1.1 Performance Problems

• Head-of-line blocking. If one request is slow (a large image), every subsequent request on that connection waits. The connection is blocked until the slow response completes.
• Connection limits. With only 6 parallel connections, a page that needs 80 resources (CSS, JavaScript, images, fonts) must process them in batches. The seventh resource waits until one of the first six finishes.
• Redundant headers. Every request sends the full set of HTTP headers, including cookies, user-agent strings, and other metadata. These headers are often identical across requests but are sent in full every time, wasting bandwidth.
• No prioritization. The browser can’t tell the server which resources are most important. A decorative footer image might download before the critical CSS file.

HTTP/1.1 Workarounds (That You Shouldn’t Need Anymore)

Developers invented hacks to work around HTTP/1.1’s limitations:

• Domain sharding. Serving resources from multiple subdomains (img1.example.com, img2.example.com) to get more parallel connections. This adds DNS lookups and connection overhead.
• CSS/JS concatenation. Bundling all CSS into one file and all JavaScript into one file to reduce the number of requests. This means downloading everything even when you only need some of it.
• Image sprites. Combining multiple small images into one large image and using CSS to show portions of it. Complex to maintain and wasteful for pages that only need a few of the sprites.
• Inlining resources. Embedding CSS, JavaScript, and even base64-encoded images directly in the HTML to avoid extra requests. This bloats the HTML and prevents caching.

These workarounds added complexity to development and sometimes hurt performance on HTTP/2 and HTTP/3. They’re technical debt from an older era.

HTTP/2: The Major Upgrade

HTTP/2 was standardized in 2015 and addresses nearly every performance limitation of HTTP/1.1. If your server is still on HTTP/1.1, upgrading to HTTP/2 is one of the highest-impact performance improvements you can make.

Key HTTP/2 Features

Multiplexing: HTTP/2 handles multiple requests and responses simultaneously over a single connection. Instead of 6 connections each handling one request, one connection handles all requests in parallel. A page needing 80 resources can request all of them concurrently. No head-of-line blocking at the application layer.

Header compression (HPACK): HTTP/2 compresses request and response headers. Since headers are often repetitive across requests (the same cookies, same user-agent, same host), HPACK compression can reduce header overhead by 85-90%.

Stream prioritization: The browser can tell the server which resources are most important. Critical CSS and above-the-fold images can be prioritized over analytics scripts and footer images. The server delivers the most important resources first.

Server push: The server can proactively send resources it knows the browser will need before the browser asks for them. When the browser requests the HTML page, the server can push the CSS file alongside it, eliminating the round trip for that resource.

Real Performance Gains from HTTP/2

For a typical small business website:

• 20-50% reduction in page load time for resource-heavy pages
• Elimination of the need for domain sharding, concatenation, and sprites. Simpler development and better caching.
• Significant improvement on high-latency connections. Mobile networks and visitors far from your server benefit the most because multiplexing reduces the impact of round-trip time.
• Better performance for repeat visitors. Connection reuse and header compression benefit subsequent page loads within a session.

Enabling HTTP/2

Most modern web servers support HTTP/2:

HTTP/2 requires HTTPS. If you’re already running HTTPS, enabling HTTP/2 is usually a one-line configuration change. If you’re not running HTTPS yet, that’s your first step.

HTTP/3: The Next Generation

HTTP/3 is the latest HTTP version, standardized in 2022 and now supported by all major browsers. Its defining feature is replacing the TCP transport protocol with QUIC, a protocol built on UDP that eliminates several TCP performance limitations.

The Problem HTTP/3 Solves

HTTP/2 solved application-layer head-of-line blocking, but TCP-level head-of-line blocking remained. In TCP, if one packet is lost, every subsequent packet on that connection waits for the lost packet to be retransmitted. This affects all HTTP/2 streams on that connection, even streams that don’t need the lost packet.

On reliable wired connections, packet loss is rare and this isn’t a major issue. On mobile networks, where packet loss is common, TCP head-of-line blocking significantly impacts performance.

How QUIC Changes the Game

QUIC (Quick UDP Internet Connections) is the transport protocol under HTTP/3:

• No TCP head-of-line blocking. QUIC streams are independent. If a packet is lost for one stream, other streams continue unaffected.
• Faster connection establishment. QUIC combines the transport connection and TLS handshake into a single round trip. First connections take one round trip instead of two or three. Resumed connections can achieve zero round trips.
• Connection migration. When a user switches from Wi-Fi to cellular (or vice versa), the QUIC connection survives. TCP connections break and must be re-established, causing delays. QUIC connections are identified by connection IDs rather than IP addresses, so they persist across network changes.
• Improved congestion control. QUIC implements more sophisticated congestion control than TCP, adapting to network conditions more quickly.

Real Performance Gains from HTTP/3

The benefits of HTTP/3 are most pronounced in challenging network conditions:

Enabling HTTP/3

HTTP/3 support is growing but not yet as universal as HTTP/2:

HTTP/3 is negotiated automatically through the Alt-Svc HTTP header. Browsers that support HTTP/3 will upgrade to it after the first request. Browsers that don’t will continue using HTTP/2 or HTTP/1.1 seamlessly.

Server Configuration Best Practices

Beyond choosing the right protocol, server configuration affects performance.

Compression

Enable Brotli compression (preferred) or Gzip for text-based resources. Brotli provides 15-25% better compression than Gzip for HTML, CSS, and JavaScript files:

Keep-Alive and Connection Reuse

Ensure keep-alive is enabled so connections are reused between requests rather than closed and reopened. This is default behavior in HTTP/1.1 and inherent in HTTP/2 and HTTP/3, but misconfigurations can disable it.

Early Hints (103)

HTTP 103 Early Hints let the server send preliminary headers (like preload hints) before the full response is ready. While the server is generating the page, the browser can start downloading critical resources. This feature works with HTTP/2 and HTTP/3 and is supported by major browsers.

Security Headers

Proper security headers improve both security and performance:

How to Check Your Current Protocol

Not sure what your server is running? Here are simple ways to check:

Keep Reading

• Local SEO for Professional Services: Lawyers, Doctors, and Financial Advisors
• Migrating Legacy Systems to Modern Web Applications
• CDNs Explained: How Content Delivery Networks Speed Up Your Site