先把一次等待的起终点写清楚
区块链性能分析中的延迟，不是脱离场景的单一数字。计时从用户点按钮开始，还是从应用收到提交响应开始，已经会得到不同区间。终点若一个采用首次观察到入块，另一个采用最终确定，两份报告即使都写毫秒，也不能直接据此判断哪个系统更快。
Ethereum交易文档把广播进入待处理集合、被纳入区块及后续最终确定分成不同阶段。用它阅读报告时，应先标出测量覆盖哪些阶段，而不是把区块间隔当作每笔交易等待。本文据此提醒：若页面定时查询后才发现状态变化，记录的还是观察到事件的时刻，可能包含查询间隔。
局部时长与日历时间不要混减
MDN说明，performance.now()返回相对timeOrigin的毫秒值，使用不随系统时钟校正而倒退的单调时钟；Date.now()则采用纪元时间和系统时钟。对同一计时环境中的局部操作，前后两次读数相减有明确含义，但不能拿一个页面的相对读数直接减另一个不同基准的读数。
文档还指出，设备休眠期间是否持续计时存在浏览器与系统差异，时间精度也受环境限制。因此，长时间等待记录应注明页面重载、休眠或测量中断，不能仅因数字保留多位小数就宣称准确。跨设备汇总之前，应先解释各自的时间基准和异常处理方法。
平均值不会告诉你全部等待经历
下面用一组纯粹构造的数字说明分布：五次耗时为100、100、100、100和600毫秒，总和1000，平均值是200毫秒，中位数是100毫秒。它不是任何区块链的实测数据。只读平均值会漏掉那次较长等待，只读中位数同样无法说明末端发生了什么。
分位数试图描述排序后的位置，但报告仍需说明采用的算法和样本数量。不能拿五个构造值包装成可靠的真实网络P95结论，也不能把不同样本范围的分位数混在一张排行表。更有用的展示是把分布、数量和统计口径放在一起，让读者知道数字覆盖谁、遗漏谁。
未完成样本保留状态，不填成零
阅读统计表还应问：观察结束时未完成的记录放在哪里？如果只展示完成样本，应同时给出未完成和失败的数量及定义；把缺失耗时填成零，会把未知等待伪装成即时完成。这是本文的统计口径建议，不是某条链的协议规则，也没有据此发起真实交易或压力测试。
一份可复核的延迟说明，至少应交代起止事件、时钟基准、单位、观察窗口、有效样本数和排除原因。应用版本、查询频率或计时环境改变时，也应保留对应说明。先比较测量方法是否一致，再讨论数值差异，才能避免将浏览器局部体验误写成整条链的处理能力。