知识库K25
工程化、测试与性能 · KNOWLEDGE CHAPTER
K25

核心性能与调度

性能优化是定位关键路径上的等待，再验证改动是否真的减少了用户代价。下载更少、主线程更闲、分数更高都只是中间证据；最终要同时看内容出现、交互反馈、结果可用、稳定性与失败率。

工程化、测试与性能2 道章节练习8 道主练关联
先修知识：K06 · 渲染与动效K09 · 异步控制与迭代K12 · 页面生命周期与调度K13 · HTTP 语义、缓存与传输

核心模型

性能优化是定位关键路径上的等待，再验证改动是否真的减少了用户代价。下载更少、主线程更闲、分数更高都只是中间证据；最终要同时看内容出现、交互反馈、结果可用、稳定性与失败率。

原理与机制

先定义可比的观察

实验室轨迹固定设备和网络，适合解释机制；真实用户数据包含地区、缓存、设备与访问路径，适合判断影响。两者不可互相替代。按路由、版本、设备和网络分层，报告样本量和分位数，并检查失败访问是否漏报。改版后总体变慢而各设备组变快，可能只是低端设备占比增加；需对齐权重或同期对照，不能凭一次跑分推断因果。指标口径及停看实验的条件应先确定。

把 LCP 拆成资源与渲染链

确认实际 LCP 元素后，分析首字节等待、资源发现延迟、下载和渲染延迟。图片压缩只影响其中一段；首屏图被懒加载、经脚本才发现，或主线程迟迟不能渲染时，减字节未必有效。文字 LCP 还要看字体、阻塞样式和客户端渲染，系统字体可能没有独立资源阶段。preload 只留给确定会用的关键资源，字体的 URL、as、type、crossorigin 要匹配，否则可能重复传输；font-display 与回退字体度量还会影响可读性和位移。

INP 关注下一次呈现，而非请求结束

一次交互延迟包含输入等待、处理与呈现等待。INP 观察点击、触摸和键盘；页面交互很多时按规则排除少量最高异常值，再跨访问观察 p75。输入立即回显、结果一秒后返回，并不意味着 INP 就是一秒；但先画 loading 再冻结两秒也不是好体验。应同时记录结果时延、后续输入和长任务。让非关键工作后移必须真正让出任务，连续 await Promise.resolve 仍可占满微任务检查点。

调度改变阻塞，不能抹去工作

将导入分为按时间预算计算、暂存验证、一次发布，可以缩短不可中断区间，并在取消时丢弃暂存，避免半份结果对用户可见。scheduler.yield 应作能力检测并有任务级退让方案。Worker 适合独立重计算，却有启动、克隆、传输和结果合并成本；复用实例，只返回聚合或差量。Transferable 改变所有权，普通对象并非零成本共享；同步长循环也不能处理排队的取消消息，需分片或可安全 terminate。

稳定性来自空间契约

CLS 取生命周期内最大的偏移会话窗口，相邻偏移间隔小于一秒，窗口最长五秒，并非把全程偏移相加。图片、字体、广告和迟到推荐应事先约定空间，记录被推挤元素后还要向上追根因。广告无填充时折叠会跳动，保留空白也有成本，应一起看填充率、收益、空白和 CLS。符合条件的离散输入后短时偏移可能排除，滚动并不因此免责；父页 JavaScript 对跨域 iframe 的归因存在盲区。

最小示例

javascript
javascript
async function prepareRows(rows, transform, signal) {
  const staging = [];
  let sliceStart = performance.now();
  for (const row of rows) {
    signal.throwIfAborted();
    staging.push(transform(row));
    if (performance.now() - sliceStart >= 8) {
      if (globalThis.scheduler?.yield)
        await globalThis.scheduler.yield();
      else await new Promise(resolve => setTimeout(resolve, 0));
      sliceStart = performance.now();
    }
  }
  signal.throwIfAborted();
  return staging; // 调用方验证后再发布
}

8ms 只是演示预算，需在目标设备调整。观察输入能否在分片间响应，而不只看总耗时。单次 transform 若很重仍会阻塞；最终渲染 staging 也可能产生长任务，且此函数只保证本地准备阶段，不能替代服务端事务。

核验：Node v24.19.0：顺序转换结果、预取消拒绝断言通过；未验证真实浏览器绘制、scheduler调度或设备性能。

边界与取舍

边界

  • LCP、INP、CLS 的良好 p75 参考阈值分别为 2.5秒、200ms、0.1，各指标不能互相抵消。
  • 把两万行计算整体放进 setTimeout 只改开始时间；把它放 Worker 也不保证总耗时更短。
  • 短暂加载测试遗漏滚动后的偏移；采不到跨域 iframe 归因不等于用户没受影响。

取舍

  • 少数关键资源优先加载可缩短关键路径，全量 preload 则会争带宽；要测冷缓存和慢网。
  • 分片和跨线程改善响应性，但增加调度、内存与一致性成本；同时约束总耗时及最长阻塞。

口述示范

我会先用真实用户分层数据确定影响，再用轨迹拆关键路径。优化资源发现、主线程调度或空间契约之后，按同口径复测，并确认没有把延迟、位移或失败转移到另一处。

章节练习

练习 1

图片压缩后 LCP 几乎不变，设计下一轮只改变一个主要因素的实验。

展开检查点
  • 确认 LCP 元素，分解 TTFB、发现、下载及渲染延迟。
  • 固定网络与设备，检查元素是否变化，复测线上分布和 CLS。
相关题目：E08E11E12
练习 2

导入表格改 Worker 后更慢且取消无效，怎样判定继续优化还是撤回？

展开检查点
  • 拆启动、复制、计算、回传与最终渲染，测输入延迟及内存。
  • 检查同步循环的取消可达性、任务版本与差量回传，比较本地分片方案。
相关题目：E09E13E26

参考来源与核验边界

2026-10-04 核验指标定义；scheduler.yield 的支持情况和时间预算须按目标浏览器与设备验证。示例不声称每次退让必然产生一帧，也不提供恒定8ms实时保证。

内容版本：2026-10-04.2 · 题目和来源 ID 保持原样，本站不将面经标签解释为企业官方出题或高频保证。