WebView性能埋点需原生与H5协同：仅window.performance不准确，必须结合onPageStarted、onReceivedHttpError、onPageFinished等原生生命周期打点，并注入webview_id、is_x5_kernel、load_strategy三字段，才能真实还原加载耗时。
WebView容器内HTML性能埋点不能只靠前端window.performance，必须结合原生层时机打点才能拿到真实加载耗时——因为WebView的onPageFinished触发时机晚于页面视觉可交互时间，且不包含JS执行阻塞、渲染合成等关键阶段。
WebView侧关键生命周期打点位置
原生层是唯一能准确捕获WebView底层加载阶段的位置。仅依赖H5侧performance.timing会漏掉WebView初始化、DNS预解析、TTFB前的Native开销。
-
onPageStarted：标记导航开始，此时URL已确定但网络请求未发，适合记录“点击到发起”延迟 -
onReceivedHttpError：捕获HTTP层失败（如404/503），比JS侧fetch错误更早，且覆盖iframe资源 -
onPageFinished：注意它不等于页面可交互，常比domInteractive晚200~800ms，仅作兜底指标 - 配合
WebChromeClient.onProgressChanged：当进度达90%时大概率DOM已就绪，可作为首屏渲染近似锚点
H5侧Performance API必须补全的三项原生参数
单纯上报performance.getEntriesByType('navigation')[0]在WebView中会缺失关键上下文，必须由Native注入以下字段，否则无法归因：
-
webview_id：每个WebView实例唯一ID，用于区分多Tab、弹窗WebView等并发场景 -
is_x5_kernel：布尔值，X5内核下navigationStart可能比系统WebView早100~300ms，影响TTFB计算 -
load_strategy：取值preconnect/preload/lazy，决定资源加载优先级，直接影响resource.duration分布
这些字段需在WebView.evaluateJavascript注入全局变量，或通过JSBridge透传，不能靠navigator.userAgent推断。
立即学习“前端免费学习笔记（深入）”；
首屏渲染时间（FCP）在WebView中的特殊处理
WebView不支持PerformanceObserver监听largest-contentful-paint，且requestAnimationFrame在JS线程阻塞时失效。可靠方案是混合打点：
- Native层用
PixelCopy截图检测首帧像素变化（Android 10+），阈值设为画面非纯色区域占比＞15% - H5侧用
document.readyState === 'interactive'+setTimeout(() => {}, 0)模拟FCP，但需过滤掉document.hidden === true的后台页 - 两者时间差＞300ms时，说明JS执行严重阻塞渲染，需单独告警而非修正FCP值
跨域资源加载耗时采集的陷阱
当H5页面引入CDN资源（如https://cdn.example.com/script.js），performance.getEntriesByType('resource')可能返回空数组——WebView默认禁用跨域资源Timing API。
- Android需在
WebSettings.setAllowUniversalAccessFromFileURLs(true)后才生效，但该开关有XSS风险，仅限调试环境开启 - 生产环境必须改用X5内核，并调用
TbsVideoLoadListener监听资源加载状态，其回调含真实transferSize和duration - 对
img标签，可用onload事件打点替代，但要防重复（decode()可能触发二次加载）
真正难的是复现：白屏时performance对象本身可能未初始化，所以所有H5侧打点必须包裹if (window.performance)判空，且Native层要保留onPageStarted到onReceivedError的原始时间戳作为最后防线。
