# 1. Web Vitals Attribution 在 Sentry Performance/RUM 平台的工程价值 A Attribution 只是重复指标数值，没有额外信息 B Attribution 提供 LCP 阶段拆解、CLS 偏移源、INP 延迟拆分等归因字段，让 RUM 平台从"指标差"定位到"哪段慢、哪个元素" ✓ 正确答案 C Attribution 只能在本地开发环境使用 D Attribution 会显著降低所有页面性能，不可用于生产
# 2. PerformanceObserver type event durationThreshold 16 在 INP 监控的工程价值 A durationThreshold: 16 对应 60fps 单帧预算，只回调导致丢帧的交互事件，配合 interactionId 定位 INP 卡顿根因 ✓ 正确答案 B durationThreshold 决定事件是否记录到缓冲区，与回调无关 C 事件 entry 的 duration 不包含处理时间 D durationThreshold 值越大，采集到的事件越多
# 3. Long Tasks 与 Long Animation Frames（LoAF） A LoAF 以呈现帧为单位记录超时帧并提供 script/style/layout 归因，比 50ms 阈值的长任务更能定位卡顿来源 ✓ 正确答案 B Long Task 与 LoAF 完全等价，没有区别 C LoAF 只能记录网络耗时 D Long Task 比 LoAF 提供更细的归因字段
# 4. FCP、TTFB 与长任务的 PerformanceObserver 采集 A 三个指标都来自 paint 类型 entry B FCP/TTFB 需尽早注册 observer 并配合 buffered: true 读取，长任务是持续事件流需聚合后上报 ✓ 正确答案 C TTFB 只能通过手动打点获得 D 长任务每条都单独上报，无需聚合
# 5. LCP、INP、CLS 的真实用户监控（RUM） A LCP、INP、CLS 都在 load 事件时一次性上报最终值 B 三指标回调时机不同，INP/CLS 需在 pagehide 时用 sendBeacon 兜底上报，并做刷新/隐身页过滤与采样控制 ✓ 正确答案 C RUM 数据无需过滤刷新与后台页面 D sendBeacon 无法用于性能数据上报
# 6. Web Vitals Attribution CrUX API 在 Chrome 用户体验报告的应用 A CrUX 提供单用户实时会话级数据 B CrUX 只包含桌面端数据 C CrUX 数据可以精确到每一个 URL 的每一次访问 D CrUX 基于 Chrome 真实用户的大样本分位值提供全网基准，与自有 RUM 互补：CrUX 看趋势广度，RUM 看样本深度 ✓ 正确答案
# 7. 自定义指标（业务关键操作时长）的 PerformanceObserver 与 mark/measure A performance.mark 只能用于浏览器内置指标 B buffer 中的 entry 会被无限期保留，无需处理 C measure 不需要 mark 支持即可直接创建 D 用 mark/measure 圈定业务操作起止，PerformanceObserver 消费 measure entry 并按采样与分位聚合上报，同时管理 buffer 与命名规范 ✓ 正确答案
# 8. INP 的 attribution（Input Delay/Processing/Presentation Delay） A INP 只测量事件处理器的执行时间 B Presentation Delay 与渲染无关 C Input Delay 是处理器开始前的等待（主线程繁忙所致），Processing 是处理器执行，Presentation Delay 是到帧呈现的渲染时间，按段归因可定位交互卡顿根因 ✓ 正确答案 D 三段延迟只能整体优化，无法分别定位
# 9. LCP Element Identification 与 LargestContentfulPaint 的 element render time A LCP entry 提供 element 与 loadTime/renderTime，可区分图片下载慢还是渲染阻塞，并用稳定标记上报元素归类 ✓ 正确答案 B LCP entry 不包含元素信息，只能看到数值 C renderTime 与 loadTime 对所有 LCP 元素都相等 D LCP 元素一旦确定就不会变化，无需处理切换
# 10. PerformanceNavigationTiming/PerformanceResourceTiming 在 LCP/TLS/TTFB 拆解的工程价值 A 这些 API 只能拿到总加载时间，无法拆解 B Resource Timing 不包含传输字节数 C TLS 握手时间无法从 timing 字段获取 D 通过 DNS/TCP/TLS/request/response 等阶段时间戳可把 LCP/TTFB 拆到具体环节，按资源与域名聚合定位网络瓶颈 ✓ 正确答案
# 11. CLS 的 session window 与 layout shift clusters 在性能监控的工程价值 A CLS 是所有布局偏移的简单累加 B 会话窗口只影响移动端 CLS C CLS 把 5 秒窗口内间隔不超过 1 秒的偏移归并为会话并取最大值，监控应基于会话聚合与 shift source 归因 ✓ 正确答案 D 布局偏移的归因不包含具体元素
# 12. 性能采样策略与统计意义 A 采样需按页面与设备分层保量，分位值小样本下不可信，聚合时应带权重还原总体分布 ✓ 正确答案 B 采样率越低，分位值估计越准 C 随机采样无法保证样本代表性 D 采样只影响存储成本，不影响统计结果
# 13. Web Vitals 库与浏览器内置 API 的差异 A 内置 API 已实现全部 Web Vitals 规范化逻辑，无需库 B 内置 API 在 bfcache 恢复场景自动处理 C web-vitals 库会增加大量上报开销，不适合生产 D web-vitals 库统一了各浏览器差异与 CLS 会话窗口、INP 最后取值等口径，产品化采集推荐用它，深度分析再直接使用内置 API ✓ 正确答案
# 14. performance.mark() 与 User Timing 在现代前端项目的工程价值 A performance.mark 只能测量浏览器加载阶段 B User Timing 数据无法在 DevTools 中查看 C mark/measure 可测量业务关键路径并接入框架与路由，统一进入 performance timeline 供 Observer 与 RUM 聚合 ✓ 正确答案 D mark 命名无需规范，随意即可
# 15. INP 在现代前端项目的工程价值 A INP 只测量页面首次输入延迟 B INP 覆盖全生命周期交互并计入渲染时间，反映交互响应性与业务转化，落地按 p75 分级并用三段归因定位主线程与渲染瓶颈 ✓ 正确答案 C INP 与 FID 的测量口径完全相同 D INP 无法与长任务关联定位
# 16. PerformanceObserver 在 SPA 路由切换的性能采集工程应用 A SPA 切换不触发导航 timing，需用路由钩子配合 mark/measure 分段测量加载/数据/渲染并按路由聚合 ✓ 正确答案 B SPA 路由切换会触发 PerformanceNavigationTiming C SPA 切换性能只能靠人工感受评估 D bfcache 恢复与正常切换无需区分
# 17. LCP 元素识别与上报的工程实现（含图片懒加载、字体加载的影响） A 首屏图片使用 loading="lazy" 不影响 LCP B LCP 采集需监听元素变化并上报最终元素；首屏关键图应 eager+preload，字体用 swap 并预加载，避免懒加载与 FOIT 推迟 LCP ✓ 正确答案 C font-display 与 LCP 无关 D bfcache 恢复时无需重新计算 LCP
# 18. CLS 累计偏移监控告警阈值的设定与工程边界策略 A 所有页面统一使用 0.1 作为唯一告警阈值即可 B CLS 告警与发布版本无关 C CLS 阈值应按页面类型、设备与基线动态设定，结合发布回归与偏移来源归类，避免一刀切与误报 ✓ 正确答案 D 第三方广告位导致的偏移无需在告警中区分
# 19. Performance API 导航时间（performance.timing）与现代替代 A performance.timing 与 PerformanceNavigationTiming 完全等价 B L2 的 startTime 与 L1 的 navigationStart 语义不同 C L2 无法通过 observer 获取 D L1 存在 load 前读 0、单份不可扩展等问题，现代方案用 PerformanceObserver 获取 navigation entry，迁移时需做属性映射与老浏览器兜底 ✓ 正确答案
# 20. PerformanceObserver 的缓冲区（buffer） A 缓冲区容量无限，entry 永不过期 B 缓冲区默认约 150 条、满则淘汰，需早期注册并 buffered: true 读取一次性指标，持续型指标要持续消费并适时清空 ✓ 正确答案 C buffered: true 会在任何注册时机拿到全部历史数据 D resource entry 不会占用缓冲区
# 21. Performance API 在生产环境的采样率策略与隐私边界 A 生产采集需分级采样控制成本，URL 先脱敏再上报，跨域 timing 依赖 Timing-Allow-Origin，并遵循最小化与 opt-out 合规要求 ✓ 正确答案 B 性能数据不含用户信息，无需脱敏 C 资源 timing 应全量逐条上报保证完整 D 跨域资源 timing 不受任何限制
# 22. Web Vitals 的 onCLS、onINP、onLCP 在 React/Vue 集成的工程实践 A 指标采集与路由、版本、水合时机无关 B SSR 与 CSR 的指标采集方式完全不同，无法共用 web-vitals C 在应用入口注册指标回调并绑定路由/版本上下文，关注水合与懒加载对 LCP/INP 的影响，回调轻量化处理避免影响被测性能 ✓ 正确答案 D onINP 可以在页面加载完成后任意时刻注册
# 23. 性能监控数据的聚合（p50、p75、p95）的工程统计方法 A 均值比 p95 更能反映用户体验 B 大数据量下用直方图或 T-Digest 等近似算法流式估计分位，并按页面/设备等维度分桶、带权重计算，避免混合分布掩盖问题 ✓ 正确答案 C 分位值只需要全局一个维度 D p95 就是把所有样本直接排序后取倒数第 95 个
# 24. Resource Timing API 在静态资源加载时长的工程监控 A resource entry 不区分资源类型 B 通过 resource entry 的阶段字段与 initiatorType 可按类型/域名聚合分析加载时长，注意持续消费防淘汰与跨域 timing 裁剪问题 ✓ 正确答案 C 跨域资源的 timing 数据总是完整的 D transferSize 无法用于缓存命中分析
# 25. 前端性能监控与 RUM 工具（Datadog、Sentry、New Relic） A 所有 RUM 平台功能完全一致，无需比较 B 选型应结合既有后端 APM 一体化、错误/回放关联、数据模型、成本与数据驻留等维度权衡，无绝对最优 ✓ 正确答案 C Sentry 的服务端 APM 能力与 Datadog 相当 D 自建 RUM 比商业工具在任何方面都更优
# 26. 性能监控在低端设备与慢网络的差异化策略的工程实践 A 低端机与高端机指标合并分析即可 B 慢网络只影响 TTFB，不影响其他指标 C 应按设备内存/网络分桶采集与定标，为低端机提供资源降级等分层优化，并降低弱网下的上报成本 ✓ 正确答案 D 统一阈值适用于所有设备形态
# 27. Performance API 在 SSR 与水合的性能测量工程边界 A SSR 分服务端渲染与客户端水合两段，服务端耗时需服务端打点，水合期间主线程占用会影响 INP，需在 hydration 完成时打 mark 对照 ✓ 正确答案 B SSR 页面的所有性能都可从客户端 Performance API 测出 C 水合不影响页面可交互性 D TTFB 能完全区分网络与服务端耗时
# 28. 如何做加权聚合并设定分级告警阈值，避免低端机型被统计噪声淹没 A 按设备/网络权重聚合分位并分档定标，辅以基线相对告警、样本量下限与版本对比，可避免低端机被稀释或误报 ✓ 正确答案 B 统一阈值加全局 p75 即可覆盖所有设备 C 加权聚合会引入严重误差，不如直接取均值 D 灰度版本应与全局混算比较
# 29. LCP 元素在不同路由切换下被重复识别导致数据失真，应如何用 element-relative 标记稳定锚点 A SPA 中 LCP 与路由无关，无需特殊处理 B 用 data 属性等稳定锚点标识 LCP 元素，以"锚点+路由"为键去重并按路由归属，可避免重复识别与跨路由失真 ✓ 正确答案 C 路由切换不会产生新的最大内容 D 选择器变化不影响 LCP 上报准确性
