业界领先的企业在软件开发阶段使用性能预算来衡量网站用户体验。性能预算在应用性能的不同阶段为开发者提供了可测量的目标。但是为应用程序选择合适的度量指标至关重要，在Sane Francisico举行的Fluent大会上，Google Chrome DevTools的项目经理Paul Irish指出。

性能预算将与应用性能相关的所有组件分解成具体的度量指标，这样开发人员可以在开发流程的早期阶段有针对性得测试相应的代码。这些度量指标可能包括页面装载时间、交互延迟、动画速度和打断空闲进程的能力。因为开发人员做出改变时，他们可以立即看到针对目标性能预算，这些改变如何影响应用程序。

在上下文中衡量速度

最大的挑战是从用户角度很难衡量“慢”的含义，因为从开发角度来说，“慢”这个词并不精确。真正有意义的描述必须依赖于上下文。比如，10ms对于电子商务网站而言像闪电一样快，但是如果在游戏上下文里，可能就已经相当慢了，Irish说。一些流行的应用性能度量指标包括Dom内容加载时间，每秒帧率，首次渲染和Jank的概念，这是用来描述可感知的缓慢的一个俚语。

但是很多这样的度量指标都没能很好地量化用户的网站体验。因此，企业正在尝试使用不同于可感知的应用缓慢的方式来达到性能目标。“我们想要确保定位到了正确的问题上，并且以正确的方式解决问题，”Irish说。好的度量指标需要在合适的应用上下文里抓取可感知的用户体验。

理解不同延迟的影响

Irish建议企业研究1993年Jako Nielsen完成的可用性研究，该研究成果现在仍然有效。Nielsen测试了应用延迟，从100ms，1000ms（1秒）以及10秒，对网站用户体验的影响。对于大部分应用程序而言，100ms的响应时间给人的感觉就非常快了。1000ms可以保证无缝的用户体验，用户可以在任务间流畅切换。延时如果超过10秒用户就会不想再用了。

接着Irish提出了Neilsen模型的短板在于一些操作上，比如即时应用反馈。即使只有10ms的延时，在用户手指接触点和视觉反馈上，仍然会有很明显的延迟。这样的延迟只有应用能在1ms内响应时才会消失。

使用RAIL模型量化网站用户体验

Google已经开发了RAIL（Response, Animation, Idle and Load Page， 响应，动画，空闲和加载页面）响应模型，将不同阶段的应用流程和用户可感知的性能关联了起来。该模型给企业提供了可以之后在应用性能预算里使用的可测量的目标。

根据Irish的观点，从接触到渲染必须少于100ms，这时用户才能感受到即时响应，而接触和移动必须少于16ms。动画效果必须在16ms内完成每一帧的渲染，这对应于现代浏览器60fps的渲染速度。页面加载必须在1000ms内完成，才能达到无缝的用户体验。

在RAIL模型里，空闲帮助量化后台进程可以被打断的速度。这给应用的架构带来了很大的挑战，这样当用户开始交互时后台任务能够快速中断。“当用户不活跃时，应该安排后台工作，”Irish建议，“但是任何时候用户都可能再次交互，我们需要随时准备着。”要达到这个目标，Irish继续道，主要的JavaScript线程需要能在50ms的空隙里完成工作。

制定正确的性能预算

接下来，Irish讨论了一些Chrome的开发任务来帮助企业级开发人员达到应用性能预算目标。Chrome新增加的一个功能是瀑布视图，可以让开发人员更容易看到网络瀑布里发生的事情和页面外观之间的关联。工具不仅仅报告网络活动，而且会记录每一帧和页面的更新。

只有当发生文件请求时这才会显得更重要，因为这给用户直接的感受页面加载流畅度。Irish已经在主流网站，比如ESPN、CNET和Time.com上发布了性能审计，帮助解释如何将这些原则应用到实际情况中。Irish认为RAIL是开始讨论的起点，可以作为模型来评估企业总体性能预算的性能参数。