5.7 KiB
性能表现
性能是编辑器应用的关键特性，块编辑器也不例外。
指标衡量
为确保块编辑器在版本迭代和开发过程中始终保持高性能，我们通过性能基准测试任务监控以下核心指标：
部分关键指标包括：
- 加载时间： 编辑器页面加载所需时长。涵盖服务器响应时间、首次绘制时间、首次内容绘制时间、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的目录结构
完成目录准备后，性能测试指令将循环执行各性能测试套件（文章编辑器与站点编辑器），并执行以下操作：
- 启动
branch1对应环境 - 运行当前套件的性能测试
- 停止
branch1对应环境 - 对其余所有分支重复前三步操作
- 计算当前套件所有性能指标的中位数值
所有测试套件执行完毕后，将生成汇总报告。
通过CodeVitals追踪性能
每次提交的性能结果将推送至codevitals，可在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展示了6.4分支的此类变更示例。
注意： 请始终使用包含错误修复的最终发行版（例如x.y.2或x.y.3）。若最终发行版尚未确定，请创建Trac工单以免遗忘。
选择提交的简易方法是选取trunk分支上最近一次通过性能测试的提交。