前言
web前端性能优化,老生常谈的话题,也是每个企业每个项目最为关心的问题。为了使用户体验达到极致,我们不得不为每一个细节深思琢磨,尽可能达到我们想要的方案。
面试中我们也常常被问到性能优化的问题,如果胡乱穿插一些优化方案,面试官会感觉没有条理性,我们也回答的没有拿捏感,所有我们更应该有思路、有条理的叙述出一个前端性能优化相对完整的流程
这便文章我将以几个大方向总结性能优化
思路也是从浏览器 -〉资源 -〉图片 -〉代码层面
来讲解
优化模块
浏览器:
-
减少HTTP请求
如Chrome浏览器最多同时允许对同一个域名Host建立6个TCP连接,不同的浏览器有所区别,减少http请求也就是减少我们html里css/js等资源的数量 -
使用HTTP2.0
需要配置一个支持h2的web服务器,并下载安装一张TLS证书,让浏览器与服务器通过h2链接
http2.0优势:- 采用二进制格式传输数据, 1.1是文本格式
- 对消息头采用Hpack进行压缩传输,能够节省消息头占用的网络流量,1.1每次请求,都会携带大量冗余的头信息,浪费了很多宽带资源
- 异步连接多路复用
- Server Push,服务器端能够更快的把资源推送到客户端
- 保持与HTTP 1.1语义的向后兼容性也是该版本的一个关键
-
设置浏览器缓存策略
主要为设置缓存策略:强缓存和协商缓存 -
白屏时间做加载动画
增强用户体验
资源:
-
静态资源cdn
静态css/js/img等资源可以做cdn缓存,这样把资源同步到全国全球各地,用户就能更快访问到 -
静态资源单独域名
- 浏览器请求并发限制(同一域名(包括二级域名)在同一时间支持的并发请求数量的限制)
- cookie传输,单独域名,不会携带cookie
- 方便分流和缓存(动静分离,有利于静态资源做cdn缓存)
-
gzip压缩
使资源体积更小
服务端配置,如nginx可配置支持gzip压缩资源传输的方式
如果浏览器支持gzip解析,服务器就会推送gzip的资源,在http的相应头里可以看到显示Content-Encoding:gzip -
做服务端渲染(SSR)
现在主流框的react、vue导致的一个痛点,就是页面构建交给了客户端来渲染,构建的过程无疑是排在了请求到html/js资源后,也就是至少两次http请求后才开始构建,这无疑是导致白屏的关键点之一,所以做ssr页面的话,能够直接返回页面,减少了不少首屏渲染时间 -
将CSS放在文件头部,JavaScript文件放在底部
单线程js可能会阻滞文档加载
图片:
-
字体图标代替图片图标
一些通用的小图标,如箭头,叉,可以使用字体图标,减少请求,渲染更快 -
精灵图
一些带有企业特色的小图标,如淘宝购物车,笑脸娃娃,可以使用精灵图,让一张图上带有多个小图,然后使用css背景定位来显示出合适的位子,能大大减少请求 -
图片懒加载
为了首屏渲染更快,图片可设置一张加载图代替,当页面在可视区域内时在替换为正真的图片
如果有首屏很大的高清图,可先渲染清晰度低的缩略图,在首页基本构建完成下一次事件循环再去替换为高清图 -
图片预加载
可以在window.onload之后请求一些其他地方需要的图片资源
比如我们有一个活动页使用了高清图,我们可以在它的入口前的首页就加载它,当我们进去页面时,浏览器就会从缓存里读取这张图片 -
使用png格式的图片
PNG 格式是WEB 图像中最通用的格式,它是一种无损压缩格式 -
小于10k的图片可以打包为base64格式
可以使用webpack url-loader处理
代码:
-
慎用全局变量
- 全局变量定义在全局执行上下文,是所有作用域链的顶端。局部找不到就会一直往上找,影响性能
- 全局执行上下文一直存在于上下文执行栈,直到程序退出,不利于GC回收
- 命名污染
-
缓存全局变量
将使用中无法避免的全局变量缓存到局部 -
减少重绘回流
回流:当元素的规模尺寸,布局,隐藏等改变的时候,render dom需要重新构建,这就称为回流
重绘:元素只更新外观,风格,而不会影响布局的,叫重绘 -
节流、防抖
-
少用闭包、减少内存泄漏
-
减少数据读取次数
如for循环优化,减少length读取次数let arr = [1,2,3] for (var i = 0; i < arr.length; i++) { console.log(arr[i]) } // 优化 for (var i = 0, len = arr.length; i < len; i++) { console.log(arr[i]) }
-
文档碎片优化节点添加
dom:document.createDocumentFragment() -
减少判断层级
减少if else,提前return if不满足的逻辑 -
字面量与构造式
数组、对象、字符串等,直接声明比new 更快
项目方案提议(额外)
长列表优化
web worker
web worker是运行在后台的js,独立于其他脚本,不会影响页面你的性能。并且通过postMessage将结果回传到主线程。这样在进行复杂操作的时候,就不会阻塞主线程了。避免 ifarme 嵌套网页
阻止了onload,使用户感觉加载很慢的感觉
与父页面共享浏览器连接池,与父页面并行占用http最大连接数,所以资源加载更慢
不利于seo
兼容性不太好,如小程序里面嵌入h5,h5又使用了ifarme
webpack优化(额外)
减小代码体积
按需加载
提取第三库代码
webpack dll优化
结尾
总体大概分为以上这几类的优化方案, 共20多个小点
如果您有更好更多的前端性能优化方式,欢迎补充!!
后续有其他的优化方案,我会继续补充此文!!欢迎收藏!