HTTP/3 Load Testing: Cloud Practices in 2026

Key Takeaways

• Most load testing tools speak HTTP/1.1 and HTTP/2. I found no HTTP/3 support in the k6, JMeter, Gatling or Locust documentation (read October 2026), so a test against an HTTP/3-fronted site usually runs over HTTP/2 over TCP.
• That is still a useful test of your origin, application and CDN capacity. It does not measure the QUIC handshake, behaviour under UDP blocking or the other things that are specific to HTTP/3.
• Always check which protocol a run actually used. In k6 it is one line: res.proto.
• The tools that do speak HTTP/3 (curl, h2load, browsers) can sample it. There is no stock way to generate large HTTP/3 load from the main open-source load testing tools.

HTTP/3 load testing means generating load over HTTP/3, that is, HTTP mapped onto QUIC over UDP (RFC 9114). With the main tools that is mostly not possible today without an experimental extension or a different generator, and browsers already use HTTP/3 where a site offers it. So the practical job is to know which protocol your test used, test the origin with the tool you have, and sample HTTP/3 separately with tools that support it.

What does an HTTP/3 load test actually measure?

An HTTP/3 test measures the same things as any load test (response time percentiles, errors, throughput) plus four effects that come from the protocol. RFC 9114 and RFC 9000 are the primary sources for all four.

Two limits to keep in mind. First, the handshake and stream effects show up mostly on lossy or high-latency paths, and a load generator in a data centre has a clean path to your servers. A clean-network run says little about what a phone on a congested mobile network sees. Second, I am not quoting speed-up figures: the gain depends on the network, the page and the server, and a number from someone else’s site is not yours. Measure your own with a controlled comparison.

Which tools can generate HTTP/3 load?

I checked each tool’s own documentation or repository in October 2026. “Not documented” means I read the relevant reference pages and found no mention of HTTP/3 or QUIC; it does not prove the feature is absent in every build or plugin.

The extension row deserves a caution. A load test needs a client you can trust under load, and a single-author experiment last updated in 2023 is a risk you would have to validate yourself. The two tools that are designed to speak HTTP/3 from the command line, curl and h2load, are better for sampling and for small, repeatable comparisons than for a full user journey.

How do I check which protocol my load test used?

Do not assume. A server that advertises HTTP/3 does not mean your client used it. An origin advertises it with an Alt-Svc response header carrying the h3 token, and a client then may try QUIC (RFC 9114, section 3.1.1). A client that cannot speak QUIC ignores the header.

In k6, the response object has a proto field. I ran this against a public site that advertises HTTP/3:

import http from 'k6/http';

export default function () {
  const res = http.get('https://www.cloudflare.com/');
  console.log(`status=${res.status} proto=${res.proto} alt-svc=${res.headers['Alt-Svc']}`);
}

Output (k6 v1.7.1, 2026-10-23): status=200 proto=HTTP/2.0 alt-svc=h3=":443"; ma=86400. The server offered HTTP/3 and k6 used HTTP/2. Add a check on res.proto to your own scripts so a result file states the protocol it measured. The k6 protocols page says the verification “requires an extra step”, which is this one.

With curl, curl -sI https://example.com/ | grep -i alt-svc shows whether the origin advertises h3. For a transfer over HTTP/3, curl --http3-only -sI https://example.com/ fails instead of falling back, so it proves the path works. I could not run --http3-only here because the curl on this machine was built without HTTP/3 (its feature list shows HTTP2 only), so the flags come from the manual page and not from a run of mine.

How do I test a site behind an HTTP/3 front end with an HTTP/2 tool?

Say plainly in the report that the generator measured HTTP/2 while browsers will use HTTP/3, then decide what the HTTP/2 test is for. It is a valid test of everything behind the protocol: origin CPU and memory, application and database behaviour, CDN or load balancer capacity, rate limits, and the TCP path that every client without UDP uses anyway. HTTP/3 changes the transport between the user and the edge. It does not change what your application does with a request.

Then add what the generator cannot show:

• Sample HTTP/3 separately. Run small curl or h2load comparisons of --http2 against --http3 from the same machine and place, many times, and report percentiles. Treat them as samples, not load.
• Read real traffic. Your CDN or server logs record the protocol of each request, so the share of HTTP/3 and fallback in production is a measurement, not a guess. Real user monitoring in browsers covers what generators cannot.
• Keep the TCP path healthy. Where UDP is blocked or rate limited, RFC 9114 says clients fall back to TCP, so your HTTP/2 capacity is also your fallback capacity.
• Model the network, not only the protocol. Latency and packet loss are where the two protocols differ, so run from distant regions and, where you can, add emulated loss at the client. The network latency and network jitter posts cover how to do it and report it.

What can go wrong with HTTP/3 in production?

Beyond speed, the failures are about UDP. Firewalls and some corporate networks may block or throttle UDP on port 443, in which case clients fall back to TCP after a delay and the user sees a slower first connection. Load balancers and CDNs differ in how they handle QUIC, so the HTTP/3 path can have a different capacity limit than the HTTP/2 path. A staged check is cheap: confirm Alt-Svc is present, confirm a real HTTP/3 transfer with curl or a browser, then watch the share of requests per protocol in your logs after a change.

How does this look with LoadFocus?

LoadFocus runs JMeter and k6 scripts from 25 cloud regions (loadfocus.com/load-testing, October 2026). The pages I read do not mention HTTP/3, and its k6 page says it supports the standard k6 features, which puts the generators on what k6 itself speaks: HTTP/1.1 and HTTP/2. Ask support before relying on anything else. So a LoadFocus run against an HTTP/3-fronted site is the HTTP/2 test described above, with the benefit of load from several regions, which matters because latency is where protocols differ. Use k6 load testing or JMeter load testing for that, and sample HTTP/3 with curl or a browser alongside it. The protocols post compares what each protocol needs from a test, and k6 vs JMeter helps choose a generator.

Frequently Asked Questions

Does k6 support HTTP/3?

Not out of the box. The k6 protocols page lists HTTP/1.1, HTTP/2, WebSockets and gRPC, and the project’s HTTP/3 pull requests were closed without merging. An experimental community extension, xk6-http3, exists; its last commit was in December 2023.

Does JMeter support HTTP/3?

I found no mention of HTTP/3 or QUIC in the JMeter component reference or its changes history (current release 5.6.3). Third-party plugins may exist, and I did not verify any, so test one carefully before using it.

How do I know my load test used HTTP/3?

Check the protocol the client reports. In k6 that is res.proto, which showed HTTP/2.0 against a site that advertises HTTP/3. With curl, --http3-only fails instead of falling back. Never infer it from the server’s Alt-Svc header alone.

Is HTTP/3 faster than HTTP/2?

It depends on the network, the page and the server, and I have no figure to give you for your site. The protocol removes blocking between streams on packet loss and shortens connection setup, but on a clean, low-latency path the difference can be small. Measure your own traffic with a controlled comparison.

Is HTTP/2 load testing still worth doing?

Yes. Clients fall back to TCP-based HTTP when UDP is blocked, and everything behind the protocol (application, database, origin capacity) is the same either way.

Which tool should I use to generate HTTP/3 traffic?

For sampling, curl or h2load built with HTTP/3 support (h2load calls it experimental). For full user journeys at scale there is no stock option among the main open-source load testing tools in the documentation I read.

Sources

• RFC 9114, HTTP/3 (sections 3.1, 3.1.1 and the streams paragraph; read 2026-10-23)
• RFC 9000, QUIC: A UDP-Based Multiplexed and Secure Transport (0-RTT, UDP; read 2026-10-23)
• Grafana k6 docs: protocols (grafana.com/docs/k6/latest/using-k6/protocols) and grafana/k6 issues 2407, 3507 and 5628 on GitHub (read 2026-10-23)
• xk6-http3 repository (read 2026-10-23)
• JMeter component reference and changes (searched for HTTP/3 and QUIC, 2026-10-23)
• Gatling HTTP protocol reference and Locust documentation (searched for HTTP/3 and QUIC, 2026-10-23)
• h2load HTTP/3 how-to and curl manual (read 2026-10-23)
• Can I use: HTTP/3 data file (read 2026-10-23)
• Local test: k6 v1.7.1 against a public site, 2026-10-23

Related reading

• 5 Top gRPC Load Testing Tools
• Vegeta Load Testing Tutorial: Rates, Targets, Reports
• Quantum Computing and Cloud Testing: Post-Quantum TLS