Performance

页面性能

全面的网页性能优化指南，涵盖性能指标、监控方案、优化策略，以及 SSR、PWA 等现代 Web 应用的性能优化实践。

如何测量性能指标

怎么测定页面帧率？

可以使用 requestAnimationFrame，但是不推荐，因为脚本本身就会对性能造成影响。

Performance Timing 被弃用了，取而代之的是 Performance Navigation Timing。不应该再使用 performance.navigation、performance.getEntries 等 API，这些旧的 API 没有办法肩检测如加载新脚本等情况，不支持新的性能指标如 Long Tasks API，此外可能干扰页面性能，所以推荐使用 Navigation Timing API 获取数据，并使用 Performance Observer 进行侦测。

Navigation Timing Level 2

见：Navigation Timing Level 2

Navigation Timing 中不同的阶段是连续的吗？

可能不是。如浏览器有同域下最多 6 个请求并行的限制，那么 domainLoopupEnd 到 requestStart 之间可能会出现较长的等待时间（Stalled Time）。此外，不一定每个阶段都会有数据，如：未发生跳转时， redirectCount 为 0；如果页面没有 service worker，那么 workerStart 为 0；DNS 从缓存中获取时，domainLoopupStart 和 domainLoopupEnd 可能相等。

PerformanceObserver 是什么？

"有效的性能测量的第一条规则是确保性能测量技术本身不会导致性能问题"，使用 Performance Observer 可以获取某个具体类型的指标的同时不会干扰或影响页面性能，因为它会在浏览器空闲时期执行。

try {
  // "element"、"event"、"first-input"、
  // "largest-contentful-paint"、"layout-shift"、
  // "longtask"、"mark"、"measure"、
  // "navigation"、"paint"、"resource"
    PerformanceObserver.supportedEntryTypes.map(type => {
        new PerformanceObserver((list) => {
          for (const entry of list.getEntries()) {
            console.log(entry.toJSON())
          }
        }).observe({
        type,
        // 使用 buffered 可以在第一次回调时获取缓存区中的历史记录
        buffered: true
      })
    })
} catch {
    // nothing
}

见：Performance Observer

Long Tasks API 是什么？

Long Tasks API 将会汇报使主线程阻塞超过 50ms 的任何任务。通过观测阻塞时长，可以获得诸如 TTI（Time To Interactive）、TBT（Total Blocking Time）等数据。

见：Long Tasks API

如何测量函数执行的时长？

可以使用 Date.now()、performance.now()，但是如果不考虑兼容性的话，使用 User Timing API 要更好一些，它可以和相关套件很好的结合：比如说在 Performance 面板中可视化，或通过 Performance Observer 进行观测。

performance.mark('myTask:start')
await task()
performance.mark('myTask:end')
performance.measure('myTask', 'myTask:start', 'myTask:end')

见：User Timing API

如何测量元素的渲染时间？

可以使用 Element Timing API。通过给 element 增加 elementtiming 属性，可以在注册 Performance Observer 后监听 element 类型的事件并获得元素渲染时间。 LCP 指标就是建立在 ET API 基础上的，只是汇报的是最大内容元素的渲染时间。

<img elementtiming="hero-image" />
<script>
  new PerformanceObserver(/* ... */)
    .observe({ type: 'element', buffered: true })
</script>

见：Element Timing API

Event Timing API 是什么？

见：Event Timing API

Resource Timing API 是什么？

见：Resource Timing API

Navigation Timing API 是什么？

类似于 Resource Timing API，但不同的地方在于它会在导航时被触发，还附带了 DOMContentLoaded 和 load 事件的触发事件。

见：Navigation Timing API

除了规范定义数据，还可以上报哪些？

5W：时间、地理位置、页面 URL、浏览器、系统、账号 ID、现场还原。网络：页面加载方式、Service Worker、HTTP 协议版本、资源压缩方式。其它：页面在前台还是后台。

时间到交互性 (Time to Interactivity)

Zach Leatherman 提出的指标，关注代码已落地浏览器但交互尚未就绪的"死亡区域"。这一指标帮助开发者量化从可看到可用的间隔，为性能优化谈判提供具体依据。

见：Web of State of the Browser Day Out：Remy Sharp 的会议回顾

性能优化

做性能优化的基本法则是什么？

编译层参见 webpack 优化；网络层减少请求；客户端预加载、预渲染、预执行。以及两句名言："空间换时间"、"串行改并行"。

如何优化复杂动画的性能？

复杂的 DOM 动画（如多个独立元素同时运动）在低端设备上可能造成性能瓶颈。 CSS Sprite 动画是一种高性能替代方案，通过 object-position 切换单张 Sprite 图的不同区域来实现帧动画，相比多元素方案大幅减少了渲染开销。

见：CSS Sprite Animation

第二页加载优化的陷阱

Harry Roberts 指出一个反直觉现象：当跳出率很高时，用大量 JavaScript"优化"第二页加载是过早优化，反而带来负面成本。这提醒性能优化需要结合实际业务数据，而非盲目追求指标。

见：Web of State of the Browser Day Out：Remy Sharp 的会议回顾

SSR 及混合应用优化

Speculation Rules API 是什么？

Chrome 推出的推测规则 API，允许开发者在用户实际导航到网页之前就开始加载网页。目前支持两种推测类型：

预提取 (prefetch)：仅获取 HTML 文档，不加载子资源
预渲染 (prerender)：获取子资源并执行渲染，几乎像在隐藏标签页中打开网页

见：Speculation Rules API

Prerender Until Script 是什么？

完全预渲染虽然性能提升显著，但存在实现复杂度和副作用风险（如分析脚本提前触发、状态管理复杂等）。Prerender Until Script 是介于预提取和预渲染之间的中间方案：

预提取 HTML 文档 + 渲染页面 + 获取子资源
关键区别：遇到 <script> 元素时暂停解析，等待用户导航后再继续
无脚本的页面将完全预渲染，有阻塞脚本的页面至少能提前开始渲染和资源预加载

使用方法：

{
  "prerender_until_script": [{
    "where": { "href_matches": "/*" }
  }],
  "prefetch": [{
    "where": { "href_matches": "/*" }
  }]
}

降级策略：同时配置 prefetch 可实现对不支持浏览器的优雅降级。

见：推测规则预渲染直到脚本源试用

CSR 是什么？

Client Side Rendering，和 SSR 相对应，指页面渲染、逻辑、路由、请求都是在浏览器发生的。想要提高 CSR 项目的用户体验，可以考虑在编译时通过预渲染首屏、骨架屏等形式对性能指标进行优化，或者，上 SSR。

从 CSR 到 SSR 有哪些过渡方案？

CSP -> CSP with prerender -> SSR with hydration -> static SSR -> SSR

From CSP to SSR

见：TODO，Rendering on the Web、CSR、SSR、NSR、ESR傻傻分不清楚

ESR 是什么？

TODO，边缘计算说过吗？淘宝用它提升了69%的首屏性能

经典直出方案是什么？

直出指在后端渲染好 HTML 后再回传给客户端这种方式，直出可以节约许多 HTML 渲染及 AJAX 请求的时间，对 Web 前端的侵入性最小。

离线包缓存是什么？

直出方案仍需要把时间花在请求、加载 HTML 上，离线包缓存意味着把 HTML、CSS、JS、数据提前缓存在本地，只有部分需要异步更新的页面才通过请求的方式加载新数据并重新渲染页面。

直出 VS 离线包缓存

容器化方案是什么？

TODO，http://www.alloyteam.com/2020/06/fast-open-h5/

Chrome 144 Web App 更新机制有哪些改进？

Chrome 144 对可安装 Web 应用（PWA）的更新流程进行了四项关键优化：

名称和图标更新改为可选操作：不再强制弹出干扰性对话框，用户可通过三点菜单的"查看应用更新"选项自主选择是否应用这些身份更改，也可以选择完全忽略
智能图标下载：如果清单中的 icons 字段 URL 未变化，则直接认为图标未改变，避免不必要的下载（视为 Cache-Control: immutable）
移除更新频率限制：由于不再每次都下载图标，每天一次的限制被取消，非安全敏感型成员可立即更新
视觉差异阈值：像素级差异小于 10% 的图标更新会自动应用，避免 CDN 重新编码等微小变化触发用户确认对话框（此豁免每天限一次，防止滥用）

见：一种更优越的 Web 应用更新方式

PWA 怎么配合 SSR 做优化？

PWA 能够通过 Service Worker 对缓存进行精细化控制，在客户端使用无头浏览器提前加载 HTML，等到实际加载时请求的就是由 Service Worker 缓存下来的资源了。

PWA + Headless Webview

NSR 是什么？

Native Side Render，GMTC 2019 UC 团队提到的一种"前端 SSR"方案，它借助浏览器启动一个额外的 JS Runtime，将提前下载好的 HTML 模板和数据预渲染出来。这种方案的瓶颈在于他会带来额外的流量和性能开销，所以如何预测用户行为，提高命中率是非常重要的事。