前端性能优化

web性能

web 性能是网站或应用程序的客观度量和可感知的用户体验

1. 减少整体加载时间: 减小文件体积、减少http请求、使用预加载
2. 使网站尽快可用： 仅加载首屏内容，其他内容根据需要进行懒加载
3. 平滑和交互性： 使用CSS 替代JS动画、减少UI重绘
4. 感知表现: 你的页面可能不能做得更快，但你可以让用户感觉更快，耗时操作要给用户反馈，比如加载动画、进度条、骨架屏等信息
5. 性能测定: 性能指标、性能测试、性能监控持续优化

<一>、web性能优化的准备工作

1. 首先需要了解性能指标
2. 使用专业的工具可量化地评估出网站或应用的性能表现
3. 然后立足于网站页面响应的生命周期，分析造成较差性能表现的原因；
4. 然后进行技术改造、可行性分析等具体的优化措施
5. 迭代优化

<二>、web性能优化的思路

1. 从发出请求到收到响应的优化，比如DNS查询、HTTP长链接、HTTP2、HTTP压缩、HTTP缓存等
2. 关键渲染路径优化、比如是否存在非必要的重绘和回流
3. 加载过程的优化，比如延迟加载、是否有不需要在首屏展示的非关键信息，占用了页面加载的时间
4. 资源优化，比如图片、视频等不同的格式类型会有不同的使用场景，在使用过程中是否恰当。
5. 构建优化，比如压缩合并、基于webpack构建的优化方案

web性能指标

<一>、RAIL性能模型

• RAIL(Response, Animation, Idle, Load)
  * Response: 响应， 应该尽可能快速的响应用户，应该在100ms内响应用户输入
  * Animation: 动画， 在展示动画的时候，(60帧/秒)每一帧应该以16ms进行渲染，这样可以保持动画效果的一致性，并且避免卡顿
  * Idle: 空闲，当使用javascript主线程的时候，应该把任务划分到执行时间小于50ms的片段中去，这样可以释放进程，以进行用户交互
  * Load: 加载，应该在小于1s的时间内加载完成你的网站，并可以进行用户交互
• 是谷歌团队15年提出的性能模型，用于提升浏览器内的用户体验和性能

延迟	用户反映
0～16ms	人眼可感知每秒60帧的动画，每帧16ms，除了浏览器一帧画面绘制到屏幕上的时间，网站应用大约需要10ms来生成一帧
0～100ms	在改时间范围内响应用户操作，才是流畅体验
100～1000ms	能够感觉到明显的延迟
>1s	用户注意力将离开对执行任务的关注
>10s	用户感到失望，可能会放弃任务

<二>、基于用户体验的性能指标

1. FCP: First contentful paint
   • 首次内容绘制, 浏览器首次绘制来自DOM的内容的时间，内容必须是文本、图片（包含背景图），非白色的canvas或SVG，也包括带有正在加载中的字体的文本
   • 这是用户第一次看到页面的内容，但仅仅只有内容，并不意味着它是有用的内容（Header、导航栏等）、也不意味着有用户要关注的内容。
   • 优化方案参考： https://web.dev/fcp/#how-to-improve-fcp

FCP时间(秒)	绿色编码	FCP分数(HTTP存档百分位数)
0-2	绿色(快速)	75-100
2-4	橙色(中等)	50-74
> 4	红色(慢)	0-49

2. LCP: Lagest Contentful Paint
   • 最大内容绘制: 可视区域中最大的内容元素呈现在屏幕上的时间，用于估算页面的主要内容对用户可见时间
   • LCP 考虑的元素:
     • <img> 元素
     • <image> 元素内的 <svg>元素
     • <video> 元素（封面图）
     • 通过 url() 加载的背景图片元素
     • 包含文本节点或者其他内联级文本元素子级的块级元素
   • 为了更好的体验，网站应力争使用2.5s或者更短的“最大内容绘制”。为了确保达到这一目标，衡量移动设备和台式机设备的网页加载量的第75个百分位数是一个很好的衡量标准
   • 优化方案： https://web.dev/lcp/#%E5%A6%82%E4%BD%95%E6%94%B9%E8%BF%9B-lcp

LCP时间（秒）	颜色编码
0-2.5	绿色(快速)
2.5-4	橙色(中等)
> 4	红色(慢)

3. FID: First Input Delay

   • 首次输入延迟，从用户第一次与页面交互到浏览器实际能够响应用户交互的时间点
   • 输入延迟的主要原因是，浏览的主线程正在忙于做其他事情（加载、解析应用程序），不能响应用户输入
   • 实际上浏览器接收用户输入操作时，主线程忙于执行一个耗时比较长的任务，任务执行完成之后才可以响应用户的输入，用户必须等待的时间就是页面上该用户的FID值
   • 在响应用户交互之前需要等待主香橙完成正在进行任务的元素
     • 文本输入框、复选框、单选按钮(<input>、<textarea>)
     • 下拉选择菜单(<select>)
     • 链接(<a>)
   • FID的速度指标: 100ms-300ms
   • 优化方案: https://web.dev/fid/#%E5%A6%82%E4%BD%95%E6%94%B9%E8%BF%9B-fid

4. TTI: Time to Interactive

   • 网页第一次大道可交互状态的时间点
   • 浏览器可以持续性响应用户输入，完全达到可交互状态时间点在最后一个长任务(Long task)完成的是假，并且在随后的5s内没有网络和主线程是空闲的
   • Long Task 长任务: 长任务是需要50ms以上才能完成的任务
   • 优化方案: https://web.dev/tti/#%E5%A6%82%E4%BD%95%E6%94%B9%E8%BF%9B-tti

TTI指标(秒)	颜色编码
0-3.8	绿色（快速）
3.9-7.3	橙色（中等）
> 7.3	红色(慢)

5. TBT: Total Block Time
   • 总阻塞时间, 度量了FCP和TTI之间的总时间，在该范围内，主线程被阻塞足够长的时间，以防止输入响应
   • 只要存在长任务，线程就会被认为是阻塞的，该任务在主线程上运行超过50ms
   • 主线程被阻塞是因为浏览器无法终止正在执行的任务
   • 如果用户确实在较长的时间内无法和页面进行交互，浏览器必须等待任务完成才能进行响应，如果任务执行的时间较长，则用户可能会明显的感觉到延迟并感觉页面缓慢或者时间过长
   • 页面总阻塞时间是fcp和tti之间发生的每个长任务阻塞时间之和
   • 优化方案：https://web.dev/tbt/#%E5%A6%82%E4%BD%95%E6%94%B9%E8%BF%9B-tbt

TBT时间(毫秒)	颜色编码
0-300	绿色(快速)
300-600	橙色(中等)
> 600	红色(慢)

6. CLS: Cumulative Layout Shift
   • 累积布局偏移
   • CLS 会测量在页面整个生命周期中发生的每个意外布局以为的多有单独布局移位份数的综合
   • CLS 是一种保证页面视觉稳定性从而提升用户体验的指标
   • 优化方案: https://web.dev/cls/#%E5%A6%82%E4%BD%95%E6%94%B9%E8%BF%9B-cls

CLS时间(毫秒)	颜色编码
0-0.1	绿色（快速）
0.1-0.25	橙色（中等）
> 0.25	红色（慢）

7. Speed Index
   • 速度指标: 是一个表示页面可视区域中内容的填充速度的指标，通过计算页面可见区域内容显示的平均时间来衡量

<三>、Web Vitals

Web Vitals 是google 15 给出的定义一个良好网站的基本指标

1. 过去衡量一个网站的好坏，需要通过很多指标去进行衡量。
2. Web Vitals 可以简化指标的学习曲线，值需要聚焦于 Web Vitals 指标的表现即可
3. Web Vitals 的重要核心:
   • LCP
   • FID
   • CLS

Web 性能测试工具

<一>、 使用 Lighthouse 测试性能

Lighthouse 是由Google 开发并开源的Web 性能测试工具，通过监控和检测网站应用的各方面性能表现，为开发这提供优化用户体验和网站性能提供指导建议

Lighthouse 性能报告, Lighthouse 给出的信息包括:
* 检测得分
* 性能指标
* 优化建议
* 诊断结果
* 通过审核的性能

1. 检测得分

经过检测，Lighthouse会根据 FCP、SI、LCP、TTI、TBT、CLS 几个纬度给出一个0-100的评分

1. 如果没有评分或者分数为0，很可能是检测过程发生了错误，比如网络链接状况异常等
2. 如果分数达到了90分以上，则说明网站应用在该方面的评估表现符合最佳实践
3. 关于如何得到这个评分：Lighthouse 首先会获得关于评估指标的原始性能数据，然后根据指标权重进行加权计算，最后以其数据苦中大量的评估结果进行对数正态分布的映射计算并计算最终得分
   

2. 性能指标

1. 6种不同的指标数需要通过加权计算，才能得到关于性能的最终评分，所以加权值越大表示对英指标对性能的影响就越大，Lighthouse 的权重情况:

Audit	Weight
FCP	15%
Speed Index	15%
LCP	25%
TTI	15%
TBT	25%
CLS	5%
该权重系统还在不断的优化过程中，虽然Lighthouse对其中个别指标给予了较大的权重，也就意味着对改指标的优化能带来更为显著的性能评分提升，但是还是建议在优化的过程中切勿只关注单个指标的优化，而要从整体性能的提升上考虑优化的策略*

3. 优化建议

1. 按照这些建议进行优化之后能带来的提升效果从高到低进行排序，每一项展开还有有更加详细的优化指导建议，从上到下依次包括:
   • (1). 移除阻塞渲染的资源: 部分js脚本文件和样式表文件可能会阻塞系统对网站页面的首次渲染，建议可以将其以内嵌的方式进行引用，并考虑延迟加载。报告会将涉及需要优化的资源文件排列在下面，每个文件还包括尺寸大小信息和优化后预计提神首屏渲染时间的效果，据此可安排资源文件优化的优先级
   • (2). 预链接所要求的源: 提前建立与所要访问资源之间的网络链接，或者加快域名解析额速度都能有效的提高页面的访问性能。这里给出了两种方案： 一种是设置（link rel=“preconnect”）的预链接，另外一种是设置(link ref=“dns-prefetch”) 的DNS解析
   • (3). 降低服务器响应的时间: 通常引起服务器响应缓慢的原因有很多，因此改进的方案也很多：比如升级服务器硬件以拥有更多的内存或cpu,优化服务器应用程序逻辑以更快地构建出所需的页面或资源，以及优化服务器查询数据库等。不要认为这些优化都和前端无关就不去关注，通常node服务器转发层就需要前端进行相应地优化
   • (4). 适当调整图片大小： 使用大小合适的图片可以节省网络带宽(单位时间内传输的数据量)并缩短加载用时，此处的优化建议通常对于本应用使用较小尺寸的图片就可以满足，但却使用了高分辨率的大图，对此进行适当的压缩即可
   • (5). 移除未使用的css: 这部分列出了未使用但却被引入的css文件列表，可以将其删除来降低对网络带宽的消耗，若需要对资源文件的内部代码使用率进行进一步的精简删除，则可以使用Chrome 开发者工具的Coverage面板进行分析

4. 诊断结果

主要从影响网站页面性能的多个维度进行检测和分析得到的一些数据

• (1). 对静态资源文件使用高效的缓存策略，这里列出了所有静态资源的文件大小及缓存的过期时间，开发者可以根据具体情况进行缓存策略的调整，比如延迟一些静态资源的缓存期限来加快二次访问时的速度
  

• (2).减少主线程的工作: 浏览器渲染进程的主线程通常需要处理大量的工作，如解析HTML构建DOM,解析CSS样式表文件并应用指定的样式，以及解析和执行javascript文件，同时还需要处理交互事件，因此渲染进程的主线程过忙容易导致用户响应延迟的不良体验。Lighthouse 给我们提供了这一环节网站页面主线程对各个人物的执行耗时，让开发者可以针对异常处理过程进行有目标的优化

• (3). 降低javascript脚本执行时间： 前端项目的逻辑基本时依托于javascript执行的，所以javascritpt执行效率与耗时对页面性能产生了不小的影响，通过对这个维度的检测可以发现执行好事过长的js文件, 进而针对性的优化javascript解析、编译和执行的耗时

• (4). 避免存在较大尺寸网络资源的请求： 因为如果一个资源的尺寸较大，那么浏览器就需要等待其完全加载好，才能进行后续的渲染操作，这就意味着耽搁文件的尺寸越大其阻塞渲染流程的时间就越长，并且网络传输过程中存在丢包的风险，一旦大文件传输失败，重新传输的成本也会很高，所以应当尽量将较大尺寸的资源进行优化，通常一个尺寸较大的代码文件可以通过构建工具打包成多个尺寸较小的代码包，对于图片文件如非必要还是建议在符合视觉要求的前提下尽量进行压缩。可以看出该检测维度列出的大尺寸资源文件基本都是图片文件

5. 已经通过性能审核项

• (1). 延迟加载首屏视窗外的图片: 改审核项的优化原理在有关图像优化章节有过详细介绍，对首屏关键资源加载完毕之后，延迟首屏外或处于隐藏状态的图片加载能够有效的缩短用户可交互前的等待时间，提升用户访问体验
• (2). 压缩css文件: 可以降低网络负载规模
• (3). 压缩js文件: 可以降低网络负载规模
• (4). 对图片采用高效的编码方式： 经过编码优化的图片文件，不但其加载速度会更快，而且需要传输的数据规模也会很小
• (5). 采用新一代的图片文件格式: WebP、JPEG XR、JPEG 2000 等较新的图片文件格式通常比传统的PNG或JPEG 有更好的压缩效果，能够获得更快的下载速度和更少的流量消耗，但使用的同时还需要注意对新格式图片的兼容性处理
• (6). 开启文本压缩: 对于文本资源，先压缩在提供能够最大限度地减少网络传输的总字节数，常用的压缩方式有gzip,deflate和brotli,至少采用其中一种即可
• (7). 避免多次页面重定向： 过多的重定向会在网页加载前造成延迟
• (8). 预加载关键请求: 通过<link rel="preload">来预先获取网页加载后期需要请求的资源，这主要是为了充分利用网站运行的间歇期
• (9). 使用视频格式提供动画内容: 建议通过WebP或MPEG4提供动画，来取代网页中大型GIF动画
• (10). 避免DOM规模过大: 如果规模过大，则可能会导致消耗大量的内存空间，过长的样式极端耗时及较高的页面布局重排代价。Lighthouse 给出的参考建议是，页面包含的DOM元素最好少雨1500个，树的深度尽量控制不要超过32层
• (11). 确保网页字体加载期间文本内容可见: 使用CSS 的 font-display 功能,来让网站页面的文本字体在加载期间始终可见