引言
前端面试时常常会问的一个问题，“做了哪些性能的优化，取得了什么效果”。性能确实是我们老生常谈的话题，要做好性能优化，首先要准确地评价一个系统性能，本文旨在列举关于性能的一些常见的谬论。(部分论点来自 Google I/O 2017 大会）
谬论一：“经过我的优化，我的网站加载时间为 X 秒”
这是面试中我听到最多的陈述，甚至不少文章的也是类似的标题党，就差加上“震惊了”。这样陈述最大的问题并不在于不真实，而是不能完全反映事实的全部信息。就像说我和李嘉诚的平均财富也能富可敌国。
统计学告诉我们，不同的描述性统计量都只能描述分布的一个侧面，没办法使用单独一个甚至几个统计量就能把总体的分布描述清楚。
实际上，加载时间会因为用户不同而有很大的变化，具体取决于用户的设备功能以及网络状况。以单个数字的形式呈现加载时间忽略了遭遇过长加载时间的用户。要全面准确地反映加载性能的唯一方法是使用以下分布直方图来展示：
之所以说“我网站的加载时间为 X 秒”是谬论的另一个原因是，加载性能是一种单一指标无法全面反映的用户体验。在加载过程中，有多个时刻会影响到用户对速度的感知，如果只关注其中某个时刻，就可能会遗漏其余时间内用户感受到的不良体验。
如果用户可以看到页面上的链接但无法点击，或者可以看到文本框但无法在其中输入内容，他们可能就不会关心页面渲染的速度有多快。
谬论二：性能只是 load 时间或者 DOMContentLoaded 时间的问题
load 时间，和 DOMContentLoaded 时间曾一度是开发者关注的传统性能指标。甚至在9102年的今天，仍然不少开发者只关注着这两个指标。主要原因大概是因为这两个指标概念简单，而且非常容易获取。
在遥远的过去，页面交互简单（ jQuery 就是一把梭），由服务端渲染（主要指 php 和 Java ），加载性能还勉强能用 load 时间，和 DOMContentLoaded 时间来描述。
然而在今天，大量页面使用异步渲染，或者说客户端渲染。继续用这两个指标来描述加载性能是非常不可靠的，因为应用是否加载完成、是否可用，已经和 load 时间没有必然的对应关系。
事实上，不只限于加载期间，在整个应用的生命周期都有可能发生性能不佳的情况。 应用无法迅速响应点击操作，以及无法平滑滚动或产生动画效果的问题，与加载缓慢一样都会导致糟糕的用户体验。用户关心的是总体体验。
例如，假设某网站针对初始渲染进行过优化（主要是 First Paint 和 First Contentful Paint），使用户在较短的时间内能看见页面在加载。然而在此之后，该网站需要加载一个花费数秒来解析和执行的大 JS 文件，只有在 JavaScript 运行之后，页面上的内容才可供交互。
因此，我们不应该只使用一个指标来衡量加载，而应该衡量整个体验过程中可能影响用户对加载感知的每个时刻。
结语
下一篇再讲一下以用户体验为中心应该关注哪些性能指标。
