97 lines
5.7 KiB
Markdown
97 lines
5.7 KiB
Markdown
|
# 性能表现
|
|||
|
|
|
|||
|
|
性能是编辑器应用的关键特性，块编辑器也不例外。
|
|||
|
|
|
|||
|
|
## 指标衡量
|
|||
|
|
|
|||
|
|
为确保块编辑器在版本迭代和开发过程中始终保持高性能，我们通过[性能基准测试任务](#性能基准测试任务)监控以下核心指标：
|
|||
|
|
|
|||
|
|
部分关键指标包括：
|
|||
|
|
|
|||
|
|
- **加载时间：** 编辑器页面加载所需时长。涵盖服务器响应时间、首次绘制时间、首次内容绘制时间、DOM内容加载完成时间、页面完全加载时间以及首区块渲染时间（文章与站点编辑场景均包含）。
|
|||
|
|
- **输入响应时间：** 在编辑器中输入时浏览器作出响应所需时长。
|
|||
|
|
- **区块选择时间：** 用户选择区块后浏览器作出响应所需时长（插入区块等效于选择区块，监控选择操作即可同步覆盖这两项指标）。
|
|||
|
|
|
|||
|
|
## 关键性能决策与解决方案
|
|||
|
|
|
|||
|
|
**数据模块异步模式**
|
|||
|
|
|
|||
|
|
WordPress组件库与块编辑器的数据模块基于Redux构建。这意味着状态全局存储，当状态发生变化时，依赖该状态的组件（UI）会相应更新。
|
|||
|
|
|
|||
|
|
随着渲染组件数量增加（例如长文编辑时），由于全局状态会向所有组件分发事件，性能将受到影响。这是Redux应用的常见问题，Gutenberg通过数据模块异步模式解决了这一难题。
|
|||
|
|
|
|||
|
|
异步模式的核心在于：开发者可自主决定以同步或异步方式刷新/重渲染React组件树的特定部分。
|
|||
|
|
|
|||
|
|
在此语境下，异步渲染意味着当全局状态触发变更时，订阅者（组件）不会立即被同步调用，而是等待浏览器进入空闲状态后再执行React树更新。
|
|||
|
|
|
|||
|
|
基于**编辑特定区块时，该区块的更新极少影响内容其他部分**这一理念，块编辑器画布仅以同步模式渲染当前选中区块，其余所有区块均采用异步渲染。这确保了随着文章内容增长，编辑器仍能保持流畅响应。
|
|||
|
|
|
|||
|
|
## 性能基准测试任务
|
|||
|
|
|
|||
|
|
我们提供了跨分支/标签/提交进行性能对比的工具。可通过以下方式本地运行：`./bin/plugin/cli.js perf [分支名]`，例如：
|
|||
|
|
|
|||
|
|
```
|
|||
|
|
./bin/plugin/cli.js perf trunk v8.1.0 v8.0.0
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
为获得最精确结果，运行测试时必须确保测试版本与环境（主题等）完全一致，各分支间唯一差异应为Gutenberg插件版本（或用于构建插件的分支）。
|
|||
|
|
|
|||
|
|
为实现该目标，指令会先创建以下目录结构：
|
|||
|
|
|
|||
|
|
│
|
|||
|
|
├── tests/packages/e2e-tests/specs/performance/*
|
|||
|
|
│ 待运行的实际性能测试
|
|||
|
|
│
|
|||
|
|
├── tests/test/emptytheme
|
|||
|
|
│ 测试环境所用主题（站点编辑器）
|
|||
|
|
│
|
|||
|
|
│── envs/branch1/.wp-env.json
|
|||
|
|
│ branch1的wp-env配置文件（除插件目录外与其他分支配置相同）
|
|||
|
|
│── envs/branch1/plugin
|
|||
|
|
│ branch1的Gutenberg插件构建副本（通过git checkout branch1获取）
|
|||
|
|
│
|
|||
|
|
└── envs/branchX
|
|||
|
|
所有其他分支均复制perf-envs/branch1的目录结构
|
|||
|
|
|
|||
|
|
完成目录准备后，性能测试指令将循环执行各性能测试套件（文章编辑器与站点编辑器），并执行以下操作：
|
|||
|
|
|
|||
|
|
1. 启动`branch1`对应环境
|
|||
|
|
2. 运行当前套件的性能测试
|
|||
|
|
3. 停止`branch1`对应环境
|
|||
|
|
4. 对其余所有分支重复前三步操作
|
|||
|
|
5. 计算当前套件所有性能指标的中位数值
|
|||
|
|
|
|||
|
|
所有测试套件执行完毕后，将生成汇总报告。
|
|||
|
|
|
|||
|
|
## 通过CodeVitals追踪性能
|
|||
|
|
|
|||
|
|
每次提交的性能结果将推送至codevitals，可在[Gutenberg数据看板](https://www.codevitals.run/project/gutenberg)查看。通过趋势图可追踪特定指标随时间的变化情况。
|
|||
|
|
|
|||
|
|
因此确保所计算指标的稳定性至关重要。这意味着在代码与环境相同的情况下，重复运行测试应获得相近结果。
|
|||
|
|
|
|||
|
|
由于性能任务运行于GitHub CI环境，我们不能完全相信两次相似任务运行获得的数值一致性。例如GitHub CI可能随时间推移分配不同的CPU与内存资源。为缓解此问题，每次在trunk分支运行性能任务时，我们会将当前提交的性能与固定的参考提交哈希进行对比，这样无论环境如何变化，都能持续追踪当前提交与参考提交间的相对差异。
|
|||
|
|
|
|||
|
|
### 更新参考提交
|
|||
|
|
|
|||
|
|
Gutenberg仅支持两个WP版本，这对性能任务产生两方面影响：
|
|||
|
|
|
|||
|
|
- 当Gutenberg支持的最低版本变更时，用于运行性能任务的基础WP版本需同步更新。为此，我们依赖插件`readme.txt`文件中的`Tested up to`标识。每次该标识变更时，性能任务所用版本也会相应调整。
|
|||
|
|
|
|||
|
|
- 更新性能任务使用的WP版本意味着，用于保证性能测试稳定性的参考提交很可能与当前WP版本不兼容。因此每次`readme.txt`中的`Tested up to`标识更新时，必须同步更新`.github/workflows/performance.yml`中使用的参考提交。
|
|||
|
|
|
|||
|
|
新选的参考提交哈希需满足以下要求：
|
|||
|
|
|
|||
|
|
- 与`Tested up to`标识使用的新WP版本兼容
|
|||
|
|
- 已在codevitals.run平台追踪所有现有指标
|
|||
|
|
|
|||
|
|
当发布涉及最低WordPress版本要求变更的插件更新时，需更新Core SVN中失去支持分支的端到端测试GitHub Action工作流，否则该分支在发布后的首次工作流运行将会失败。
|
|||
|
|
|
|||
|
|
可通过在测试矩阵中添加`gutenberg-version`输入来固定工作流中使用的插件版本。[Core-59221](https://core.trac.wordpress.org/changeset/59221)展示了6.4分支的此类变更示例。
|
|||
|
|
|
|||
|
|
**注意：** 请始终使用包含错误修复的最终发行版（例如`x.y.2`或`x.y.3`）。若最终发行版尚未确定，请创建[Trac工单](https://core.trac.wordpress.org/ticket/62488)以免遗忘。
|
|||
|
|
|
|||
|
|
**选择提交的简易方法是选取trunk分支上最近一次通过性能测试的提交。**
|
|||
|
|
|
|||
|
|
## 拓展阅读
|
|||
|
|
|
|||
|
|
- [高性能编辑器的演进之路](https://riad.blog/2020/02/14/a-journey-towards-a-performant-web-editor/)
|