Independent comparison · no paid rankings
Home / Blog / HTTP/3: visible speedup or premature optimization?
Guide

HTTP/3: visible speedup or premature optimization?

HTTP/3 and QUIC promise lower latency on unstable networks. On a site already fast over HTTP/2 with healthy TTFB, gains are often marginal — sometimes negative if origin stays slow.

3 min read Updated Apr 18, 2026

The tech lead checks "Enable HTTP/3" in the CDN. Lighthouse gains three points. Server TTFB did not move: 890 ms on the cart page. Management concludes "hosting is slow". In reality, HTTP/3 mostly optimises transport — not PHP generation or an overloaded database.

HTTP/3 runs on QUIC (UDP) rather than TCP. It cuts handshake round trips, handles packet loss better on mobile and network changes (Wi‑Fi → 4G). A useful evolution — not a magic wand for uncached WordPress.

What HTTP/3 improves — and what it ignores

LayerHTTP/3 helps?Example
TLS handshake + transportYesFaster connect on unstable 4G
Request multiplexingYes (like h2)Many small assets
PHP / SQL TTFBNoSlow dynamic page
Image / JS weightNoHigh LCP
Slow DNSNoResolution before QUIC

On a static CDN-served site with many short connections, HTTP/3 may shave 50–150 ms perceived latency. On a slow origin admin or heavy POST API, effect is invisible.

When enabling makes sense

Yes, enable if:

  • Origin TTFB already acceptable (< 400 ms dynamic or effective cache).
  • Significant mobile traffic, international audience.
  • CDN handles QUIC without complex server config.
  • You measure with RUM before/after.

Defer if:

  • OPcache off, no page cache, slow SQL.
  • You have not fixed Core Web Vitals LCP/CLS yet.
  • Host advertises HTTP/3 but forces a misconfigured proxy (loops, bad headers).

Typical deployment: CDN vs origin

Most HTTP/3 sites use a CDN:

  1. Visitor ↔ edge QUIC (HTTP/3)
  2. Edge ↔ origin often still HTTP/1.1 or HTTP/2

The host "supports HTTP/3" via CDN partner, not necessarily bare VPS. Check contract: TLS termination where, certificates, cache rules.

Minimal test:


curl --http3-only -sI https://example.com | head -5

Compare --http2 and --http1.1 on the same static asset.

The peak: optimising protocol before application

CDN marketing loves "HTTP/3 ready". It does not replace OPcache, SQL indexes or image compression.

Decide and move forward without blind spots

  1. Measure origin TTFB and current LCP.
  2. Fix PHP, cache, assets if TTFB > 600 ms or LCP red.
  3. Enable HTTP/3 via CDN; compare mobile RUM over 7 days.
  4. Document edge vs origin protocol for support.

Compare compatible hosts and CDNs via the directory and comparator.

Frequently asked questions

Is HTTP/3 mandatory in 2026?

No — prioritise TTFB and content before QUIC if the server is the bottleneck.

Shared host offers HTTP/3 — enable?

Yes as risk-free toggle with measurement; no if it avoids real origin diagnosis.

HTTP/3 without CDN?

Possible at origin (Nginx/Caddy), but rare in practice — most use CDN edge.

How to test HTTP/3?

DevTools Protocol h3 or curl --http3-only; compare to h2.


Before celebrating HTTP/3, one question: is origin TTFB already green? Otherwise you mostly speed up a PHP queue — not the network.

Compare European hosts

Filter by compliance, location and use case — then open the sheets to verify the real scope.

Browse the directory
Blog

Related reading

All articles →