vue中常见的性能优化,vue提高性能
本文主要介绍了一些在vue项目中使用的性能优化技巧的例子。有需要的朋友可以借鉴一下,希望能有所帮助。祝大家进步很大,早日升职加薪。
目录
介绍性能优化标准灯塔通用常规优化手段通用性能优化分析FCP(第一内容全绘)LCP(大内容全绘)Speedex (SpeedIndex)故障排除性能瓶颈分析包内容利用chorme devtool的代码覆盖率对vue图片进行专门优化利用v-show和KeepAlive复用dom批量渲染组件在vue中懒人加载虚拟滚动功能组件最后
引言
说到性能优化,浮现在很多人面前的面试经历是否历历在目?反正在我看来,性能优化永远是前端领域的热门王。
不过最近这个渣的维修项目正好在这个方向下了很大功夫。下面是一些经验,希望对大家有些帮助!
性能优化标准
既然说性能优化,他肯定有一个公认的标准,这也是我们多次听到的关于灯塔的标准。
许多公司都有自己的绩效监控平台。我们只需要引入相应的sdk,就可以分析你的页面在平台上的性能问题。大家都学会了,是不是很神奇?
其实除了业务需求,还需要特殊定制。大多数情况下,我们公司的性能优化平台其实就是用无头浏览器运行灯塔。
了解了我们公司的性能监控平台的原理之后,就可以有针对性的做性能优化了,也就是为灯塔编程。
Lighthouse
Lighthouse是谷歌Chrome推出的开源自动化工具。它可以收集许多现代网页性能指标,分析Web应用的性能并生成报告,为开发者优化性能提供了参考方向。
说到Lighthouse,它已经被集成到了现代的谷歌浏览器中。
他可以通过几个指标来分析我们的页面表现。
Lighthouse衡量以下绩效指标:
第一幅内容丰富的画。即浏览器第一次绘制任何内容(如文本、图像、画布等)的时间。)在屏幕上。互动时间(互动时间)。指的是所有页面内容都已成功加载并能快速响应用户操作的时间点。速度指数(速度指数)。测量可视内容的第一屏在屏幕上的绘制速度。在页面第一次加载的过程中尽可能多的展示内容,往往能给用户带来更好的体验,所以速度指数的值越小越好。总阻塞时间(总阻塞时间)。它是指从第一次内容丰富的绘画(FCP)到交互时间(TTI)之间的总时间。该度量报告视窗中可见的最大图像或文本块的显示时间的累积布局偏移(#累积布局偏移)。它测量页面整个生命周期中每个元素的意外布局偏差分数的总和。每当两个渲染帧中的可视元素的起始位置不同时,就会发生LS(布局偏移)。一般情况下,根据我的经验,由于成绩监控平台和本地平台的差异,本地平台有可能达到70分,只有线上平台才有可能通过考试。如果有性能优化的需求,可以酌情处理(但我认为,你是可以通过考试的。毕竟大学考试有句话:60分万岁,61分浪费,传承不能丢。我们应该在更重要的事情上花更多的时间。)
通用常规优化手段
lighthouse的优势在于,它可以在你的页面中发现一些常见的性能瓶颈,并提出优化建议,比如:
所以对于这些优化建议,我们需要做一些常规的优化:
减少不使用的javascript,移除阻碍渲染的资源,压缩图像质量,限制使用的字体数量,尽可能少的使用变体来优化关键渲染路径:只加载当前页面渲染必需的资源,页面渲染完成后再加载二级资源。
通用性能优化分析
我们知道灯塔有六个性能指标,而在这六个指标中,LCP、FCP、速度指数和这三个指标尤为重要,因为一般来说,这三个指标会影响TTI、TBT和CLS的得分。
因此,我们在优化时,需要提高LCP、FCP和speedIndex的得分。经过测试,即使是空页也会耽误时间,初始成绩基本都是0.8秒。
注:需要注意的是,我们目前所有的测试都是基于移动端的(之所以使用移动端是因为pc强大的计算能力,性能瓶颈少),页面上必须有一些内容才能得到分数,内容必须包括以下一项或多项
嵌入svg元素的图像元素视频元素(使用封面图像)url()函数加载的带有背景图像的元素(而不是使用CSS渐变)包含文本节点的块级元素或者内联级文本元素的其他子元素。否则,将会出现以下错误
接下来,我们将从LCP、FCP和speedIndex开始。
FCP(First Contentful Paint)
顾名思义,就是第一次绘制内容,也就是页面开始绘制内容的时间。但是由于我们现在开发的页面都是spa应用,所以框架层面的初始化肯定会有一定的性能损失。以vue-cli搭建的脚手架为例。当我初始化空脚手架,打包上传到cdn进行部署时,FCP会从0.8s提升到1.5秒。可见vue的diff并不是免费的,他也会有性能损失。
在优化页面内容之前,我们声明三个前提。
提高FCP的时间实际上是优化关键的渲染路径。如果是样式文件(CSS文件),浏览器在渲染页面之前必须对其进行全面解析(这也是CSS有渲染阻碍的原因)。如果是脚本文件(JavaScript文件),浏览器必须:停止解析,下载脚本,运行。之后才能继续解析,因为JavaScript脚本可以改变页面内容(尤其是HTML)。(所以才说JavaScript分块解析。)对于上面的用例测试,我们发现无论我们怎么优化,框架本身的性能损失都无法抹去。我们唯一能做的就是让框架早一点初始化,少初始化一些内容。可以采用以下优化方法:
所有不用于初始化的js文件都是异步加载的,也就是添加了defer或者asnyc,一些需要cdn的第三方插件需要放在页面底部(因为放在顶部,所以它们的解析会阻止html的解析,从而影响css等文件的下载,这也是雅虎的一个通吃的规则)。解包js文件。以vue-cli为例。一般来说,我们可以通过cli的配置来拆分代码,划分一些第三方。如果有路由,就解包,保证每个路由只加载当前路由对应的js代码,优化文件大小,减少字体包、css文件、js文件的大小(当然这些脚手架默认已经做好了),优化项目结构,每个组件的初始化都有性能损失。在保证可维护性的基础上,尽量减少初始化组件的加载次数。5.网络协议层面的优化,这种优化方式需要服务器配合纯前端,无法实现。在现在的云服务器时代,自己的单位一般都会默认在云服务器中开启这些优化方法,比如开启gzip,使用cdn等等。
事实上,提高FCP的核心是减少初始视图内容和减少初始下载资源大小的想法。
LCP(Largest Contentful Paint)
顾名思义,就是最大内容绘图。什么时候举报LCP,官方是这么说的。
为了应对这种潜在的变化,浏览器将在绘制第一帧后立即分发大内容全绘制类型的PerformanceEntry,用于标识最大内容绘制。但是,在呈现后续帧之后,当最大内容元素发生更改时,浏览器将分发另一个PerformanceEntry。
例如,在具有文本和标题图像的网页上,浏览器最初可能只呈现文本部分,并在此期间分发大内容丰富绘画条目,其元素属性通常指P或h2。然后,一旦加载了第一个图像,浏览器将分发第二个大内容丰富绘画条目,其元素属性将引用img。
应该注意的是,一个元素只有在被呈现并且对用户可见之后才能被视为最大的内容元素。尚未加载的图像不会被视为“渲染完成”。字体阻止期间使用网页字体的文本节点也是如此。在这种情况下,较小的元素可能被报告为最大的内容元素,但一旦较大的元素完成呈现,它将通过另一个PerformanceEntry对象进行报告。
其实用白话解释就是,通常情况下,LCP会在图片、视频、大量文字绘制完成后上报。
了解了这些,优化方法就清楚了。只是尽可能地减少这些资源的大小。经过测试,在缩小第一屏渲染图片和视频内容的尺寸后,整体评分明显提高。以下是一些优化方法:
本地图片可以使用在线压缩工具进行压缩,推荐图片附在tinypng.com界面上。一般每个单元都有对应的oss或cdn参数传递配置,通过地址栏参数传递方式控制画质。图像很难加载。
SpeedIndex(速度指数)
速度指数利用可视化页面加载的可视化进度来计算内容渲染速度的总得分。要做到这一点,您需要能够计算在页面加载期间的每个时间点有多少部分“完成”。在WebPagetest中,通过捕获浏览器中加载的页面的视频并检查每个视频帧来完成(在启用视频捕获的测试中,每秒10帧)。这个算法在下面描述,但是现在假设我们可以给每个视频帧分配一个完整的百分比(显示在每个帧下面的数字)。
以上是官方对计算方法的解释。其实所谓速度指数就是衡量页面内容填充的速度。
一幅画胜过千言万语
经过测试,和LCP一样,图片和视频内容对SpeedIndex影响很大,所有优化方向和之前一样。一般来说,只要增加LCP和FCP的时间,SpeedIndex的时间就会显著增加。
不过需要注意的是,界面的速度也会影响SpeedIndex时间。因为AJAX现在很流行,所以我们的大部分数据都是通过使用接口提取的。如果界面速度太慢,会影响你页面的初始渲染,导致性能问题。所以在做性能优化的同时,寻求后端合作伙伴的协助也是一种性能优化的解决方案。
排查性能瓶颈
上面的分析,根据三个指标,提供了一些常规的优化方法,所以在这些优化方法中,有些你可以立即检查和优化,例如:
优化图片,优化字体大小,配合服务器利用浏览器缓存机制。启用cdn,启用gzip等。减少网络协议过程中的消耗,减少http请求,减少dns查询,避免重定向和优化关键渲染路径,异步加载js等。但是有些优化方法我们也不好排查,因为是在包里打出来的,这个js文件包含了很多逻辑。这里,我有两种方法可以帮助解决出现性能瓶颈的地方:
分析包内容
一般情况下,我们无法判断的优化点都是打包好的,我们无法分析。那些东西不是我们第一屏需要的,所以无法进行新的优化。为了解决目前的问题,各大bundle厂商也有自己的分析包方案。
以vue-cli为例
“报告”:“vue-CLI-服务构建-报告”
我们只需要在scaffold中提供上述命令,就可以在打包时生成整包的分析文件。
如上图所示,打包后,我们可以分析打包后的js文件包含哪些组件,这样就可以知道那些文件不需要同步加载,或者取cdn,通过配置隔离,从而找出性能问题。
利用chorme devtool 的代码覆盖率
如下图所示,
通过使用devtool的代码覆盖检查,可以知道js或者css文件的代码没有被使用过。结合对包内容的分析,可以大致猜出性能的瓶颈在哪里,并做出相应的特殊处理。
针对vue 的特殊优化
以上内容都是一般的优化方法,随处可见,但我已经表达了做这些常规优化的深层原因。在你能更清楚的了解这些原因后,你就能在性能瓶颈处游刃有余,而不是为了面试死记硬背,用起来就无效了。
然后我们公司是vue,要拿到vue的手段。
图片懒加载
所谓图片的懒加载,就是页面只渲染当前可见区域的图片,从而减少其他图片的渲染数量,大大增加SpeedIndex和LCP的时间,从而提高评分。
提到vue中的镜像懒加载插件,先推vue-lazyload。
使用方式简单,功能丰富。
虚拟滚动
在一个列表很长的页面里,你有没有发现自己在往下滑,卡住了?这时候,虚拟滚动就派上用场了。他的基本原理是只渲染可见区域的几条数据,但是模拟的是正常滑动的效果,因为每次你只渲染戏剧区域的数据,滑动的时候他的性能会迅速提升。
vue中有两个很好用的插件:vue-virtual-scroller和vue-virtual-scroller-list。
目前我公司统一使用vue虚拟滚动列表。当他把它拉下来的时候,他可以在分页的地方添加一些装载提示。
vue 中的函数式组件
在vue中,我们知道组件的初始化是相对有损耗的。你可以试试。使用vue直接呈现文本内容与直接呈现app.vue组件略有不同。
但是有了功能组件,这个问题就可以解决了。
因为函数就是组件,顾名思义就是函数,说白了就是渲染函数,省去了组件初始化的过程和初始化的大量开销。
什么时候用函数式组件呢?
当组件中没有业务逻辑,只显示内容时,功能组件就派上了用场。
利用v-show 、KeepAlive 复用dom
我们知道v-show通过display控制dom的显示和隐藏,他不会删除dom。我们在切换v-show的时候,实际上是降低了diff的对比度,而KeepAlive直接复用dom,连diff的进程都没有了,合理使用它们不会影响初始渲染。这降低了js的执行开销,但是值得注意的是,它优化的不是你初始化的性能,而是运行中的性能。
分批渲染组件
前面我们提到了SpeedIndex的逐步渲染是提高SpeedIndex的关键。有了这个前提,我们就可以批量异步渲染组件。先看内容,再渲染其他内容。
例如:
模板
差异
{{数据1 }}
/div
div v-if=data1
{{数据2 }}
/div
/模板
脚本
从“vue”导入{ ref }
导出默认值{
setup() {
让data1=ref( )
让data2=ref( )
//假设这是从后端获取的数据
常量数据={
数据1:“这是呈现的内容1”,
2:“这是呈现的内容2”
}
data1.value=data.data1
//使用requestAnimationFrame在空闲时渲染当前渲染后的剩余内容。
requestIdleCallback(()={
data2.value=data.data2
})
返回{
数据1,
数据2
}
},
}
/脚本
上面的例子比较简单,可能描述不太恰当。这里我想说明一下,目前的方法适用于很多组件,每次渲染时间过长,导致白屏时间过长。比如一次性拉用户列表,批量渲染就很适合。先展示一些用户信息,最后,直到所有内容都慢慢渲染出来。这对浏览器的SpeedIndex也是非常友好的。
最后
绩效优化一直是个热门话题,无论是面试还是工作都很重要。有了这些优化点,您就可以轻松地编写代码或优化旧项目,并且可以提前考虑一些陷阱并避免它们。
但是大家需要明白的是,不要为了性能优化而优化性能。要因地制宜,在不损害项目可维护性的前提下,优化性能。最好不要优化一个项目的性能,但是大家都理解不了。有点亏。再次,60分钟万岁,61浪费。差不多够了。把经验留给更重要的事情吧!
这些是将在vue项目中使用的性能优化技术的细节。有关vue项目性能优化技术的更多信息,请关注我们的其他相关文章!
郑重声明:本文由网友发布,不代表盛行IT的观点,版权归原作者所有,仅为传播更多信息之目的,如有侵权请联系,我们将第一时间修改或删除,多谢。