HTTP/1.1 vs HTTP/2 vs HTTP/3 — Protocol Speed Comparison
Paste any public URL to test its response time across all three HTTP protocol versions. See DNS, connect, TLS handshake, TTFB and transfer time for each — with a visual waterfall chart and side-by-side comparison.
Test a URL
Understanding the HTTP Protocol Timeline
When a browser (or curl) requests a URL, the connection goes through several sequential phases before the first byte of content arrives. This tool measures each phase individually so you can see exactly where time is being spent.
| Phase | What Happens | Good Target | Colour |
|---|---|---|---|
| DNS Lookup | Resolve the hostname (e.g. google.com) to an IP address via DNS. Often near-zero on repeat requests thanks to OS/browser DNS caching. | < 20 ms | |
| TCP Connect | Three-way handshake (SYN → SYN-ACK → ACK) to establish a TCP connection to the server. Determined by physical network latency. | < 50 ms | |
| TLS Handshake | Negotiate SSL/TLS — agree on cipher, exchange certificates, derive session keys. TLS 1.3 requires 1 round trip; TLS 1.2 requires 2. Zero for plain HTTP. | < 100 ms | |
| TTFB | Time To First Byte — the server receives the request, processes it (database query, render, cache hit), and sends back the first byte of the response. This is the server performance indicator. | < 200 ms | |
| Transfer | Download the response body. Depends on response size and network bandwidth. A 1 KB JSON API response vs a 500 KB HTML page will differ enormously here. | Varies by size |
HTTP/1.1 vs HTTP/2 vs HTTP/3 — Key Differences
| Feature | HTTP/1.1 | HTTP/2 | HTTP/3 |
|---|---|---|---|
| Year introduced | 1997 | 2015 | 2022 |
| Transport | TCP | TCP | QUIC (UDP) |
| Multiplexing | No (one request per connection) | Yes (multiple streams) | Yes (independent streams) |
| Header compression | None | HPACK | QPACK |
| Head-of-line blocking | HTTP layer + TCP layer | TCP layer only | None |
| TLS required | No | In practice yes (browsers) | Yes (built into QUIC) |
| Connection setup | TCP + TLS (2–3 RTT) | TCP + TLS (2–3 RTT) | 1-RTT or 0-RTT resumption |
| Server push | No | Yes | Yes |
Why HTTP/2 May Not Always Be Faster in This Test
For a single URL test, HTTP/2's biggest win — multiplexing — doesn't apply because there is only one request. HTTP/2 can actually be marginally slower than HTTP/1.1 on single requests due to framing overhead. HTTP/2's advantage is most visible when loading a full web page with 20–100 assets simultaneously, where the elimination of head-of-line blocking and reduced handshake overhead compound dramatically. For API calls or single-resource fetches, the difference is typically under 5ms.
How to Improve Your Site's Performance
- High DNS time: Use a fast DNS provider (Cloudflare 1.1.1.1, Google 8.8.8.8) and reduce TTL for critical records.
- High TLS time: Enable TLS session resumption (ssl_session_cache in Nginx), use TLS 1.3, or use a CDN that terminates TLS close to users.
- High TTFB: Add server-side caching (Redis, Nginx FastCGI cache), optimise database queries, or move to a CDN edge.
- Enable HTTP/2: Add
listen 443 ssl http2;in Nginx. HTTP/2 requires HTTPS. Check your current protocol with this tool. - Enable HTTP/3: Requires Nginx 1.25+ with
listen 443 quic reuseport;andadd_header Alt-Svc 'h3=":443"; ma=86400';or use Cloudflare which enables HTTP/3 automatically.
Frequently Asked Questions — HTTP Protocol Comparison
HTTP/1.1 (1997) opens one TCP connection per request, causing head-of-line blocking. HTTP/2 (2015) multiplexes multiple requests over a single TCP connection and adds header compression (HPACK), making it significantly faster. HTTP/3 (2022) replaces TCP with QUIC (UDP-based), eliminating TCP head-of-line blocking entirely and enabling 0-RTT connection resumption, which makes it faster still — especially on high-latency or lossy networks.
HTTP/2 introduces three key improvements: (1) Multiplexing — multiple requests share one TCP connection without waiting for each other; (2) Header compression — HPACK reduces repetitive header bytes by up to 85%; (3) Server push — the server can send assets proactively before the browser requests them. Together these eliminate the need for HTTP/1.1 workarounds like domain sharding, image sprites, and CSS concatenation.
HTTP/3 runs over QUIC instead of TCP. QUIC is a transport protocol built on UDP that incorporates TLS 1.3 into the handshake (reducing round trips), multiplexes streams independently (so one lost packet doesn't block others), and supports connection migration (staying connected when switching from WiFi to mobile). HTTP/3 is especially beneficial on mobile networks and high-latency connections.
HTTP/3 requires: (1) HTTPS — plain HTTP cannot use QUIC; (2) Server-side support — Nginx (1.25+), LiteSpeed, Cloudflare, or a CDN that supports HTTP/3; (3) The libcurl build on the testing server must include QUIC support. If the result shows "Not Supported", either the target server does not advertise HTTP/3 via the Alt-Svc header, or libcurl lacks QUIC capability.
DNS — time to resolve the hostname to an IP address. Connect — TCP handshake time (SYN → SYN-ACK → ACK). TLS — SSL/TLS negotiation time (0 for plain HTTP). TTFB (Time To First Byte) — time from sending the request to receiving the first byte of the response body; this reflects server processing time. Transfer — time to download the response body after the first byte arrives. Total = DNS + Connect + TLS + TTFB + Transfer.
Results reflect real network conditions from the testing server's location — they are not from your browser or your ISP. DNS time may be near-zero if the hostname was recently cached. Run the test multiple times and compare averages for more reliable numbers. For a full page load test including all assets, use tools like WebPageTest or Lighthouse.
Any publicly accessible HTTP or HTTPS URL. Private IPs (10.x, 192.168.x, 127.x), localhost, and internal hostnames (.local, .internal) are blocked to prevent SSRF attacks. URLs must start with http:// or https:// and be no longer than 512 characters. The tool follows up to 3 redirects automatically.
TTFB (Time To First Byte) measures how long the server takes to start responding after receiving a request. A high TTFB (> 200ms) usually means server-side processing is slow — slow database queries, no caching, or an under-resourced server. TTFB is one of Google's Core Web Vitals inputs and directly affects perceived page load speed. A good TTFB is under 200ms; excellent is under 100ms.