HTTP/2 and HTTP/3 for Web Performance: What Changes for PageSpeed Monitoring

A CDN panel can show HTTP/3 as “on” while a PageSpeed Insights run still finishes over HTTP/2. A share of Chrome field users never negotiate QUIC at all. That gap is the monitoring problem, not another primer on multiplexing and UDP. Agencies need the narrower reading: what changes for PageSpeed monitoring when the edge starts advertising h3, how http2 vs http3 shows up in lab versus field, and how to avoid selling a Core Web Vitals win that never left the settings screen.

The fuller handshake and CDN walk already lives in Network Performance: DNS, TLS, HTTP, CDN, and Cache Rules; this piece owns the protocol flip after that guide. Whether handshake gains survive the next navigation is mostly a cache question, covered in Cache-Control Headers for Web Performance. And if you are still pasting one-off lab screenshots into retainers, PageSpeed Insights vs Automated Monitoring and When to Use Synthetic vs Real User Monitoring explain why a schedule beats a single capture.

What HTTP/2 and HTTP/3 change for Core Web Vitals

HTTP/2 and HTTP/3 both multiplex many requests over one connection, so browsers spend less time opening parallel TCP sockets the way HTTP/1.1 often did. HTTP/2 still rides TLS over TCP. Lose a packet and more of that connection can stall, even though the HTTP streams themselves are multiplexed. HTTP/3 keeps the same HTTP semantics but runs over QUIC on UDP. Streams recover more independently under loss, and cold paths can cost fewer round trips when the stack and the network cooperate.

For Core Web Vitals the wins are usually small and conditional. Time to First Byte (TTFB) can move when cold connection setup was a real share of the wait, especially on higher-latency or lossy mobile paths. Largest Contentful Paint (LCP) follows when that earlier byte time, or faster parallel fetches of the LCP resource and critical CSS, sat on the critical path. Interaction to Next Paint (INP) and Cumulative Layout Shift (CLS) almost never budge from a protocol toggle alone; they track main-thread work and layout stability. If the origin takes a second to build HTML, HTTP/3 will not invent a fast document.

So http3 performance is a delivery upgrade, not a substitute for image weight, render-blocking CSS, or third-party script cost. It removes avoidable setup and loss penalties when the rest of the stack is already roughly healthy. Agencies that treat the CDN toggle as a Core Web Vitals project usually learn that in the first week of honest measurement.

HTTP/2 vs HTTP/3 (and QUIC): where gains usually show

Public guidance and measurements keep landing on the same boring truth: QUIC web performance is path-dependent. Awkward networks show gains more often. On an already fast, nearby CDN edge the difference can be small, neutral, or occasionally slightly worse once user-space QUIC cost is counted. That is why a single homepage lab run after flipping a Cloudflare or host “HTTP/3” switch is a weak proof for a portfolio retainer.

Browsers discover HTTP/3 differently too. Many Chrome navigations still learn from Alt-Svc after an earlier connection rather than opening QUIC on the absolute first hit; Safari leans more on HTTPS DNS records where those exist. Field cohorts therefore mix h2 and h3 users even when the edge “supports HTTP/3.” Treating every CrUX percentile as an HTTP/3 story is usually wrong.

What PageSpeed Insights measures when the edge speaks h3

PageSpeed Insights and Lighthouse report page-level outcomes: Performance score, LCP, TBT, CLS, related lab timings, and field CrUX when the URL qualifies. They are not a native “HTTP/3 vs HTTP/2 A/B” product. An HTTP/3 PageSpeed win in a client deck still needs a protocol check on the same capture, because the lab run uses whatever the test agent negotiates for that session. If the agent stays on HTTP/2, your PDF shows HTTP/2 behaviour even while marketing copy says HTTP/3 is live.

That gap cuts both ways for agencies:

1. False credit. Lab LCP improves the same week HTTP/3 was enabled, but the waterfall still shows h2, or the improvement came from a concurrent image or cache change.

2. False blame. Field mobile LCP looks worse than desktop lab after an HTTP/3 launch, because a slice of users never get QUIC, or because the real bottleneck was never the handshake.

Synthetic locations add another twist. A US or EU lab profile on a clean network understates the paths where QUIC helps most, so aligning lab regions with traffic share still matters more than chasing a universal protocol win. Synthetic vs real-user monitoring is the longer treatment of that lab/field split. The extra rule here is simple: record which protocol the lab session used before you narrate a protocol victory.

How to verify the protocol path after an HTTP/3 toggle

After the edge change, a useful agency check looks like this:

1. Confirm advertisement. Response headers should include an Alt-Svc (or equivalent) that names h3 on the expected port, or HTTPS DNS records that advertise HTTP/3 where you rely on that path. If nothing advertises h3, browsers will not magically upgrade.

2. Confirm negotiation in a real browser. Chrome DevTools Network (protocol column) or PerformanceNavigationTiming.nextHopProtocol / resource timing nextHopProtocol values such as h3 versus h2 tell you what that navigation actually used. Empty protocol strings mean the browser would not expose the value; they are not proof of HTTP/1.1.

3. Confirm the lab path. Repeat PageSpeed Insights or Lighthouse from the same location before and after, and note the protocol on the document and LCP request when the tool exposes it (or capture a parallel DevTools session against the same URL). Several runs beat one screenshot.

4. Watch field with lag. CrUX and Search Console will not rewrite overnight. Leave the toggle annotated on the monitoring calendar the way you annotate CDN or TLS changes in the network performance guide.

5. Keep HTML cache policy honest. Handshake gains vanish if every navigation revalidates a heavy document. Pair protocol work with the Cache-Control rules for HTML versus fingerprinted assets.

UDP reachability still fails on some corporate and captive networks. Fallback to HTTP/2 is normal, not a misconfiguration by itself. The report should say “HTTP/3 available and used by a share of Chrome users,” not “everyone is on QUIC now.”

What to put in the client report when HTTP/3 ships

Client language that ages well:

• What changed: edge or origin now advertises HTTP/3 (Alt-Svc / DNS), date of change, who approved it.

• What we measured: lab URLs, locations, Lighthouse or PageSpeed Insights versions, and whether those runs negotiated h3 or h2.

• What field shows: CrUX or RUM percentiles for LCP/INP/CLS on the same templates, with the usual lag caveat.

• What we are not claiming: a protocol toggle as the cause of a score move unless protocol and timing evidence line up.

If lab never saw h3, say so. If field is mixed, say so. A slight TTFB improvement on mobile lab profiles with flat LCP is still a useful, honest outcome. Over-claiming is how the next CDN ticket opens with “but you said HTTP/3 would fix LCP.”

Scheduled monitoring is what makes that honesty cheap. A dated lab column on priority URLs catches the week someone disables HTTP/3, breaks Alt-Svc, or “optimises” cache rules in the same sprint. Field rows keep the visitor story visible when synthetic paths stay privileged. Apogee Watcher is built for that multi-tenant schedule across client properties: recurring PageSpeed-oriented checks, history for the retainer PDF, and alerts when a template drifts after an edge change. Protocol upgrades do not replace that layer. They make the annotation habit more important.

FAQ

Does HTTP/3 always improve PageSpeed Insights scores?
No. Gains are conditional, often small on already fast edges, and the lab agent may still use HTTP/2. Verify negotiation before you credit the toggle.

What is the difference between HTTP/2 and HTTP/3 for agencies?
Both multiplex requests. HTTP/3’s QUIC transport can help more under loss and high latency, with UDP and discovery trade-offs. Monitoring must record which protocol each test and cohort actually used.

Will enabling HTTP/3 fix LCP?
Only when connection setup or multiplexed fetches were on the LCP critical path. Slow origin HTML, huge heroes, and render-blocking CSS remain the usual causes.

How do we prove QUIC web performance to a client?
Show advertisement (Alt-Svc or DNS), negotiation (nextHopProtocol / DevTools), dated lab before/after on the same URLs, and field percentiles with lag. Skip screenshots that omit protocol.

Should every site turn on HTTP/3?
Most modern CDN-backed sites can advertise it safely with fallback. Measure; do not assume a universal win. Keep fallback paths and do not weaken TLS or cache discipline to “make QUIC look good.”

Ship the toggle, then keep the schedule honest

Agency technical leads who inherit an HTTP/3 launch can treat protocol as one annotated delivery change among many. Confirm advertisement and negotiation, run the same lab URLs before and after, and leave field time to move. Refuse to collapse lab Performance and CrUX into one unverified sentence. That is how http3 performance stays an operations story instead of a checkbox in the CDN UI.

When spreadsheets stop scaling, that lab history and those regression alerts across client sites after edge changes are what Apogee Watcher is for. Start a trial or run a free PageSpeed check on the templates you care about most. Leaving HTTP/3 undocumented in the monitoring calendar is how the next PDF invents a win the waterfall never showed. It is also how the next edge ticket starts from argument instead of evidence.

References

• Network Performance: DNS, TLS, HTTP, CDN, and Cache Rules (Apogee Watcher)

• Cache-Control Headers for Web Performance (Apogee Watcher)

• PageSpeed Insights vs Automated Monitoring (Apogee Watcher)

• When to Use Synthetic vs Real User Monitoring (Apogee Watcher)

• HTTP/3 explained (Daniel Stenberg / community reference)

• A QUIC progress report (APNIC Blog)

• Resource Timing Level 2 (nextHopProtocol) (W3C)