前端性能优化汇总
主要分为几个维度：
@1 网络请求层面的优化
- 减少HTTP的请求次数和大小
- 资源的合并压缩
- 雪碧图
- 图片音视频的懒加载
- CSS代码不多的情况下采用内嵌式
- 图片的BASE64
- …
- DNS的预解析
- Connection: Keep-Alive
- 采用缓存机制：强缓存、协商缓存、数据缓存
- 采用HTTP2.0
-
@2 代码渲染层面的优化
减少DOM的层级嵌套
- 避免使用@import，防止阻塞GUI的渲染
- CSS资源的导入放在页面头部，JS资源的导入放在页面的底部「可以设置defer/async」
- 减少DOM的重排和重绘
- 使用Vue/React框架，避免直接操作DOM
- 分离读写
- 文档碎片(或者字符串拼接)实现DOM的批量创建
- 使用一些高性能的样式属性去修改样式：transform…
- 改变样式的元素最好有一个独立的文档流「可以使用position」
- …
- CSS代码的优化
- 避免渲染器层级过深（前缀不要太长）
- 避免使用CSS表达式
- 减少对filter的使用
- 能基于CSS3实现动画的，绝对不用JS「JS最好基于requestAnimationFrame实现动画」
- …
- JS代码的优化
- 堆栈内存的有效管理「含：闭包的合理使用 & 作用域链优化…」
- 避免使用：with、eval等
- 避免循环嵌套和死循环
- 避免死递归
- …
- 基于骨架屏「SSR或者前端骨架屏」，减少首屏加载的时间「防止白屏效果」
- Vue&React代码层面的优化
- …
- …
@3 打包编译层面的优化
@4 信息安全的处理
@5 网站性能监控处理
详细知识点如下：
- CSS样式表置于头部导入，在渲染DOM-TREE的时候预先请求样式资源，让页面渲染速度加快
- 基于ajax/fetch获取的数据，对于不经常更新的做缓存「本地存储」
- 减少DNS解析次数「真实项目中往往是增加解析次数，来多服务器资源部署，但是可以做DNS预解析」
- 实现资源文件的强缓存和协商缓存
- CSS选择器不要太深
- 避免404「SEO优化手段」
- 基于事件委托实现事件绑定「堆栈内存都有优化 & 给动态绑定的元素实现事件绑定」
- 函数的防抖和节流，降低触发的频率
- 尽可能使用CSS3动画，如果需要使用JS动画，则最好使用requestAnimationFrame
- 避免使用TABLE布局
- 使用HTTP2.0来处理「多路复用 & 主动推送 & 减少头信息的传输 & 二进制格式传输」
- cookie存储的信息尽可能少一些「原因：每一次向服务器发请求，都会把cookie带上」
- 不要使用@import导入CSS资源「原因：阻塞GUI的渲染」
- 代码编写中要“低耦合高内聚 「封装」”
- 减少闭包的使用「原因：占用栈内存」，最好手动释放没用的内存 “内存优化”
- 避免循环的多级嵌套「原因：时间复杂度过高」，避免死循环「原因：阻塞JS引擎线程的渲染」
- 避免使用CSS表达式
- sript放在页面底部，而且可以使用defer/async，使其变为异步的
- 图片格式尽可能使用webp{速度快}
- 使用webworker和scoket.io实现数据实时通信，避免长轮询
- 及时清除没用的定时器「率属于内存优化」
- 避免死递归「原因：死递归会导致栈内存溢出」
- 在js中有一些代码尽量少用（打死都别用，性能消耗很大）：with\eval…
- 使用正则表达式虽然可以很方便的处理字符串，但是复杂的正则表达式也会带来性能上的损耗
- 循环中各种方式的性能对比（好->坏）：for/while、内置方法「例如：forEach」、for of、for in
- CSS中减少对filter的使用
- 音视频采用流信息播放
- 终极优化方案：使用CDN
SEO&SEM{SEO搜索引擎优化和SEM百度竞价排名}
CDN：服务器分布式
1. 减少直接对DOM的操作
- 操作DOM耗性能，因为会引发DOM的重排(回流)和重绘
- Vue/React等框架是不需要我们自己操作DOM的「推荐」
- 分离读写
- 基于文档碎片或者字符串拼接等方式，批量实现DOM的创建
- 修改样式尽可能使用transform
要修改样式的元素，尽可能在单独的文档流(层)中「使用position定位」
资源合并&压缩「例如：CSS合并为一个、JS合并为一个、雪碧图… -> webpack」
- 图片/音视频懒加载「首次渲染页面，减少HTTP请求，以此来优化白屏等待时间；当页面渲染完，再去请求真正的图片；」
- 在保证图片不失真的情况下，尽可能压缩大小，或者使用字体图标
- CSS代码不多的情况下，使用内嵌式「原因：减少HTTP请求 & 加快样式渲染」
- 开启HTTP的Connection: Keep-Alive
- 开启服务器端的GZIP压缩
- 图片使用BASE64「正常方式加载图片，需要经历：请求、编码、渲染三个步骤，而每个步骤都需要一些时间」，而BASE64是直接给图片设置对应的编码，浏览器只需要渲染即可「问题：BASE64码太长了，不方便开发和维护，也增加了页面请求的时间，所以真实项目中，BASE64我们一般会基于webpack编译生成，而且不要过度使用」
3. 前端骨架屏方案 => 首次渲染更快，减少页面白屏等待时间
- 服务器渲染{SSR}「vue:nuxt.js react:next.js」
- 服务器渲染有利于SEO优化，而客户端渲染是做不了的
- 在“服务器并发压力较强”的情况下，服务器渲染是可以更快实现页面渲染的
- 弊端：导致服务器压力过大、前后端没有完全分离…
- 服务器只需要完成首屏信息的渲染即可，其余屏幕还是交给客户端完成
- 纯前端骨架屏方案「Loading效果」
+客户端渲染
+服务器端渲染
+服务器只需要完成首屏信息的渲染即可，其余屏幕还是交给客户端完成
全栈开发
若有收获，就点个赞吧
0 人点赞
