页面可用性监控需基于真实用户路径，结合Navigation Timing API、fetch/XHR拦截及可见性与交互状态综合判定，避免仅依赖HTTP状态码或ping导致90%误报。
页面可用性监控不是测“能不能打开”，而是确认用户真实访问时是否能完成关键路径——比如按钮可点、表单可提交、核心API返回200。只靠HTTP状态码或ping检测，90%会误报。
用Navigation Timing API捕获真实加载失败
单纯检查performance.getEntriesByType('navigation')里的responseEnd是否为0，会漏掉大量软失败：SSL握手超时、DNS解析卡住、TCP连接被RST、甚至CDN回源失败但返回了兜底HTML。必须结合type和nextHopProtocol字段交叉判断：
-
entry.type === 'navigate'且entry.encodedBodySize === 0→ 很可能没拿到任何HTML内容 -
entry.nextHopProtocol === ''或entry.nextHopProtocol === 'http/1.0'→ 协议协商异常，常见于中间设备拦截 -
entry.responseStart === 0且entry.domainLookupStart > 0→ DNS成功但后续链路断在TCP或TLS层
不要等load事件——很多失败发生在domContentLoaded之前，此时performance.getEntriesByType('navigation')已存在有效条目。
监听fetch/XHR失败并归因到具体资源
页面“打不开”往往不是HTML加载失败，而是关键JS/CSS/字体/接口挂了。但fetch和XMLHttpRequest的错误不会自动触发error事件，必须手动拦截：
使用 Puppeteer + Chrome 将 HTML 渲染为中文 PDF，自动处理图表等待、Tab 展开、动画、测高、白边消除、防分页，适用于看板、报表、网页和交互图表转 PDF。
立即学习“前端免费学习笔记（深入）”；
- 重写
window.fetch，捕获network error、TypeError及非2xx/3xx响应体 - 给
XMLHttpRequest.prototype.open打补丁，在send后监听onerror和onload，检查status和statusText - 过滤掉监控探针自身请求（如
/healthz、/ping），避免污染数据
上报时必须带url、method、status、duration、initiatorType（script/style/link等），否则无法区分是业务接口还是第三方SDK拖垮了可用性。
用Page Visibility + IntersectionObserver防伪“在线”
很多监控系统把document.visibilityState === 'visible'当成页面“可用”，但iOS Safari在App切后台后仍长期维持该状态；Chrome冻结标签页时也会保持visible。真正的可用性要叠加用户意图：
- 仅当
document.visibilityState === 'visible'且 核心区域（如#main-content）在视口内（用IntersectionObserver判定）时，才认为页面处于可交互状态 - 若连续5秒
intersectionRatio ，即使<code>visibilityState为visible，也应标记为“不可见可用”，不计入uptime统计 - 对SPA应用，每次
pushState后需重置可见性观察器，否则路由切换后旧观察器仍绑定在已移除的DOM节点上
别信online事件——它只反映浏览器网络栈是否通，和页面能否渲染、JS能否执行完全无关。真正要盯的是用户手指点下去那一刻，有没有东西响应。
