Wix 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 (357 ms faster on HTTP/3) and how much comes from edge CDNs.
On Wix, 1.7% of sites serve their main HTML document over HTTP/2, 96.3% use HTTP/3 over QUIC, and 2.1% still use HTTP/1.1. On HTTP/3, 94% of Wix sites have a good LCP, against 88% on HTTP/2 and 96% on HTTP/1.1. In Chrome's field data, HTTP/3 cuts median Time to First Byte by 357 ms compared with HTTP/2 (402 ms against 759 ms).
LCP pass rate
Sites serving their HTML over HTTP/1.1 have a good LCP most often at 96%, followed by HTTP/3 (h3) at 94% and HTTP/2 (h2) at 88%. HTTP/1.1 sits slightly ahead of HTTP/2 here because many HTTP/1.1 sites are small static pages. Six in seven HTTP/2 sites serve dynamic CMS pages straight from the origin server, while more than half of HTTP/3 sites sit behind an edge CDN.
HTML document protocol usage
Across 5,621 audited Wix sites, HTTP/2 (h2) is the default protocol on 1.7% of sites. HTTP/3 (h3) serves 96.3% (5,411 sites), and HTTP/1.1 still serves 2.1% (116 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 759 ms on HTTP/2 and 404 ms on HTTP/1.1 to 402 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 (74%) serve their main HTML through an edge CDN, compared with only 26% 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 717 ms to 422 ms and reaches 91% on LCP (against 89% on HTTP/2). On Cloudflare, HTTP/3 cuts median TTFB to 363 ms and reaches 94%. Fastly HTTP/3 reaches 398 ms TTFB and 96%.
| HTML protocol | Origin (no edge CDN) | Cloudflare | Fastly | CloudFront | Akamai |
|---|---|---|---|---|---|
| HTTP/3 (h3) | 91% 1,386 sites | 94% 273 sites | 96% 3,277 sites | 88% 466 sites | few sites |
| HTTP/2 (h2) | 89% 70 sites | few sites | few sites | few sites | few sites |
| HTTP/1.1 | 93% 65 sites | few sites | 100% 29 sites | few sites | few sites |
HTML document protocol per framework
React serves the main HTML over HTTP/3 on 96% of its sites, and 94% of React sites have a good LCP.
HTML protocol or the framework
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 717 ms on HTTP/2 to 422 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
Turn on HTTP/3 at your CDN or web server and publish an HTTPS DNS record with alpn="h3" so cold visitors use QUIC on their very first document request. Across this dataset, 96.3% of sites serve their HTML over HTTP/3 and reach 94% good LCP (402 ms median TTFB), compared with 88% on HTTP/2 (759 ms TTFB). Part of that 357 ms TTFB lead comes from edge CDNs, which terminate the connection close to the visitor. Even on direct origin servers without a CDN, HTTP/3 still trims 295 ms off median TTFB by removing a handshake round trip. If your HTML still runs over HTTP/1.1 (2.1% of sites), move to HTTP/2 or HTTP/3 first. Stylesheets, scripts, and the LCP image can then reuse the open document connection instead of opening six separate TCP connections.
By Arjen Karel · 5,621 crawled Wix sites (3,077 with phone Chrome field data, October 2026). How we measured.