前端性能优化在工作中经常会有这个需求,下面我从请求与响应,静态资源处理,渲染三个层面进行一个全链路的优化处理
请求与响应
先说请求,http请求是基于tcp连接的,在每次请求之前都要进行三次握手这个操作,是相对比较浪费的.
http1.1引入了长连接跟信道的概念,这样就可以节省每次请求的我握手时间,同时信道的出现也解决了http请求排队问题,在单个信道内可以并发多个请求,这样请求就不用排队了,但是返回还是要排队.所以此时如果一个请求堵塞了,后续的也就没法返回了.
http2中解决了http堵塞,http2引入了多路复用,这样请求与响应都不用排队了,所以就不存在一个响应堵塞所有的请求问题.
所以在我们前端如果请求过慢,数据量过大的时候,我们可以拆分请求,就是利用http1.1的并发请求的能力
再说响应, 响应主要是利用浏览器的缓存机制,强缓存和协商缓存,localstorage,indexDB,
强缓存:在请求头命中强缓存时,浏览器不会发送请求而是直接复用缓存数据
协商缓存::在请求头命中协商缓存之后,请求返回304直接告诉你去复用旧数据,
**localstorage :可以用来缓存一些用户信息,以及常用的全局信息
indexDB:可以作为前端的一个小型数据库,存储数据量大的数据
静态资源处理
资源加载这块是为渲染服务的,资源越小占用就越小,反之,加载越快.
-
图片压缩：将图片进行压缩可以大幅减小图片的大小，从而缩短加载时间。压缩图片时需要注意保持图片质量(有损压缩)，以免影响图片显示效果。
-
图片分割：将超大图片分割成多个小图块进行加载，可以避免一次性加载整个图片，从而加快加载速度。这种方式需要在前端实现图片拼接，需要确保拼接后的图片无缝衔接(不好用前端加了很多工作量)。
-
CDN 加速：使用 CDN（内容分发网络）可以将图片缓存在离用户更近的节点上，从而加速图片加载速度。如果需要加载的图片是静态资源，可以将其存储在 CDN 上，以便快速访问。
-
懒加载：懒加载是一种图片延迟加载的方式，即当用户浏览到需要加载的图片时才进行加载，可以有效避免一次性加载大量图片而导致页面加载速度缓慢。
-
WebP 格式：使用 WebP 格式可以将图片大小减小到 JPEG 和 PNG 的一半以下，从而加快图片加载速度(好用推荐)。
-
HTTP/2：使用 HTTP/2 协议可以并行加载多个图片，从而加快页面加载速度。
-
预加载：预加载是在页面加载完毕后，提前加载下一步所需要的资源。在图片加载方面，可以在页面加载完毕后提前加载下一个需要显示的图片，以便用户快速浏览(例如:商城下翻图片加载问题)。 具体使用哪一个根据视情况而定
-
使用文本图标:文本图标体积比图片要小很多
-
小图标转base64:指14k以下,原因是浏览器在渲染图片的时候就会去下载,转了的话就不用下载,但是大图片转了之后体积会过大,得不偿失
-
开启gzip
3.渲染
渲染想要速度快,我觉得没有别的办法只有减少渲染量.以及减少重排重绘.
- 虚拟列表:原理是每次只显示可视范围内得数据,由此大幅度节省渲染成本
requestAnimationFrame的步伐跟着系统的刷新步伐走。它能保证回调函数在屏幕每一次的刷新间隔中只被执行一次，这样就不会引起丢帧现象。适用于不可分页且需要完全展示数据的地方,但是他是挂载到window下的,所以关闭页面的时候记得停止渲染- webworker:现代浏览器为
JavaScript创造的 多线程环境。可以新建并将部分任务分配到worker线程并行运行，两个线程可 独立运行，互不干扰，可通过自带的消息机制相互通信。一般使用Web Worker的场景是代码中有很多计算密集型或高延迟的任务，可以考虑分配给Worker线程。 - 大数据量的带层级结构的下拉框渲染:这个处理方法是我们只渲染最上层数据在点击最上层展开时再去获取填充下层数据,以此来达到优化渲染的目的,
- 节流防抖,减少因为多次点击引起的请求重复发送
