最近没有啥心思写代码
看了一下老黄写的文章 揭秘 Vue.js 九个性能优化技巧
打算亲自做个一个性能测试,一探究竟,具体的 benchmark 方案,我会放在 /pages/perf/**/*
下面
ps: 文章针对的是
vue 2.x
我的nuxt
项目依赖也是vue 2.x
2 个原因:
before 代表优化前,after 代表优化后
我们先在 nuxt 上测试 spa 的行为
perf/functional/before
232.7ms 4fps
perf/functional/after
102.3ms 10fps
原因文章里也说了:没有有递归子组件的过程,因此渲染开销会低很多。
perf/child-component-splitting/before
149.1ms 7fps
perf/child-component-splitting/after
127.7ms 8fps
其实这个个人感觉用计算属性更好
before
285.8ms 3fps
after
135.9ms 7fps
可见这个帮助提升来说也是很大的,不过 就我个人观点而言,一般在里面多次引用一个this.xxx
时候,就应该缓存了,
一般不会写出 demo 那样的代码吧
同样的道理,看上去是优化,实际上是针对不同的场景
有些场景下,你需要组件被重新加载,比如一些 CRUD 或者部分会带有上一次状态的组件
那种组件可能没有暴露 reset status
的方法,那么这时候 v-if
可能是用来减少 bug,或者偷懒的一种方式
这个不解释了,不知道去就看教程
延时分批渲染组件
// defer.js - vue mixin
export default function (count = 10) {
return {
data () {
return {
displayPriority: 0
}
},
mounted () {
this.runDisplayPriority()
},
methods: {
runDisplayPriority () {
const step = () => {
requestAnimationFrame(() => {
this.displayPriority++
if (this.displayPriority < count) {
step()
}
})
}
step()
},
defer (priority) {
return this.displayPriority >= priority
}
}
}
}
// usage
// v-if="defer(n)"
这个得分情况看,算一种体验的优化吧
这个是用来处理 一次性提交的数据过多,内部 JS 执行时间过长,阻塞了 UI 线程,导致页面卡死的问题的
我在想试试,使用 worker 来处理会不会更好?
这个本质上就是通过 Object.defineProperty
把修饰符 configurable: false
,来避免这条属性变成响应式的
这种减少开销当然会变快了,但是每个都要精确控制各个的 key
是不是可枚举,可配置的,感觉上太麻烦了
这种初期开发阶段是不会在意的!
看到这个笑死了,硬广了一波,better-scroll
让我想起了 el-scrollbar
这个内置组件 ,也是一种实现方式
[1] vue-9-perf-secrets slides
[2] vue-9-perf-secrets 分享演讲视频
[3] vue-9-perf-secrets 项目源码
[4] vue-9-perf-secrets 在线演示地址
[5] vue-9-perf-secrets 讨论 issue:
[6] vue-virtual-scroller 项目源码