老实说,当我刚开始调查性能下降原因的时候,还觉得我肯定要优化很多维修资源才能解决问题。最后这个结果说明,在使用许多框架抽象时我们都必须非常小心——特别是在 Vue 中更是如此,只有在必要时才使用某条指令,而且用法一定不能出错,因为它们绝对有自己的代价。
这还让我开始思考自己做过的其他工作,其中应用程序可能会因为框架而出现不必要的性能问题。大多数现代的前端框架都有很多抽象,使我们能更轻松地为 Web 制作应用程序。但我们应该牢记一点,那就是使用这些东西可能会引发潜在的性能问题。
我经常使用 Vue.js,所以决定探索一些我以前用过的指令,以前我用这些指令的时候完全没考虑过它们可能对应用程序带来的性能影响。其中有三条非常流行的指令进入了我的视线。
v-if 和 v-show
这两条指令都是用来有条件地渲染元素的,但是它们背后的工作机制却大不相同,因此用法也大相径庭。v-if 一开始不会渲染组件,而只在条件为真时才渲染组件。这意味着当你多次切换组件的可见性时,就会不断重新渲染。如果你要多次更改组件的可见性,那就不要使用这个功能。这会影响你的性能。
v-show 是一个很好的替代品。不管你是否启用 CSS 都会渲染你的组件,但是只会根据条件是 true 还是 false 来决定组件是否可见。这种方法确实有其缺点,因为它不会将非必要组件的渲染推迟到你需要它们在屏幕上实际出现的时候。如果你的初始渲染没那么复杂,那么它就很合适。
v-for
这条指令通常用来从数组中渲染列表。它有一个特殊的语法,形式为 item in list,其中 list 是源数据数组,而 item 是要迭代的数组元素的别名。默认情况下,Vue 在源数据数组上添加 watchers,每当发生更改时它就会触发重新渲染。这种持续的重新渲染可能会对应用程序性能产生不利影响。如果你只想可视化对象,那么 Object.freeze() 是一个很好的解决方案,可以大大提高性能。但是请务必记住,你将无法更新组件或编辑对象数据。
在这个研究过程中我还意识到,Lighthouse 可能检查的是以更直接的方式影响用户体验的应用性能指标,所以接下来我的疑问就是如何跟踪服务器上的应用程序性能。
我们是不是太依赖直觉,是不是在假设开发人员知道自己在做什么,假设他们遵循的是最佳实践?不管怎样,这次经历让我对单页应用程序的性能产生了不同的看法。大家可以在 GitHub 上查看上述项目的存储库,也欢迎大家在 Twitter 上和我打招呼。
相关文章
- 10-16终端中经常使用的shell 命令
- 10-16我如何使用discord.py列出不和谐服务器中的所有成员?
- 10-16rhel – 如何以这样的方式配置我的环境:使用适当的(不同于系统的)版本的库
- 10-16我可以使用seaborn在x轴上绘制带日期时间的线性回归吗?
- 10-16c# – 一个大的System.IO.MemoryStream会导致我的应用程序的内存使用量急剧增加吗?
- 10-16c – 为什么dynamic_cast是邪恶的?在这种情况下我应该使用dynamic_cast吗?
- 10-16我如何加快配置文件NumPy代码的使用-矢量化,Numba?
- 10-16使用Python的datetime模块,我可以获得UTC-11当前所在的年份吗?
- 10-16Vue.js的使用(一)
- 10-16android – 当我设置最小高度时,我使用的是哪些单位?