一起养成写作习惯！这是我参与「掘金日新计划 · 4 月更文挑战」的第9天，点击查看活动详情。
一般来说，我们认为网站性能大概分为两种：加载性能和交互性能。加载时间的长短以及交互反馈的时间是否及时能反应到界面上会提供给用户直接的预期感受。
加载性能
指的是指用户从输入URL或者进入你的网站到可以与用户可以持续进行交互的这段时间。这段时间决定了用户的对网页的整体评价。
通常，越快的网页加载性能，会提升用户的留存概率，而较长的白屏时间让用户等待，会降低用户的留存率，毕竟大家都这么忙，很少人会对着白色的屏幕发呆十几秒钟。
造成网页加载的性能有很多：网络速度，硬件性能，代码的执行效率，资源的大小等都会影响我们看到完整界面的时间。你需要清晰地知道浏览器是怎么样呈现一张网页的，然后在顺着这条线去发现问题。
交互性能
交互性能指的是，用户在网页可以完全交互后，在交互的过程当中，界面的流畅程度。
交互性能一般与渲染帧数以及界面时间反馈有关系。人的眼睛能看到60帧（FPS）的动画为流畅，因此，如果界面的持续变化维持在60FPS会给用户的感觉提供很好的反馈。
其次是对输入行为的时间响应，如果事件延迟执行100~300ms用户就会感觉到响应延迟，从而给客户带来流畅性不佳的体验。
开发中常见的性能调试工具，来帮助定位网页的性能
1.Dev tools
相信任何做前端的工程师都离不开这个工具，它是集成到谷歌浏览器中的工具面板（在其他的浏览器中也有相关的工具，例如firefox的firebug等。我们对他们的统称为dev tools），提供给开发者专业全面的信息。其中功能非常丰富，你甚至可以在里面发现一些彩蛋。
2.Lighthouse
Lighthouse是一种基于web的网页测试性能的系统，你只需要在输入框中输入你需测试的网站的地址，它就会给出我们之前提到过的各种指标。当然，这些指标只是基于特定的环境（网络，机器，浏览器）下进行评估的，不具备普遍性。Lighthouse集成在chrome浏览器中，你可以很方便地使用它对网页进行整体的性能评估。
3.Fiddler & Charles & Wirmsharp
Fiddler和Charles分别是一款在window上和ios上的抓包工具。他们的功能都是非常丰富，提供了抓包，替换，监控请求的诸多功能。相对于前两者来说，wirmsharp在更深层次的细读上更加详细。但对于我们日常开发来说，选择前两者就足够了。抓包工具无论在开发还是在测试的过程中都非常有用，它不仅可以快速地定位问题的根源，而且在线上调试上有很好的辅助作用。
4.WebpageTest
和Lighthouse一样，webpagetest也是基于网页的性能测试系统，同样是输入测试网站地址，它会给出结果，只不过它侧重http的方面的，而且在网络细度上具备丰富的可调节性，例如，可以测试某个地方的网页加载速度，可以在地图上选择即可。对CDN的应用的效果测试十分重要。
5.Chrome User Experience Report
CUER是一项google的性能检测计划，通过引入google提供的脚本，将我们的客户端数据上报google，从而统计你的网页的性能报告和评估。开发者可通过查询该数据集来了解使用不同硬件、软件和网络的实际 Chrome 用户的上网体验。分析很多网络原点可帮助网站开发者和网络社区了解它们的表现出色之处，发现需要改进的领域。
6.Eruda
Eruda是在移动端开启调试的利器。它通过模拟PC端的devtools，提供给我们移动端的一个类似的dev tools的调试界面。在调试网络和缓存方面尤其有用。缺点就是功能远远不如桌面版真实的dev tools强大。这是一个阉割版本的调试工具，功能非常有限。
具体优化策略
1. 减少HTTP请求数
这条策略基本上所有前端人都知道，而且也是最重要最有效的。都说要减少HTTP请求，那请求多了到底会怎么样呢？首先，每个请求都是有成本的，既包 含时间成本也包含资源成本。一个完整的请求都需要经过DNS寻址、与服务器建立连接、发送数据、等待服务器响应、接收数据这样一个“漫长”而复杂的过程。时间成本就是用户需要看到或者“感受”到这个资源是必须要等待这个过程结束的，资源上由于每个请求都需要携带数据，因此每个请求都需要占用带宽。
另外，由于浏览器进行并发请求的请求数是有上限的，因此请求数多了以后，浏览器需要分批进行请求，因此会增加用户的等待时间，会给 用户造成站点速度慢这样一个印象，即使可能用户能看到的第一屏的资源都已经请求完了，但是浏览器的进度条会一直存在。减少HTTP请求数的主要途径包括：
2. 从设计实现层面简化页面
如果你的页面像百度首页一样简单，那么接下来的规则基本上都用不着了。保持页面简洁、减少资源的使用时最直接的。如果不是这样，你的页面需要华丽的皮肤，则继续阅读下面的内容。
3. 合理设置HTTP缓存
缓存的力量是强大的，恰当的缓存设置可以大大的减少HTTP请求。以有啊首页为例，当浏览器没有缓存的时候访问一共会发出78个请求，共600多K 数据（如图1.1），而当第二次访问即浏览器已缓存之后访问则仅有10个请求，共20多K数据（如图1.2）。（这里需要说明的是，如果直接F5刷新页面 的话效果是不一样的，这种情况下请求数还是一样，不过被缓存资源的请求服务器是304响应，只有Header没有Body，可以节省带宽）
怎样才算合理设置？原则很简单，能缓存越多越好，能缓存越久越好。例如，很少变化的图片资源可以直接通过HTTP Header中的Expires设置一个很长的过期头；变化不频繁而又可能会变的资源可以使用Last-Modifed来做请求验证。尽可能的让资源能够 在缓存中待得更久。
4. 资源合并与压缩
如果可以的话，尽可能的将外部的脚本、样式进行合并，多个合为一个。另外，CSS、Javascript、Image都可以用相应的工具进行压缩，压缩后往往能省下不少空间。
5. CSS Sprites
合并CSS图片，减少请求数的又一个好办法。
6. Inline Images
使用data: URL scheme的方式将图片嵌入到页面或CSS中，如果不考虑资源管理上的问题的话，不失为一个好办法。如果是嵌入页面的话换来的是增大了页面的体积，而且无法利用浏览器缓存。使用在CSS中的图片则更为理想一些。
7. Lazy Load Images
这条策略实际上并不一定能减少HTTP请求数，但是却能在某些条件下或者页面刚加载时减少HTTP请求数。对于图片而言，在页面刚加载的时候可以只 加载第一屏，当用户继续往后滚屏的时候才加载后续的图片。这样一来，假如用户只对第一屏的内容感兴趣时，那剩余的图片请求就都节省了。有啊首页曾经的做法 是在加载的时候把第一屏之后的图片地址缓存在Textarea标签中，待用户往下滚屏的时候才“惰性”加载。
