作者 | Bas Schouten
对任何软件来说，一个最大的挑战就是确定更改对用户体验的影响。不管是视频编辑软件的处理速度，还是浏览体验的流畅度，在控制良好的实验环境中测试只能告诉我们有限信息。虽然本地实验可以提供很多指标，但这些指标的改进不一定能带来更好的用户体验。
这对运行第三方代码的复杂客户端软件，例如Firefox，尤其具有挑战性。这也是我们与其他浏览器一起进行Speedometer 3 工作的一个主要原因。我们的目标是构建模拟真实用户体验的性能测试，这样浏览器就有更好的工具来为真实网站上的真实用户带来改进。当然，我们能看到Firefox在今年通过这项工作取得的各种测试指标上升，但我们真正关心的是这些改进能够为我们的用户带来多大好处。
为了衡量用户体验，Firefox会收集和匿名化地记录与页面加载、响应性、启动等各种浏览器性能相关的参数。在保持隐私标准的最高水平的前提下收集数据也是一个挑战。比如，由于我们依赖于汇总指标，我们无法追踪来自任何特定网站的数据。但更大的挑战可能是分析收集到的数据并得出可操作的结论。未来我们会更详细地介绍这些挑战以及我们的解决方法，但在这篇文章中，我们想分享一些反映用户使用浏览器体验的基础指标在今年的改进情况。
我们从页面加载开始。首次内容绘制（First Contentful Paint，FCP）比 onload 事件更好地反映性能体验。我们追踪从接收第一个网络字节到FCP的时间。这告诉我们浏览器在成功加载页面提供反馈的速度有多快，这是一个了解用户体验的关键指标。尽管这很大程度上取决于网页本身，但如果浏览器整体性能得到提升，我们预期这个数字会下降。
图1：从响应开始到首次内容绘制的中位数时间（毫秒）
我们可以看到，从年初的大约250毫秒到10月的215毫秒，这个时间有了接近15%的改进。这意味着用户得到反馈的页面加载速度比年初快了近15%。重要的是，这完全是优化工作的结果，而这些工作并没有明确针对页面加载。
为了了解这个改进来自哪里，让我们看看另一项时序数据：页面加载期间执行JavaScript代码花费的时间。在这里，我们将查看第95百分位，这代表最依赖JS的页面，也更突出我们降低用户等待的机会。
图2：页面加载期间执行JS的第95百分位数时间（毫秒）
这显示了从年初的大约1560毫秒下降至10月的1260毫秒。这代表一个约300毫秒或近20%的显著改进，很可能是FCP时间下降的主要原因。这理解起来合理，因为Speedometer 3工作对SpiderMonkey JavaScript引擎进行了大量优化（这是另一篇文章的故事）。
我们也想了解页面加载后响应能力如何。例如，当我写这篇博文时键入时的流畅度如何。我们这里收集的主要指标是“按键反馈延迟”：按下键盘与结果在屏幕上呈现之间的时间。将一些文本渲染到屏幕上似乎很简单，但其实背后有很多工作，尤其是当网页通过主线程JavaScript响应键入事件时。大部分键入速度主要受硬件限制（例如显示器的刷新频率），但性能不好时会非常影响用户体验。这意味着我们需要减少最差情况，所以我们仍将查看第95百分位。
图3：按键反馈延迟的第95百分位数
我们再次看到了明显的改进。大部分时间第95百分位都在65毫秒附近震荡，8月的Firefox 116和117版本发布后下降到59毫秒以下。最慢的按键反馈提高了10%，这意味着用户在打字时会获得更流畅的反馈体验，干扰也会减少。
我们对从遥测数据看到的进步感到振奋。相信今年的工作为Firefox用户带来实实在在的积极影响。我们还有更多优化措施在研发中，将在后续分享详情。
IntelliJ IDEA 2023.3 & JetBrains 全家桶年度大版本更新 新概念“防御性编程”：让自己稳拿铁饭碗 GitHub.com 跑了 1200 多台 MySQL 主机，如何无缝升级到 8.0？ 周星驰 Web3 团队下个月上线独立 App Firefox 会被淘汰吗？ Visual Studio Code 1.85 发布，浮动窗口 余承东：华为明年将推出颠覆性产品，改写行业历史 美国 CISA 建议放弃 C/C++，消除内存安全漏洞 TIOBE 12 月：C# 有望成为年度编程语言 雷军 30 年前写的论文：《计算机病毒判定专家系统原理与设计》