HTTP/3 vs. HTTP/2 on CDNs: How Much Faster Is It and How Can You Confirm It’s Actually Enabled?

How much faster can a website get after enabling HTTP/3 in the CDN console?

Some expect a 30% speed improvement, some find after testing that HTTP/2 and HTTP/3 are almost identical, and others see in response headersalt-svc, and conclude that the website is already delivered over HTTP/3.

None of these judgments is complete.

The main value of HTTP/3 is not a fixed reduction of tens of milliseconds for every request. Rather, it reduces the impact of connection establishment and head-of-line blocking in high-latency, packet-loss, mobile-network, and network-switching environments. When the network is already stable and connections can be reused for a long time, the speed difference between HTTP/2 and HTTP/3 may be very small.

Here is a direct conclusion first:

On stable low-latency networks, HTTP/3 may be only 0%–5% faster than HTTP/2, or show no improvement at all. On high-latency mobile networks or cross-border links with packet loss, some pages and long-tail requests may improve by 5%–20%, and in special cases by more, but this is not a fixed benefit available to every website.

Whether HTTP/3 is actually enabled also cannot be judged solely by a CDN console switch or response header. Ultimately, you should confirm whether the protocol actually negotiated by the browser ish3.

What exactly is the difference between HTTP/2 and HTTP/3?

Both HTTP/2 and HTTP/3 support multiplexing, meaning multiple requests can be transmitted in parallel over a single connection. The most fundamental difference lies in the underlying transport protocol:

• HTTP/2 typically runs over TCP and TLS;

• HTTP/3 runs over QUIC;

• QUIC is carried over UDP and integrates TLS 1.3 into the connection establishment process;

• HTTP/3 transmits multiple requests in independent QUIC streams.

RFC 9114defines HTTP/3 as a protocol that uses QUIC to transport HTTP semantics. It retains HTTP capabilities similar to HTTP/2 but redesigns the transport method based on QUIC's stream and connection mechanisms.

The problem with HTTP/2 is not that it cannot be concurrent

HTTP/2 already solved the problem in HTTP/1.1 where multiple connections were needed for concurrent requests. A domain can typically transmit HTML, CSS, JavaScript, images, and other resources simultaneously over a single TCP connection.

The problem is that these HTTP/2 streams still share the same TCP connection.

If a TCP packet is lost, TCP must first recover the missing data before delivering subsequent content to the upper layer. Even if the subsequent data belongs to another HTTP request whose packets were not lost, it may have to wait as well. This is commonly called TCP-level head-of-line blocking.

On networks with very little packet loss and low round-trip latency, this waiting may not be noticeable; on mobile networks, cross-border links, or during peak hours, it may amplify the long tail of page load times.

Why HTTP/3 is better suited to unstable networks

QUIC provides multiple independent transport streams within a connection. When data in one stream is lost, mainly that stream is blocked, and other streams do not all need to wait for the missing data to be recovered.

This means that when an image loses packets, other CSS, JavaScript, or API requests still have a chance to continue transmitting.

However, this does not mean HTTP/3 can eliminate the impact of packet loss. QUIC connections still require congestion control, and severe packet loss will still reduce overall throughput. What it improves is the mutual blocking between different requests, not turning a very poor-quality network into a lossless one.

RFC 9308notes that QUIC uses UDP as its transport and integrates TLS 1.3, while also reminding application developers to consider issues such as network equipment, UDP reachability, and the actual deployment environment.

How much faster can HTTP/3 actually make a CDN?

There is no fixed percentage that applies to all websites. The actual difference depends on four conditions:

1. the network latency between users and CDN nodes;

2. whether the link has packet loss and jitter;

3. whether the browser reuses an existing connection;

4. how many resources the page needs to load concurrently.

Common results can be roughly divided into the following categories:

The figures in the table are only test expectations and must not be treated as performance commitments for HTTP/3. The same website may produce completely different results on Shanghai Telecom, a Southeast Asian mobile network, and U.S. residential broadband.

Why some websites show almost no change after enabling HTTP/3

If a website meets the following conditions, the improvement from HTTP/3 is usually not particularly noticeable:

• users are close to the CDN node;

• the network packet loss rate is very low;

• the page has few resources;

• the browser makes heavy use of cache;

• users are mainly repeat visitors;

• the HTTP/2 connection can be reused for a long time;

• the performance bottleneck is in the origin, database, or front-end rendering.

For example, an API's TTFB takes 1.5 seconds, of which 1.3 seconds is spent on a database query at the origin. Even if HTTP/3 saves tens of milliseconds, users will still not perceive a noticeable change.

Similarly, if LCP is slow because the hero image is 3 MB, the focus should be on image compression, dimensions, and loading priority, not the protocol version.

Why HTTP/3 is sometimes slower instead

HTTP/3 is not necessarily faster just because it is enabled. The following situations may make it perform worse than HTTP/2:

• enterprise networks, firewalls, or carriers restrict UDP port 443;

• the quality of the UDP path from users to CDN nodes is worse than TCP;

• the CDN's QUIC implementation or routing in the region is suboptimal;

• the client first attempts HTTP/3, fails, and then falls back to HTTP/2;

• the test sample is too small and happens to hit a period of network jitter;

• HTTP/2 and HTTP/3 requests are routed to different nodes;

• the cache states on the two sides differ during testing.

Therefore, seeing a single HTTP/3 request slower than HTTP/2 is not enough to conclude that the protocol is ineffective. You need to compare P50 and P95 in the same region, with the same carrier, and under the same cache state.

Why the first visit may still show HTTP/2 after enabling HTTP/3

The browser must first know that the server supports HTTP/3.

Common discovery methods include:

• the server sends aAlt-Svcresponse header declaring support for HTTP/3;

• the DNS HTTPS record provides HTTP/3-related protocol information;

• the browser has previously visited the site and has cached information that HTTP/3 is available.

If the browser has no prior knowledge that the website supports HTTP/3, the first request may be completed over HTTP/2. The server returns a response header similar to the following:

alt-svc: h3=":443"; ma=86400

After the browser remembers this information, subsequent connections attempt to use HTTP/3. Cloudflare's explanation of the HTTP/3 discovery mechanism also mentions thatAlt-Svcthis information is returned after the client first accesses the server over another protocol, while an HTTPS DNS record can provide protocol information earlier.

Therefore, the first refresh showsh2and the second refresh showsh3does not necessarily mean a configuration error.

But note:

The appearance of thealt-svc: h3response header only proves that the server has declared support for HTTP/3 to the client; it does not prove that the current request has already been transmitted over HTTP/3.

To confirm the actual protocol, you must check the request negotiation result.

Method 1: Use Chrome DevTools to confirm HTTP/3

This is the most direct inspection method for ordinary site owners.

Steps

1. Open the website in the latest version of Chrome;

2. PressF12to open DevTools;

3. go to the 'Network' panel;

4. right-click in the request list header;

5. check the 'Protocol' column;

6. refresh the page;

7. check the protocol of the main document and static resources.

Common results shown in Chrome DevTools include:

• h2: the current request uses HTTP/2;

• h3: the current request uses HTTP/3;

• http/1.1: the current request uses HTTP/1.1;

• dataorblobother values: the resource was not obtained through a regular network request.

Chrome's officialNetwork feature documentationclearly states that the Protocol column can show the protocol used by a request, for example HTTP/2 corresponds toh2, and HTTP/3 corresponds toh3.

Why checking only the homepage main document is not enough

Different resources on a page may come from different domains. For example:

• HTML comes fromwww.example.com;

• images come fromimg.example.com;

• JavaScript comes fromstatic.example.com;

• APIs come fromapi.example.com;

• fonts come from a third-party service.

These domains may use different CDNs, and HTTP/3 may be enabled for only some of them.

Therefore, you should check the main document, images, scripts, and API requests separately. You cannot assume that the entire website already uses HTTP/3 just because one resource showsh3.

What to do if h3 does not appear on the first check

You can verify again as follows:

1. keep DevTools open;

2. refresh normally two to three times;

3. do not check 'Disable cache' right away;

4. test in an incognito window;

5. confirm that the browser has not disabled QUIC;

6. confirm that the local network allows UDP 443;

7. check whether the response header containsalt-svc;

8. test with another carrier or mobile network.

'Disable cache' mainly affects the HTTP cache and does not necessarily clear all protocol discovery information stored by the browser. If you need to verify a true first visit, it is best to use a new browser profile, an incognito environment, or an independent test terminal.

Method 2: Use curl to check the negotiated protocol

First run:

curl -V

Check the output'sFeaturesprotocol capabilities, or whether HTTP/3 support is included. Not all system-provided curl builds include HTTP/3 functionality; even if the curl version looks recent, you cannot assume it supports HTTP/3.

curl's officialHTTP/3 documentationlists HTTP/3 build methods and related QUIC dependencies.

Check the protocol ultimately used by a normal request

curl -sS -o /dev/null \
  -w 'HTTP version: %{http_version}\n' \
  https://www.example.com/

You may get:

HTTP version: 2

or:

HTTP version: 3

A normal request not using HTTP/3 does not necessarily mean the server does not support it. curl may not yet have obtained theAlt-Svcinformation, or the current build may not have HTTP/3 enabled.

Force an HTTP/3 test

curl --http3-only -sS -o /dev/null \
  -w 'HTTP version: %{http_version}\n' \
  https://www.example.com/

If it succeeds and returns:

HTTP version: 3

it means the current terminal can access the domain over HTTP/3.

If it reports that the current curl does not support--http3-only, you need to use a curl build with HTTP/3 capability; if the command times out or the connection fails, continue checking the CDN configuration, UDP port 443, DNS routing, and local network restrictions.

Also output request timing

curl --http3-only -sS -o /dev/null \
  -w 'version=%{http_version} starttransfer=%{time_starttransfer} total=%{time_total}\n' \
  https://www.example.com/test.jpg

When testing HTTP/2, you can use:

curl --http2 -sS -o /dev/null \
  -w 'version=%{http_version} starttransfer=%{time_starttransfer} total=%{time_total}\n' \
  https://www.example.com/test.jpg

Be sure to check the output'sversion.--http2allows fallback to an earlier protocol when HTTP/2 is unavailable, so you cannot judge only by whether the command succeeds.

Also, do not compare speed using a single curl result. A single result is easily affected by DNS cache, connection establishment, CDN node load, and public network jitter.

Method 3: Check the Alt-Svc response header

You can use:

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

Then look for a response header similar to:

alt-svc: h3=":443"; ma=86400

It indicates that the server declares HTTP/3 is available on port 443 and allows the client to remember this information for the specified period.

However, it can only serve as a clue that HTTP/3 is available, not as final evidence of the actual transport protocol.

The following situations can all produce 'there isAlt-Svcbut HTTP/3 is not used':

• the browser does not support QUIC or has disabled it;

• UDP 443 is blocked by a firewall;

• the client attempts QUIC, fails, and falls back to HTTP/2;

• some CDN nodes do not yet correctly support HTTP/3;

• the local proxy, VPN, or security software does not support QUIC;

• the browser considers the current network conditions unsuitable for HTTP/3.

So the correct order of judgment is:

1. HTTP/3 is enabled in the console;

2. the response header or HTTPS DNS record declares support for HTTP/3;

3. the browser or curl actually negotiatesh3;

4. CDN logs show that real users are indeed generating HTTP/3 traffic.

Only when the first three conditions are met can you confirm with reasonable confidence that the feature is actually working.

Method 4: Use CDN logs to verify whether real users are using HTTP/3

If the CDN provides access logs or log delivery, check whether the following fields exist:

• HTTP protocol version;

• QUIC or HTTP/3 identifier;

• protocol from the client to the edge node;

• edge node or PoP;

• request status code;

• cache hit status;

• request duration;

• client network or region.

Logs are more representative than checks on a single computer because they can answer:

• how many users actually use HTTP/3;

• which regions have a higher HTTP/3 share;

• whether HTTP/3 is concentrated on mobile;

• what differences exist between HTTP/3 and HTTP/2 in P50 and P95;

• whether QUIC failures or fallbacks are concentrated on specific carriers.

Here it is necessary to distinguish two directions:

用户浏览器 → CDN边缘节点 → 源站

Enabling HTTP/3 externally for a website usually means that the user's browser to CDN edge node path supports HTTP/3. When the CDN edge node fetches from the origin, it may still use HTTP/1.1 or HTTP/2.

Therefore, seeing HTTP/1.1 in the origin Nginx logs does not prove that users are not using HTTP/3. The origin sees the CDN-to-origin protocol, not the protocol used by the browser to access the CDN.

To confirm HTTP/3 on the user side, you should check the CDN's edge access logs, not just read$server_protocolin the origin logs.

How to test HTTP/2 and HTTP/3 speed fairly

A truly meaningful protocol comparison requires controlling at least the following variables:

• use the same domain;

• hit the same CDN node;

• request the same file;

• keep the file size consistent;

• keep the compression method consistent;

• test HIT and MISS separately;

• test first connection and connection reuse separately;

• use the same region and carrier;

• test alternately during comparable time periods;

• record P50, P95, and failure rate separately.

Test targets should include at least:

1. a small HTML or API response;

2. a static file of about 100 KB;

3. an image or test file of 1 MB–5 MB;

4. a complete page containing many concurrent resources.

Small files are better at showing connection and TTFB differences, large files are better at showing throughput, and pages with many resources are better at showing the impact of multiplexing and packet-loss recovery.

For a specific test design, refer toCDN Speed-Testing Methodology: Active Probing, P50/P95, and Reproducible Performance Rankings.

Do not test only on an office network

The advantages of HTTP/3 often appear on unstable networks. If you test only on a low-latency gigabit office network, you are very likely to conclude that 'HTTP/2 and HTTP/3 are exactly the same.'

It is recommended to cover at least:

• local fixed broadband;

• 4G or 5G mobile networks;

• a high-latency cross-border network;

• the regions where core users are located;

• peak evening hours;

• a test environment with artificially added mild latency and packet loss.

If a website's real users mainly come from mainland China, you should also observe by China Telecom, China Unicom, China Mobile, and region separately, rather than looking only at a single cloud server test point.

Five most common misjudgments in HTTP/3 testing

Misjudgment 1: The console switch is on, so the website already uses HTTP/3

The console switch only represents configuration intent. The configuration may not yet be rolled out to all nodes, and the client may also fall back because UDP is unreachable.

Ultimately, you still need to check the browser's Protocol column, a forced HTTP/3 test, or CDN logs.

Misjudgment 2: Seeing Alt-Svc proves that the current request is HTTP/3

Alt-SvcIt is only the server's protocol hint for subsequent requests. The request that currently returns this response header may itself be using HTTP/2.

Misjudgment 3: One low HTTP/3 TTFB means it is faster

A single request has no statistical significance. DNS cache, connection reuse, cache hits, and node load can all make a single result deviate from the normal level.

If a website has the problem of 'sometimes fast, sometimes slow,' followWebsite Sometimes Fast, Sometimes Slow: How Should CDN Speed Testing Be Done?and observe multiple rounds of results and the long tail.

Misjudgment 4: The origin logs show HTTP/1.1, so the CDN has not enabled HTTP/3

Origin logs usually record the CDN-to-origin fetch protocol and cannot directly represent the user-to-CDN protocol.

Misjudgment 5: A low HTTP/3 share means configuration failure

Not all browsers, networks, proxies, and enterprise firewalls can use QUIC stably. Some users falling back to HTTP/2 is normal compatibility behavior.

You should observe the actual share of users for whom HTTP/3 is available, the failure rate, and the regional distribution, rather than requiring all requests to showh3.

Is it worth changing CDNs for HTTP/3?

It is not advisable to conclude that one CDN is faster than another simply because it supports HTTP/3.

Compared with protocol names, the following factors are usually more important:

• whether nodes are close to target users;

• whether carrier routes are stable;

• whether DNS routing is accurate;

• whether the cache hit ratio is high enough;

• whether edge node load is stable;

• whether the origin fetch path is reasonable;

• whether TLS handshake and TTFB are normal;

• whether P95 gets out of control during peak hours;

• whether HTTP/3 is truly available in core regions.

A CDN with unsatisfactory node coverage and routing will not automatically become faster just by enabling HTTP/3. Conversely, a CDN using HTTP/2 but with closer nodes, a higher cache hit ratio, and better carrier interconnection may well deliver a better real-world experience.

When selecting a CDN, you can first use active probing to compare the baseline performance of HTTP/2 and HTTP/3 in different regions, and then use RUM to verify the benefits for real users. For the respective roles of the two types of data, refer toWhat Is the Difference Between Active Probing and Real User Monitoring (RUM)? Which One Should You Trust When Choosing a CDN?.

What results should you look at in the end?

The most direct evidence for confirming whether HTTP/3 is enabled is:

The Protocol column in Chrome DevTools showsh3, or a curl build that supports HTTP/3 successfully connects via--http3-onlyand returns version 3.

To confirm whether HTTP/3 brings actual value, you need to continue comparing:

• the success rates of HTTP/2 and HTTP/3;

• first connection time;

• TTFB;

• full page load time;

• P50, P95, and P99;

• differences between mobile networks and fixed broadband;

• performance by region and carrier;

• real user experience metrics such as LCP.

HTTP/3 is not a button that guarantees a speed boost once enabled. It is more like adding a more resilient transport path to a CDN under conditions of high latency, packet loss, and network switching.

If a stable network improves by only 2%, but P95 for mobile users drops by 15%, this optimization may still be very valuable; if the protocol shows ash3, but real users' TTFB and page experience do not improve, then continuing to optimize nodes, caching, origin fetches, and page resources is often more important than pursuing a protocol name.

Frequently Asked Questions

1. Is HTTP/3 always faster than HTTP/2?

Not necessarily. In environments with low latency, low packet loss, and reusable connections, the difference may be very small. The advantages of HTTP/3 are usually more evident on high-latency networks, networks with packet loss, and mobile networks.

2. The response header has Alt-Svc, so why does Chrome still show h2?

The current request may first obtainAlt-Svcinformation over HTTP/2, and only subsequent requests attempt HTTP/3; alternatively, UDP 443 may be restricted, the browser may have disabled QUIC, or a fallback may have occurred after an HTTP/3 connection failure.

3. What should I do if I cannot find the Protocol column in Chrome?

Go to the Network panel in DevTools, right-click in the request list header, and then check Protocol. In some interfaces with a smaller width, this column may be hidden by default.

4. curl reports that it does not support--http3-onlyWhat should I do?

This indicates that the current curl build does not include HTTP/3-related functionality. You need to install a curl with QUIC and HTTP/3 support; you cannot judge based only on the curl version number.

5. Why is the homepage h3, but some images are h2?

These resources may come from different domains, different CDNs, or different configurations. Each resource domain must independently support and successfully negotiate HTTP/3.

6. HTTP/3 uses UDP. Is it less secure than TCP?

Using UDP does not reduce transport security. QUIC integrates TLS 1.3, and HTTP/3 traffic content is still encrypted and authenticated. UDP is only a different transport method.

7. Does enabling HTTP/3 require modifying the origin?

When using a CDN, in many cases you only need to enable HTTP/3 from the client to the edge node on the CDN side; the origin does not have to support it directly. However, the specifics also depend on the CDN product, domain certificate, and node configuration.

8. Which websites should prioritize testing HTTP/3?

Websites with many mobile users, significant cross-border access, many concurrent page resources, and greater user network fluctuation are more worth testing first. Download sites, image sites, cross-border e-commerce, and global SaaS can also focus on long-tail improvements.