performance.getEntriesByType('navigation') 不直接标注 HTTP/3，但通过 nextHopProtocol（值为"h3"）、domContentLoadedEventStart 和 loadEventStart 可分析其首屏收益；高 RTT 或丢包场景下，HTTP/3 通常提升 150–300ms。
performance.getEntriesByType('navigation') 返回的是页面导航生命周期的完整性能快照，其中包含大量与协议层密切相关的字段。它本身不直接标注“用了HTTP/3”，但通过组合分析关键指标与网络行为特征，能清晰定位 HTTP/3 带来的实际首屏收益。
重点看这三项字段：domContentLoadedEventStart、loadEventStart 和 nextHopProtocol
-
nextHopProtocol是最直接的线索：值为"h3"表示该导航请求走的是 HTTP/3；"h2"或"http/1.1"则对应旧协议。注意：它反映的是主文档（HTML）的加载协议，不是所有资源。 -
domContentLoadedEventStart标志首屏可交互时间点，受 HTML 解析、关键 CSS/JS 加载影响，而 HTTP/3 的 0-RTT 和无队头阻塞会明显压缩这个过程。 -
loadEventStart反映整体资源就绪时间，对含大量图片、字体等非关键资源的页面更敏感，HTTP/3 的并行流优势在此处放大。
结合网络环境做归因分析，比单纯看数字更有说服力
- 在高 RTT（如跨洲访问）或中高丢包率（>2%）场景下，对比
nextHopProtocol === 'h3'和'h2'的domContentLoadedEventStart差值，常可观测到 150–300ms 提升。这是 0-RTT 连接 + 快速恢复带来的直接收益。 - 若页面启用了
<link rel="preload">加载关键 CSS/JS，且这些预加载请求也走 HTTP/3（可通过performance.getEntriesByType('resource')验证），则domContentLoadedEventStart进一步提前——因为多个流独立传输，不会因某张图片丢包而卡住 JS 执行。
实操建议：用代码自动聚类对比
const navEntries = performance.getEntriesByType('navigation');
const h3Entry = navEntries.find(e => e.nextHopProtocol === 'h3');
const h2Entry = navEntries.find(e => e.nextHopProtocol === 'h2');
if (h3Entry && h2Entry) {
const dclDiff = h2Entry.domContentLoadedEventStart - h3Entry.domContentLoadedEventStart;
console.log(`HTTP/3 较 HTTP/2 缩短首屏可交互时间: ${dclDiff.toFixed(1)}ms`);
}再配合 performance.getEntriesByType('resource') 筛出 .css、.js、.woff2 等首屏关键资源，统计它们的 duration 和 nextHopProtocol，就能确认：是否关键资源真正在用 HTTP/3 加载？有没有因 CDN 配置遗漏导致部分资源降级？
注意一个常见盲区：Alt-Svc 头未生效或客户端不支持时，nextHopProtocol 仍可能显示 'h2'，即使服务端已配 QUIC。务必同步检查 Network 面板的 Protocol 列或用 curl -I --http3-only 验证服务端通告是否正确。
不复杂但容易忽略
