WordPress HTML protocol and the Core Web Vitals
HTTP/2, HTTP/3, or HTTP/1.1 on the main HTML document: how the protocol changes Time to First Byte (175 ms faster on HTTP/3) and how much comes from edge CDNs.
On WordPress, 71.8% of sites serve their main HTML document over HTTP/2, 20.9% use HTTP/3 over QUIC, and 7.3% still use HTTP/1.1. On HTTP/3, 73% of WordPress sites have a good LCP, against 69% on HTTP/2 and 68% on HTTP/1.1. In Chrome's field data, HTTP/3 cuts median Time to First Byte by 175 ms compared with HTTP/2 (979 ms against 1154 ms).
LCP pass rate
Sites serving their HTML over HTTP/3 (h3) have a good LCP most often at 73%, followed by HTTP/2 (h2) at 69% and HTTP/1.1 at 68%.
HTML document protocol usage
Across 63,295 audited WordPress sites, HTTP/2 (h2) is the default protocol on 71.8% of sites. HTTP/3 (h3) serves 20.9% (13,203 sites), and HTTP/1.1 still serves 7.3% (4,626 sites).
TTFB and the four LCP phases by HTML protocol
HTTP/3 wins its LCP lead in Time to First Byte. Median field TTFB drops from 1154 ms on HTTP/2 and 1108 ms on HTTP/1.1 to 979 ms on HTTP/3. Over TCP, HTTP/2 needs a TCP handshake before TLS can finish. Over UDP, QUIC combines TCP and TLS setup into one round trip (or zero on a repeat visit).
HTML protocol paired with edge CDN
More than half of all HTTP/3 sites (33%) serve their main HTML through an edge CDN, compared with only 9% of HTTP/2 sites. Comparing protocol versions on the same delivery path separates QUIC from edge caching. On sites served straight from the origin server, HTTP/3 still cuts median TTFB from 1148 ms to 967 ms and reaches 73% on LCP (against 69% on HTTP/2). On Cloudflare, HTTP/3 cuts median TTFB to 1012 ms and reaches 74%, against 1227 ms and 64% on Cloudflare HTTP/2. Fastly HTTP/3 reaches 1307 ms TTFB and 64%.
| HTML protocol | Origin (no edge CDN) | Cloudflare | Fastly | CloudFront | Akamai |
|---|---|---|---|---|---|
| HTTP/3 (h3) | 73% 8,893 sites | 74% 3,419 sites | 64% 156 sites | 73% 364 sites | 78% 359 sites |
| HTTP/2 (h2) | 69% 41,429 sites | 64% 1,687 sites | 67% 641 sites | 64% 758 sites | 67% 918 sites |
| HTTP/1.1 | 67% 4,149 sites | 68% 215 sites | 72% 77 sites | 70% 108 sites | 67% 73 sites |
HTML document protocol per framework
Alpine serves the main HTML over HTTP/3 on 30% of its sites, and 78% of Alpine sites have a good LCP. jQuery serves HTTP/2 on 72% of its sites, HTTP/3 on 21%, and HTTP/1.1 on 7%, and 69% of jQuery sites have a good LCP.
HTML protocol or the framework
Does the framework explain the HTTP/3 pass rate?
On jQuery, 73% of sites served over HTTP/3 have a good LCP, against 67% of jQuery sites on HTTP/2. Within jQuery, HTTP/3 beats HTTP/2 by 6 percentage points. On Vue, 71% of sites served over HTTP/3 have a good LCP, against 67% of Vue sites on HTTP/2. Within Vue, HTTP/3 and HTTP/2 sites have a good LCP about equally often.
Why HTTP/3 needs an HTTPS DNS record to help the first visit
A cold HTTP/2 connection takes two round trips before the browser can request the HTML: one for TCP and one for TLS. HTTP/3 runs over QUIC and finishes connection and TLS setup in one round trip. Even without an edge CDN, that cuts median origin TTFB from 1148 ms on HTTP/2 to 967 ms on HTTP/3. On a first visit, though, most servers only advertise HTTP/3 through the Alt-Svc response header. The browser only sees that header after the first HTML response has already arrived over HTTP/2. Publishing an HTTPS (type 65) DNS record with alpn="h3" tells the browser to use HTTP/3 on the very first request.
Understanding HTML document protocol
Put Cloudflare, Fastly, or a QUIC-enabled web server (LiteSpeed, Caddy, or nginx 1.25+) in front of WordPress and publish an HTTPS DNS record with alpn="h3". On WordPress, 20.9% of sites serve their HTML over HTTP/3 and reach 73% good LCP (979 ms median TTFB), compared with 69% on HTTP/2 (1154 ms TTFB). Even on direct origin servers without an edge CDN, HTTP/3 trims 181 ms off median TTFB by removing a handshake round trip. Pair HTTP/3 with full-page HTML caching (WP Rocket, FlyingPress, or Cloudflare APO) so the server does not rebuild PHP on every cold visit.
By Arjen Karel · 63,295 crawled WordPress sites (36,524 with phone Chrome field data, October 2026). How we measured.