前端性能监控

• Attribution 提供指标拆解字段（LCP 的元素与时间阶段、CLS 的 shift 归因）
• 从"指标差"到"哪一段差"的定位能力
• 与 span 瀑布、样本详情的联动

Web Vitals 库（web-vitals 的 attribution 版本）在指标数值之外返回拆解信息：LCP 给出元素选择器、URL 与 load 各阶段（TTFB、资源下载、元素渲染）耗时；CLS 给出造成偏移的最大 shift 源（元素、时间）；INP 给出输入延迟、处理、呈现延迟拆解。工程价值在于把聚合指标变成可行动的归因数据：RUM 平台按 p75/p90 圈出慢样本后，Attribution 字段直接回答"LCP 慢是因为图片下载慢还是主线程阻塞""CLS 是哪张图片插入引起"，无需人工逐个回放猜测；平台再把这些字段与 PerformanceObserver 的 entry、后端 trace span 关联，形成从指标到元素到代码的定位链。落地时注意 attribution 计算有额外开销（需收集更细的 timing 与元素信息），应在采样样本上启用而非全量。

本题考察 Web Vitals 的深度应用。答题核心是 Attribution 把"WHAT（指标差）"升级为"WHY（差在哪一段、哪个元素）"，并说明与 span/样本联动的定位链与采样开销的权衡。

• event entry 与 durationThreshold 的过滤语义
• 16ms 与帧预算（60fps）的关系
• INP 采集的边界（长事件、buffered、cross-origin 限制）

'event' 类型的 PerformanceEntry 记录每次交互事件（pointerdown、click 等）从输入到下一帧渲染的持续时间，只有超过 durationThreshold 的事件才会回调，16ms 对应 60fps 的单帧预算（1s/60≈16.7ms），即只上报"导致丢帧"的交互，避免海量短事件淹没数据。工程价值：INP 本质是取页面生命周期内交互延迟的分位值，用 durationThreshold 16 采集的长事件子集近似估算 INP 分布，且 event entry 自带 interactionId 与 target 元素，可与长任务、LoAF 关联定位卡顿根因。注意边界：buffered: true 需在 early 时机（页面加载早期）注册 observer 以收到历史 entry；跨域资源可能导致 timing 信息被裁剪；event entry 的兼容性（Chrome 96+）要求降级到手动打点测量输入延迟。

本题考察 PerformanceObserver 配置的精确语义。答题核心是 durationThreshold 与帧预算的关系、事件过滤对数据量的控制，以及 buffered/跨域/兼容性边界，体现对浏览器性能 API 的精细理解。

• Long Task 50ms 阈值的语义与局限
• LoAF 的呈现帧视角与 attribution 字段（script、style、layout）
• 长任务与长动画帧在卡顿归因上的互补

Long Task 以 50ms 为阈值标记占用主线程的单个任务，能暴露长阻塞，但粒度粗：无法区分任务内的具体活动，也无法覆盖"多个短任务凑成的帧超时"与渲染阻塞。LoAF（Long Animation Frames）以呈现帧为单位，凡是导致一帧渲染超时的执行区间都会被记录，并给出 attribution 数组：每项按类型（script、style、layout、paint）列出耗时与相关元素/脚本 URL，能精确回答"这一帧的卡顿是脚本执行、样式计算还是布局引起"。工程价值：LoAF 弥补了 Long Task 的归因盲区，尤其适合 React/Vue 渲染更新与交互后的一帧卡顿分析，配合 event entry 的 interactionId 可定位 INP 慢的具体代码块。注意兼容性：LoAF 目前 Chrome 支持较广、其他浏览器支持有限，需按 capability 检测降级到 Long Task。

本题考察主线程卡顿监控的两个层次。答题核心是"任务视角 vs 帧视角"的本质差异与 LoAF attribution 的归因价值，同时点明兼容性降级，体现对新一代性能 API 的掌握。

• 各指标的 entry type（paint、navigation、longtask）与观测时机
• buffered: true 与 early 注册的必要性
• 长任务的连续采集与上报聚合

对应 entry type：FCP 是 paint 类（first-contentful-paint）；TTFB 从 navigation 类 entry 的 responseStart 字段读取（或 resource timing 的响应开始时间）；长任务是 longtask 类。采集要点：FCP 与 TTFB 在页面加载早期就可能产生，observer 需尽早注册（如 HTML 内联脚本或库的 early 配置），并用 buffered: true 读取缓冲区内已产生的 entry；longtask 是持续事件流（不是一次性），需在启动时注册 observer 并持续聚合，可结合 startTime 计算每个任务的时长分布。上报策略：FCP/TTFB 作为页面级指标在 load 后一次性上报并打版本标签；长任务按 session 聚合（总阻塞时间 TBT、Top 长任务、发生时段）上报，避免每条任务一个事件造成数据爆炸。还需注意 navigation entry 需等 load 事件后读取才完整。

本题考察性能采集的工程细节。得分点是 entry type 与时机匹配（early + buffered）、一次性指标与持续事件流的分化处理，以及长任务聚合上报的降量设计。

• web-vitals 库的 onLCP/onINP/onCLS 采集语义
• 三个指标的不同上报时机（最终值、会话期）
• 采样、隐私与数据质量（忽略缓存、隐身模式）

RUM 用 web-vitals 库监听三类指标：onLCP 在首次内容绘制后的最大元素渲染完成时回调（含元素变化重算），onINP 在用户离开页面或指标稳定时回传会话内最差交互，onCLS 在页面隐藏（visibilitychange）时回传会话累计值，三者都应处理"页面卸载前最后上报"的场景。工程要点：上报时机分开——LCP 可在 load 后回调（但需处理 bfcache/延迟加载变化）、INP/CLS 需监听 pagehide 用 sendBeacon 发送；数据质量上排除刷新页面（navigationType reload）、忽略隐形页面（visibilityState hidden）、对移动端与弱网按网络类型/设备分桶；隐私合规上不采集 URL 查询参数中的敏感信息，按采样率（如 10%）抽样以控制成本，并对每个指标附环境标签（浏览器、设备、地域）以支持分组分析。

本题考察 RUM 全流程设计。答题核心是三个指标差异化的回调时机与"最后一刻上报"（pagehide + sendBeacon）、数据质量过滤与采样，体现对真实用户数据可信度的工程把控。

• CrUX 数据来源（Chrome 真实用户、大样本、分位值）与 API 形态
• CrUX 的查询维度（URL、origin、form factor、地域）
• CrUX 与自有 RUM 的互补关系（样本覆盖 vs 深度归因）

CrUX（Chrome UX Report）是 Google 基于真实 Chrome 用户匿名统计的 Web Vitals 大样本数据集，通过 CrUX API（或 BigQuery）可按 origin/URL、设备形态（desktop/mobile）、国家/地区查询 p75 等分位值，回答"这个网站在全网的体验表现如何、相比上月如何"。工程应用：作为 RUM 的"外部基准"——自有 RUM 样本可能偏（受自家用户结构影响），CrUX 提供客观对照，常用于发布后的体验回归检测、SEO 优化验证与竞品对比。互补关系：CrUX 覆盖面广但无深度（无具体元素、瀑布、trace），自有 RUM 深度足但样本受限于自身用户，二者结合——CrUX 发现趋势劣化，RUM 定位具体页面与根因；注意 CrUX 只有周/月粒度、不含单用户会话与 5% 以下低频 URL 数据，不能替代实时监控。

本题考察外部数据源与自有监控的结合。答题核心是 CrUX 的"全网大样本基准"定位与查询维度，以及与 RUM"广度 vs 深度"的互补分析模式。

• performance.mark/measure 的用法与 entry type
• PerformanceObserver 观察 'measure' 类型并取 buffered entry
• 业务指标的上报聚合与命名规范

实现路径：在业务关键操作（如搜索、下单、切换 Tab）开始处 performance.mark('op:start')，结束处 mark('op:end') 并 performance.measure('op:duration', 'op:start', 'op:end')；再用 PerformanceObserver({ type: 'measure', buffered: true }) 订阅回调，取出 duration 与 detail（可挂业务上下文），序列化后上报到 RUM。要点：mark 的命名用统一前缀与业务语义（如 'search:query'），避免与框架库冲突（可用 performance.mark 的 detail 挂参数）；跨异步流程测量时 start 标记不能丢失（用变量保存时间戳而非依赖 mark 存在）；对高频操作做采样与聚合（上报 p50/p95 或直方图桶）而非逐条上报；measure 的 buffer 默认有限（150 条），观察者需及时消费或配置 buffered 读取历史，长期运行用 PerformanceObserver 持续监听并清空。同时注意 performance 时间轴会累积，长会话可按需 performance.clearMarks 清理。

本题考察 User Timing 的业务化应用。答题核心是 mark/measure 的测量模型、observer 消费与 buffer 管理，以及聚合上报与命名规范，体现把性能 API 转化为业务指标体系的工程能力。

• INP 三段延迟的定义与测量窗口
• 各段延迟的典型根因（长任务、事件处理器、渲染）
• attribution 对定位的具体指导

INP 测量一次交互（如 click）从用户输入到下一次可见帧更新的总延迟，分为三段：Input Delay 是事件从触发到事件处理器开始执行的等待时间，主要被此前的长任务、繁忙主线程占据；Processing 是事件处理器（监听器、React/Vue 更新调度）本身的执行时间，长且 CPU 密集的处理器是主因；Presentation Delay 是状态更新后浏览器执行样式计算、布局与绘制直到帧呈现的时间，动画、大 DOM diff、layout thrashing 都会放大它。定位指导：用 event entry 的 duration 与 LoAF attribution 交叉——若 delay 段长说明主线程被抢占（找前置长任务），processing 段长优化事件处理器（拆分、节流、防抖、web worker），presentation 段长优化渲染路径（减少布局抖动、CSS 动画改用合成属性、组件更新收敛）。三者合起来解释了"为什么点下去没反应"，是 INP 优化的标准分析框架。

本题考察 INP 的精细归因模型。答题核心是厘清三段延迟的测量语义与各自根因，并给出对应优化手段，体现从指标拆解到具体代码优化的完整链路。

• LCP entry 的 element 与 renderTime/loadTime 语义
• 图片与文本 LCP 元素的时间差异
• 用 LCP 元素定位瓶颈（图片体积、字体、布局）

LCP entry 提供 element 属性（触发 LCP 的 DOM 元素）与时间字段：图片类 LCP 有 loadTime（资源加载完成）与 renderTime（绘制完成），文本类只有 renderTime。工程价值：识别出 LCP 元素后可按"元素类型 + 来源"聚合分析——若 LCP 是首屏大图，重点查图片体积/格式/预加载（fetchpriority、preload）；若是文本/标题，重点查字体加载（font-display、子集化）与布局阻塞（CSS、render-blocking 脚本）；再结合 renderTime 与 loadTime 的差值判断是"资源下载慢"还是"渲染被阻塞"。要点：LCP 元素可能变化（最大元素切换），需在回调时记录最终元素；上报时带上元素选择器（注意脱敏）、尺寸与 URL 归类字段；用 element-relative 或稳定 class 标记（如 data-lcp-root）避免压缩混淆后选择器失效。

本题考察 LCP 的微观归因。答题核心是 element/renderTime/loadTime 字段的语义差异及其对"网络 vs 渲染"瓶颈的区分，加上元素识别稳定性的工程细节。

• Navigation Timing 各阶段字段（redirect/DNS/TCP/TLS/request/response）
• Resource Timing 对单个资源的耗时拆解
• 用拆解数据定位网络瓶颈的维度（地域、运营商、协议）

PerformanceNavigationTiming 提供页面导航的完整阶段时间戳：domainLookupStart/End（DNS）、connectStart/End（TCP）、secureConnectionStart（TLS 握手）、requestStart（请求发出）、responseStart（TTFB 起点）、domContentLoaded/loadEvent。PerformanceResourceTiming 为每个资源提供同样的阶段字段与 transferSize/encodedBodySize/decodedBodySize。工程价值：把 LCP 拆成"导航 TTFB（DNS+连接+TLS+首字节）→ 资源下载（图片/Font）→ 渲染"，精确定位慢在哪一段：TTFB 长查服务端与网络、TLS 长查证书与握手链路、资源 download 长查体积与并发；按资源 initiatorType（img/script/css）与 URL 分组聚合，还能发现"某个 CDN 域名的连接建立普遍慢"。这些数据是性能优化优先级排序（先治服务端 TTFB 还是先压图片体积）的客观依据。

本题考察 Navigation/Resource Timing 的拆解能力。答题核心是各阶段字段的准确语义与"指标→阶段→根因"的拆解方法，体现用标准 API 构建性能归因体系的能力。

• CLS 会话窗口的归并机制（500ms 窗口、1s 间隔）
• 单次偏移 vs 会话累计的语义差异
• 偏移簇归因（字体、图片、动态插入）与优化

CLS 不是简单累加所有偏移，而是把偏移事件按会话窗口归并：从第一次偏移起，5 秒内发生的偏移、且两次偏移间隔不超过 1 秒的归为同一会话，取各会话累计值的最大值作为页面 CLS。这一机制避免"长时间页面上的偶发偏移被无限累加"导致的指标失真，同时保证"短时间内连锁偏移（如字体加载后整页跳动）"被完整计入。工程价值：监控时按会话维度上报最大 shift source（LayoutShiftAttribution 的元素与旧/新位置），归因典型来源——无尺寸图片/iframe 插入、字体加载（font-display 不当）、动态内容注入、动画触发布局；优化手段如为媒体预留尺寸、使用 aspect-ratio、content-visibility、字体 fallback 策略。注意 session window 的存在使"每次偏移都报"的埋点与 CLS 计算不一致，需按官方算法聚合后再上报。

本题考察 CLS 指标算法的精确理解。答题核心是会话窗口的归并规则（5s/1s）与"取最大会话"的语义，以及基于 shift source 的归因优化，避免答成"CLS 是所有偏移之和"。

• 采样率与样本量的权衡（成本 vs 精度）
• 随机采样与分层采样（设备、地域、场景）
• 分位值估计与置信度、样本代表性的关系

采样策略的核心权衡是"数据量与成本"对"统计精度"：全量采集成本高（带宽、存储、上报压力），过度采样率（如 0.1%）在长尾设备与低频页面上的样本不足，分位值估计方差大。设计要点：按页面类型与业务价值分层——核心页面高采样（如 50%）、长尾页面低采样（如 1%）；兼顾设备分层（低端机型、弱网样本必须保量，否则指标被高端机稀释）；对错误与极端性能事件做条件采样（异常样本全量、正常样本抽样）以兼顾诊断与成本。统计意义上，分位值（p50/p75/p95/p99）对小样本敏感，样本 < 100 时 p99 基本不可信，需用置信区间（如正态近似或分位数 CI）表达；样本偏倚（只采到某些浏览器）会系统性扭曲结论，因此采样必须随机且分层，并在上报中带采样权重（weight），聚合时加权还原总体分布。

本题考察性能监控的统计学基础。答题核心是采样率对分位值可信度的影响、分层采样的必要性，以及加权聚合还原总体分布的方法，体现数据工程素养。

• 内置 API 的原始性与各浏览器实现差异
• web-vitals 库的标准化处理（polyfill、会话窗口、上报时机）
• 直接使用 API 的边界与选型

浏览器内置 API（PerformanceObserver 的 paint/layout-shift/event 等类型）提供原始数据，但存在差异与坑：各浏览器对指标定义、entry 时序、跨域裁剪的实现不同；CLS 的会话窗口算法、INP 的"离开页面取最差值"、LCP 的元素变化重算等规范化逻辑需要自行实现，还容易漏掉 bfcache 恢复与后台标签页等场景。web-vitals 库封装了这些差异：统一回调时机（onLCP/onINP/onCLS）、内置会话窗口与分位逻辑、处理 bfcache/页面前后台切换、对不支持的类型做降级与 polyfill，并统一 entry 信息（如 attribution）。选型建议：产品化 RUM 直接使用 web-vitals（或其 RUM SDK）保证指标口径与官方一致；自研底层监控、需要原始 timing 深度分析时才直接用 Performance API 并自行实现规范化，同时维护跨浏览器兼容矩阵。

本题考察指标采集工具链的选型。答题核心是"内置 API 原始但有实现差异与口径坑，库负责标准化"，以及"口径一致性"在性能平台中的决定性作用。

• mark/measure 的测量模型与 performance timeline
• 框架集成（React Profiler、Vue、路由）与跨模块标记
• 与 PerformanceObserver、RUM 的结合

User Timing 提供轻量的自定义时间标记与区间测量能力：mark 打点、measure 计算区间，统一进入 performance timeline，可被 PerformanceObserver 读取与 DevTools Performance 面板可视化。工程价值：一是测量业务关键路径（路由切换、数据加载、组件渲染、表单提交）时长，补齐 Web Vitals 覆盖不到的体验环节；二是与框架集成——React 可用 onRender 回调打 mark/measure 记录组件树渲染耗时，Vue 类似地测量组件挂载，路由层用 beforeEach 与 afterEach 测量导航耗时；三是统一格式（performance.measure 的 detail 可挂上下文）后由 RUM 聚合，形成"标准指标 + 自定义指标"的完整度量体系。组织规范：mark 命名前缀化（module:action）、关键区间在单文件集中定义、必要时 clearMarks 控制 timeline 长度；在支持受限的环境用 Date.now() 兜底。

本题考察 User Timing 的业务应用价值。答题核心是 mark/measure 作为"标准指标之外的自定义测量通道"及其与框架、路由、RUM 的集成方式，体现把性能 API 用于业务度量体系的能力。

• INP 作为 FID 替代指标的定义与采集
• 交互延迟对业务转化的影响
• 落地路径：监控、归因（attribution）、优化手段

INP 衡量页面生命周期内所有交互（点击、按键、触屏）中最差交互到下一帧呈现的延迟，是 Google 于 2024 年正式替代 FID 的核心体验指标。工程价值：它把"交互响应性"量化——现代前端大量行为由用户交互驱动（路由、弹窗、提交），INP 直接反映"点下去有没有反应、多久有反应"，与业务转化率、流失率强相关；相比 FID 只测首次输入，INP 覆盖全生命周期并计入渲染时间，更能代表真实使用体验。落地路径：先采集（web-vitals onINP + event entry + LoAF），按 p75 分级（200ms 良好、500ms 需改进）与页面分组；再用 attribution 三段拆解定位根因——主线程长任务（拆分、并发、worker）、事件处理器过重（防抖、节流、缓存、异步化）、渲染阻塞（批量更新、减少布局抖动、动画合成）；对低端设备与慢网络单独设目标。

本题考察 INP 的宏观价值与落地。答题核心是 INP 替代 FID 的语义升级（覆盖全交互+计入渲染）、其对业务转化的重要性，以及"采集→分级→归因→优化"的完整落地路径。

• SPA 切换不触发导航 timing 的局限
• 路由钩子 + mark/measure 的采集方案
• 切换延迟的构成（JS、渲染、数据）与归因

SPA 路由切换不走浏览器导航，PerformanceNavigationTiming 只覆盖首次加载，需自行采集：在路由 before 钩子（如 Vue Router beforeEach / React Router 的导航生命周期）打 mark('route:start')，在组件挂载完成/页面 ready 后打 mark('route:end') 并 measure，同时记录切换类型（push/pop）、目标路由与耗时。要点：测量窗口要覆盖完整链路——路由解析、懒加载 chunk 下载（resource timing）、数据请求（fetch timing）、组件渲染（可与 React/Vue 渲染钩子联测），分段测量才能归因"慢在网络、数据还是渲染"；PerformanceObserver 持续监听 measure 与 resource 类型，聚合后按路由分组上报 p50/p95；注意浏览器前进/后退（popstate/bfcache）场景单独标记，避免与正常切换混淆；prefetch 路由与真实切换的时长差异也值得记录，用于决策预取策略。

本题考察 SPA 专属性能采集。答题核心是"路由钩子 + mark/measure"替代导航 timing、分段测量（加载/数据/渲染）归因，以及按路由聚合与 bfcache 区分，体现对现代应用性能采集的理解。

• LCP entry 的 element/renderTime 读取与上报字段设计
• 懒加载（loading="lazy"）延迟 LCP 的风险与预加载策略
• 字体加载（font-display、FOIT/FOUT）对文本 LCP 的影响

实现要点：注册 PerformanceObserver({ type: 'largest-contentful-paint', buffered: true })，在回调中读取 entry.element 与 renderTime/loadTime，维护"当前最大元素"，在页面隐藏或指标稳定时上报最终元素（选择器、标签、尺寸、URL 归类字段），并处理元素变化（最大元素切换）与 bfcache 恢复时的重新计算。懒加载影响：首屏图片若加 loading="lazy" 会推迟下载，直接拉高 LCP 或导致 LCP 元素变成其他内容，应为首屏关键图加 fetchpriority="high" 或 preload 并保持 eager；LCP 检测时若元素尚未加载完成，观察者要持续监听直到其渲染。字体影响：自定义字体若 font-display: block（FOIT），文本 LCP 会被推迟到字体就绪；应使用 swap/optional 配合 preload 字体子集、font-size-adjust 防跳动，文本 LCP 的 renderTime 反映的是文本首次绘制（含 fallback 字体），需区分"字体就绪时间"与"文本可见时间"。

本题考察 LCP 采集与优化的联动。答题核心是元素识别上报的实现细节，以及懒加载与字体两条典型 LCP 陷阱的机理与对策，体现采集与优化的闭环。

• CLS 良好/需改进/差的官方阈值（0.1/0.25）与分级
• 阈值设定的业务属性（页面类型、设备）
• 告警去噪与回归检测策略

官方口径：CLS ≤ 0.1 为良好，0.1~0.25 需改进，> 0.25 为差；监控告警通常按 p75（移动端与桌面端分开）分级：p75 超 0.1 提示需改进、超 0.25 告警，但阈值应按页面类型差异化——电商详情页动态内容多（广告、推荐位插入）可适当放宽，纯内容页应收紧；低端设备与弱网上限更高，需按设备/网络分桶设定。工程边界策略：用相对基线而非固定值（与过去 7 天基线比涨幅告警），避免节假日流量波动误报；对已知第三方注入（广告位偏移）设豁免或单独分组；结合发布回滚——新版本上线后 CLS 环比恶化即触发阻断式检查；同时区分"单次大偏移"与"持续累积"，前者可接受（弹窗场景），后者才是布局稳定性问题，监控应按 shift source 与触发时机归类。

本题考察指标告警的精细化设计。答题核心是官方阈值与业务/设备差异化设定、基于基线的动态告警，以及按偏移来源区分可接受与需治理的场景，避免一刀切阈值。

• L1 的全局对象形态与读取时机坑（0 值、load 后）
• L2 的 entry 形态、属性对齐与 buffered 机制
• 迁移时的兼容与口径差异处理

performance.timing 是 Navigation Timing L1 的全局对象，提供固定的导航时间戳集合，但有几个公认问题：时间戳可能在 load 事件前读取为 0（须在 load 后读取）、对象只有一份（不支持多导航/重定向场景）、部分字段在跨域资源下被裁剪、且是过期标准。现代替代是 PerformanceNavigationTiming（L2）：通过 PerformanceObserver({ type: 'navigation', buffered: true }) 获取 entry，属性语义对齐（startTime 为导航起点、duration 为整个加载、fetchStart/responseStart 等同名），支持 redirectCount、serverTiming 等新字段，并可与其他 entry 统一在 timeline 中消费。迁移要点：保留 L1 兜底（老浏览器）但默认用 L2；注意 L1 的 navigationStart 对应 L2 的 startTime，L1 的部分字段（如 unloadEvent）在 L2 中语义有调整；统一封装 getNavTiming() 接口，避免业务代码直接依赖已废弃 API。

本题考察标准演进与兼容迁移。答题核心是 L1 的"0 值/只读/单份"缺陷与 L2 的 entry 化改进，以及迁移时的属性映射与兜底策略。

• buffer 的容量限制（150 条）与淘汰策略
• buffered: true 与注册时机的配合
• 长会话下的持续消费与内存管理

浏览器为每种 entry type 维护一个性能缓冲区，默认容量约 150 条，容量满后最旧的 entry 被淘汰；PerformanceObserver 注册时若指定 buffered: true，可立即读取缓冲区内已有的 entry（弥补晚注册漏数据）。工程要点：一次性指标（paint、navigation）应在页面早期注册并带 buffered: true，防止 entry 被淘汰；持续型指标（resource、longtask、event）在应用生命周期内不断产生，若回调消费不及时，缓冲区淘汰会导致数据丢失，所以观察者必须在产生早期注册并持续消费；长会话中及时处理并配合 clearResourceTimings 释放内存，避免 timeline 无限膨胀；对需要全量 resource 分析的场景，可在关键节点（load 后、每 N 秒）主动 getEntries 拉取快照并清空，平衡完整性与内存。注意不同 entry type 容量可能不同，且 buffered 读取不代表数据永续存在。

本题考察性能 API 的资源管理。答题核心是 150 条容量与淘汰语义、buffered 的正确使用时机，以及长会话下的消费-清空节奏，属于性能采集的常见实战坑。

• 采样率与上报量的权衡（resource/event 数据量）
• 隐私边界：URL 参数、用户标识、跨域 timing 裁剪
• 合规要求下的最小化采集

采样率策略：resource timing 每条资源一个 entry，长会话页面可能成千上万条，全量上报成本极高，应分级——核心资源（首屏图、关键 JS/CSS、API）全量，长尾资源（图片轮播、分析脚本）按比例抽样；event/longtask 按阈值过滤后抽样（如 5%~10%）；聚合上报（分布桶）优先于逐条上报。隐私边界：性能 URL 常带用户信息（订单号、Token 查询参数），上报前必须对 URL 做脱敏（只保留路径与域名，剥离 query）；不采集可识别用户的字段（不做设备指纹关联），按 GDPR/个保法对性能数据做"业务必要最小化"评估；跨域资源（第三方 CDN、字体）的 timing 在未加 Timing-Allow-Origin 时会被裁剪为 0，这既是安全机制也是数据盲区，需要求关键第三方资源配置该响应头以换取可测性。合规上还需在隐私政策中声明性能数据的收集范围与用途，并提供拒绝采集的机制（如 opt-out）。

本题考察性能采集的工程治理。答题核心是"数据量分级采样 + URL 脱敏 + Timing-Allow-Origin 可测性边界 + 合规最小化"，体现性能监控与隐私安全的平衡。

• 库在框架入口的初始化与上报绑定
• 指标与路由、组件、版本上下文的关联
• 框架渲染对指标的影响（水合、Suspense、客户端渲染）

集成实践：在应用入口（React 的入口模块或 Vue 的 main.js）引入 web-vitals 并注册上报函数，把指标与版本号、路由（history 变化时更新）、用户上下文（脱敏后）绑定；上报函数统一走项目封装（sendBeacon/fetch 批量队列），并在生产环境才启用、开发环境跳过。框架注意点：CSR 应用的首屏指标与 SSR 水合（hydration）表现不同——水合期间的 INP/LCP 受 JS 执行影响大，应记录 hydration 完成时间与指标对照；Suspense/lazy 组件的 LCP 元素可能在挂载后才出现，observer 回调需覆盖；Vue 的 Teleport、React Portal 渲染的节点也可能成为 LCP/CLS 来源，上报元素信息时应保留稳定标识。实践规范：指标回调只做轻量处理（立即上报或入队），避免影响指标本身；按环境变量开关采样；把 onINP 的注册放在交互发生前（页面早期），保证覆盖全部会话。

本题考察指标库的框架级落地。答题核心是入口初始化与上下文绑定、SSR/水合与懒加载对指标的框架特殊性，以及"别让监控拖慢被测对象"的工程自律。

• 分位值的计算语义（排序、插值）
• 大数据量下的近似算法（直方图、T-digest、HDR histogram）
• 聚合维度（全局、页面、设备）与加权

分位值是把样本排序后取第 p% 位置的数值，p50/p75/p95 分别代表"一半/四分之三/95% 用户不差于该值"，对偏态分布（性能数据典型右偏）比均值更稳健。小数据量直接排序计算；大数据量（百万级事件）逐条排序不现实，工程上用近似算法：直方图分桶（把耗时按对数桶累计计数，按桶插值估计分位）简单高效；更精确的用 T-Digest 或 HDR Histogram（高动态范围直方图），在流式场景下边接收边更新、误差可控（如 1%）。聚合设计：按维度分桶——全局、页面、设备、网络、版本分别计算分位，否则混合分布会掩盖问题（低端机 p95 远高于全局 p95）；若采样带权重，分位计算需按权重加权（权重大小表示代表样本数）；上报端尽量在客户端聚合（每 N 条汇总一次直方图）而非逐条上报，降低传输成本。

本题考察性能数据的统计工程。答题核心是分位值的语义与偏态稳健性、T-Digest/直方图等流式近似算法，以及多维分桶与加权，避免把均值当指标或直接排序全量数据。

• resource entry 的字段（initiatorType、duration、transferSize、阶段拆分）
• 按资源类型与域名的聚合分析
• 观测完整性与跨域裁剪（Timing-Allow-Origin）

通过 PerformanceObserver({ type: 'resource', buffered: true }) 持续收集 resource entry，每个 entry 记录 initiatorType（script/link/img/css/font）、name（URL）、duration、transferSize、encodedBodySize 以及 DNS/connect/secureConnection/request/response 阶段时间。工程应用：按 initiatorType 与域名聚合出"JS 平均下载耗时、字体加载成功率、CDN 各域 TTFB 分布"，识别慢资源与未缓存资源（transferSize 大说明未命中缓存）；结合页面版本与首屏资源清单，能发现构建产物体积膨胀或 CDN 回源慢的问题。要点：observer 必须尽早注册并持续消费（buffer 会淘汰旧 entry）；跨域资源（第三方 CDN、字体）无 Timing-Allow-Origin 时 duration 等字段被裁剪为 0，需推动第三方配置该头或改用服务端日志补全；上报策略按资源重要性抽样聚合，避免全量风暴；transferSize 为 0 且非跨域时表示命中了本地缓存，可用于缓存命中率分析。

本题考察资源层性能监控。答题核心是 resource entry 的字段语义与按类型/域名聚合的方法、buffer 与跨域裁剪两大坑，以及缓存命中分析等进阶用法。

• 各平台 RUM 的核心能力差异（Web Vitals、回放、trace 整合）
• 与后端 APM 联动的一体化能力
• 成本、数据留存与自建复杂度

三家都提供 RUM：Datadog RUM 与 APM、Session Replay、日志深度打通，支持自定义 RUM events 与真实用户采样，背靠强大的查询与告警体系，适合全栈可观测性一体的团队；Sentry 以错误监控见长，Performance 与 Session Replay 与错误事件同源关联，前端团队上手快、成本友好，但服务端 APM 与查询能力弱于 Datadog；New Relic Browser 与后端 APM 同平台，Web Vitals 与分布式追踪整合成熟，适合已有 New Relic 后端监控的公司。权衡维度：是否已用其 APM（一体化减少工具链）、前端数据模型灵活度（自定义事件与属性）、隐私与数据驻留（SaaS vs 自托管/私有化）、成本随采样率与留存期增长的方式，以及 SDK 体积与上报性能开销。自建 RUM 则在数据主权与定制上更灵活，但需要承担采集、存储、查询的工程成本。

本题考察 RUM 平台选型的综合判断。答题核心是"先看后端 APM 一体化需求，再比较错误关联、数据模型、成本与数据驻留"，体现选型框架而非罗列功能。

• 低端设备与慢网络的性能特征（主线程弱、TTFB 长）
• 按设备/网络分桶的采集与目标设定
• 针对性优化（资源降级、首屏裁剪、体验分层）

低端设备（低内存、低端 CPU）与慢网络（3G、弱 Wi-Fi）会系统性放大性能问题：同一条优化在旗舰机上收益明显、在低端机上才是生死线，若把指标混在一起聚合，问题会被高端机稀释。差异化实践：采集端把 deviceMemory、hardwareConcurrency、effectiveType（网络）随指标上报，按设备/网络分桶聚合与展示，各自设定目标（如低端机 LCP < 4s 即可接受，而非统一 2.5s）；分析端对"低端机专属劣化"（主线程长任务、内存压力、图片解码耗时）单独建看板与告警；优化端提供分层策略——低端机/弱网下发精简包（去动画、裁剪富文本、降分辨率）、延迟非首屏资源、用 dPR/网络感知的资源选择、关闭高开销特性。同时注意上报本身在弱网下成本更高，应降低采样率或使用 sendBeacon 批量、压缩事件。

本题考察性能监控的用户分群思维。答题核心是"按设备/网络分桶、分层定标、定向优化、弱网上报降成本"，体现对真实用户环境的尊重与数据分层的工程方法。

• SSR 输出 HTML 与客户端水合的两段式指标
• 水合期间的 LCP/INP 特殊性（事件监听、再渲染）
• 测量时机的错位（服务器时间 vs 客户端时间）

SSR 页面先由服务端输出完整 HTML（首屏内容直接可见），再在客户端水合（绑定事件、恢复状态），性能测量因此分两段：服务端渲染时间（SSR 耗时、TTFB 含服务端生成时间）与客户端水合时间（hydration 完成、可交互时间 TTI 近似）。边界问题：浏览器端 Performance API 只能测客户端时间线——TTFB 已包含服务端生成时长但无法区分"网络慢"与"服务端慢"；LCP 可能在 HTML 解析时即达成（文本内容），水合后的交互响应（INP）受水合期间主线程占用影响，水合不完成甚至会出现"内容可见但点击无响应"；测量水合完成的可靠方式是在 hydration 完成回调中打 mark，与首屏 paint 对照。工程边界：SSR 耗时需服务端打点上报；客户端区分"水合前事件是否丢失/延迟"；对 hydration 期间的长任务用 Long Tasks/LoAF 归因，避免把 SSR 的优化效果误判到客户端。

本题考察 SSR 场景测量模型的特殊性。答题核心是"两段式指标"与"客户端 timeline 的盲区"（服务端耗时不可见）、水合对 INP/LCP 的干扰，以及服务端打点补全的必要性。

• 加权聚合（按设备/网络/流量权重的分位计算）
• 分级阈值（分设备、分场景）与基线告警
• 噪声识别（异常样本、小样本、新版本回归）

加权聚合：数据上报时携带设备分档（deviceMemory/并发核数）、网络分档（effectiveType）与流量占比权重，聚合分位值时按权重计算——既反映真实用户分布（低端机用户多的产品其权重自然大），又可按分档单独看板防稀释。分级告警设计：第一层按档位分桶定标（旗舰机 LCP 2.5s、中端 3.5s、低端 5s），各档独立阈值与看板；第二层用基线相对告警（当前 p75 相对近 7 天基线上涨 20% 触发），比固定阈值更抗噪声；第三层对噪声源做抑制——样本量不足（< 50）的桶不告警、异常波动（单日尖峰）需验证是否发布或流量结构变化引起，灰度与新版本单独比较避免与全局混算。落地中还可对同一版本做 A/B 对比（新版本 vs 旧版本同设备档位），把"统计噪声"与"真实回归"区分开。

本题考察性能数据的统计治理。答题核心是"按设备/网络加权聚合 + 分档定标 + 基线相对告警 + 样本量与版本对比去噪"，防止低端机被稀释或误报，体现数据驱动决策的严谨性。

• SPA 路由切换中 LCP 元素重复识别的问题
• element-relative 标识（data 属性、稳定选择器）的设计
• 上报去重与路由维度的指标归属

问题成因：SPA 每次路由切换都产生新的最大内容（新页面的 hero 图/标题），若上报逻辑沿用"页面级 LCP 只报一次"或选择器基于易变 class，会出现同一视觉元素被重复计为 LCP、或元素因 Vue/React 复用导致选择器错位，使 LCP 分布失真（同一个内容被计多次或归错路由）。解决手段：给可成为 LCP 的元素加稳定的 element-relative 锚点——数据属性（data-lcp="hero-title"）或稳定的语义标识，上报时以"锚点 + 路由"为键：同一路由下同一锚点只计一次（或按访问次数归一），不同路由按当前路由归属指标；路由切换时在路由钩子中重置"当前页面 LCP 已上报"状态并更新上下文。这样 LCP 统计口径从"全局最大元素"细化为"每个路由的最大元素"，避免跨路由串扰与重复计数，配合按路由聚合看板即可定位各页面真实首屏瓶颈。

本题考察 SPA 指标口径治理。答题核心是"路由维度归属 + 稳定锚点去重"双重机制，解释失真成因（复用、重复识别）并给出可落地标记方案。