前端性能对用户体验至关重要，讲解性能优化的文章也很多，本文将介绍基本的原则和方法。
原则
性能优化的首要原则是，优先解决妨碍用户体验的问题。
通过使用工具对性能问题进行度量，确认问题所在并获取到可度量的数据，设计优化方案，执行优化方案后对考察的指标进行比对，最终确认验证是否生效。
什么最优先
用户打开一个网站，首屏多快速度加载出来，多长时间可以进行交互，对用户是否流失极为关键。
因此我们组最优先的目标是，让首屏最重要的内容尽快可视、可交互。
对应的指标
统计性能的指标有很多，其中最重要的有FMP（是否有内容可视）和 TII（是否可以交互）。
但因为FMP中M代表meaningful，通常需要自己去推算，在Chrome中已经使用LMP（最大的可视化的内容）替代。
如何统计
很多在线网站提供了统计数据，但此种数据成为实验室数据，我们通常期望收集到的真实用户的数据。
W3C 2012年制定的Navigation Timing标准，让我们可以在主流浏览器使用performance API获取各阶段的时间。
探查LCP
const observer = new PerformanceObserver((list) => {
for (const entry of list.getEntries()) {
console.log(entry);
}
});
observer.observe({entryTypes: ['largest-contentful-paint', 'longtask']});
使用上述代码可以对LCP进行侦听，但是注意：在网页加载的不同阶段，最大的Content是会变的，因此可能输出多个entry的值。
针对LCP优化的目标尽可能减少LCP的时间。
结合数据上报，我们可以看到上面什么时间点，什么元素在页面已经是可视状态。
探查TTI
TTI在API层面并不支持，可以使用Chrome提供的tti-polyfill，在安装后，就可以在代码中使用如下代码来输出TTI：
import ttiPolyfill from 'tti-polyfill';
ttiPolyfill.getFirstConsistentlyInteractive().then((tti) => {
console.log(tti);
});
针对TTI的优化目标是尽可能让它靠近LCP的值。
单个数据无意义
LCP和TTI的结果，通常会在不同用户、设备、时间上有不同的表现，单个数据值并不具备统计意义。
最好的做法是，结合数据上报，最终得到大量用户的数据，然后取中值。
在手机App上的秒开率，也是这么个思路，即1秒内内容交互的用户的占比。
关键渲染路径
CRP(关键渲染路径) 简单来说就是浏览器将HTML、CSS和JavaScript转化为可见的像素的过程。
有一个标准常被用来衡量CRP(关键渲染路径)的性能：
| 指标名 | 含义 |
|---|---|
| CRP resourcs | 请求资源的数量 |
| CRP KB | 请求资源的大小 |
| CRP length | 代表了从请求从客户端到服务端来回的次数（仅会阻塞渲染的资源） |
客户端的优化策略
理解加载渲染过程
JS阻塞DOM解析，CSS阻塞样式的渲染，我们的目标是尽可能早地渲染render tree的内容。
浏览器会同时发起多个连接去加载CSS和资源，我们希望尽早看到界面样式，因此CSS加载应该放在头部，希望JS代码不要阻塞DOM的解析，因此通常将JS的引入在body标签结束之前的位置。
减少请求资源的数量
我们可以用如下手段来减少请求资源的数量：
- 在