★ FEATURED ARTICLE 前阵子接手一个Vue项目首屏白屏时间4.3秒Performance面板一录脚本执行占1.8秒打包产物1.2MB。这个状态别说用户受不了我自己调试的时候都想摔键盘。做vue项目性能优化就是这样没有一劳永逸的银弹能做的就是一层一层把开销扒下来。这篇文章把我这些年攒下的优化经验做一次汇总梳理覆盖构建、渲染、数据、网络四个层面也包含一套从定位到验证的排查思路适合正在做Vue2/Vue3项目但总觉得哪里卡的同学参考也适合准备面试时把性能优化这个专题真正讲透的人。1. 先搞清楚瓶颈在哪性能优化的排查思路1.1 Vue性能问题的高发场景很多同学一上来就埋头改代码结果改了半个月没效果原因很简单——没有先定位问题。根据我接触过的项目Vue性能问题通常集中在这么几个场景首屏白屏时间过长、大数据量列表渲染卡顿、频繁切换路由时组件重建开销大、复杂表单输入时掉帧、以及打包体积过大导致加载缓慢。其中首屏问题和列表渲染问题占了七成以上。举几个实际例子。某个后台管理项目路由表有80多个页面全部注册进来之后webpack把所有页面打包成一个巨大的chunk用户首次点开就要下载超过2MB的JS。另一个项目是在一个表格里渲染5000行数据行内还有多个联动下拉框每次输入都触发全量重渲染卡到弹窗都点不出来。这类问题有共同特征数据量上去了组件结构复杂了渲染开销按指数级上升而不是线性。1.2 用Performance面板锁定瓶颈拿到一个卡顿的页面我的第一动作永远是打开Chrome DevTools的Performance面板点录制操作页面停掉然后看三段信息脚本占比Scripting、渲染占比Rendering、以及是否存在长任务Long Task。脚本占比高说明问题出在JavaScript执行本身大概率是computed重复计算、数据响应式转换开销、或者methods里做了太重的事情。渲染占比高说明DOM更新频率太快或者节点太多要往v-for列表、样式重绘方向排查。长任务持续超过50ms主线程就被占住了用户的点击事件排不上队体验就会像PPT一样顿挫。我排查过一次典型的卡顿列表滚动时CPU占用飙到90%Performance录制结果里脚本和渲染各占一半顺着调用栈发现是某个行内组件里对Math.random()做了实时响应式绑定每次滚动都触发上百个子组件更新。定位到具体组件之后一行代码拆出去就解决了一大半问题。这就是先定位再动手的价值。1.3 性能指标的量化标准与优化目标性能优化不能靠“感觉不卡了”来验收必须落到指标上。业界常用的几个前端性能指标FCP首次内容绘制应在1.8秒以内LCP最大内容绘制应在2.5秒以内TTI可交互时间应在3.5秒以内TBT总阻塞时间应低于200msCLS布局偏移应低于0.1。这些是Google Core Web Vitals的建议值拿来当优化目标很合适。针对Vue项目我更关心几个子树指标路由组件首屏JS体积gzip后建议不超过200KB、页面交互响应延迟点击到反馈不超过100ms、列表渲染帧率滚动时稳定在50fps以上。优化之前把这些指标用Lighthouse和Performance测一遍记录下来优化之后再做一轮对比效果一目了然。如果没有量化做了十项优化也说不清哪项真正起作用了。2. 构建层面的优化从打包产物开刀2.1 按路由拆分代码动态import的正确打开方式构建层最立竿见影的优化就是代码分割把项目从“一个bundle走天下”改成“按路由按需加载”。Vue Router结合Webpack的动态import是我认为性价比最高的优化手段不用改业务代码只需要把路由配置里的组件引入方式换一下。// 优化前所有页面打包进同一个chunk import Home from /views/Home.vue import UserList from /views/UserList.vue // 优化后按路由拆分成独立chunk访问时再加载 const Home () import(/* webpackChunkName: home */ /views/Home.vue) const UserList () import(/* webpackChunkName: user-list */ /views/UserList.vue)webpackChunkName这个注释不是装饰它决定了生成的chunk文件名而且多个路由可以指向同一个chunkName实现逻辑合并。比如UserList和UserDetail两个页面都依赖一个公共的用户信息组件可以让它们共享同一个chunkName加载一次缓存后另一个页面直接用缓存减少重复请求。要注意的是懒加载粒度不能划太细。如果一个页面三四个弹窗组件都单独懒加载弹窗首次打开反而多了一次网络请求用户会明显感觉到“等一下”的延迟。我的实践经验是一级路由拆一份复杂页面内部的大型组件比如编辑器、大图表单独拆一份轻量级弹窗不要拆。2.2 第三方依赖按需引入与体积换血第三方库是打包体积的大头很多项目一检查moment.js一个库就占了200多KBgzip前实际用到的只有日期格式化那一个功能。Vue项目里常见的做法分两种支持按需引入的库就走按需不支持的就找替代品换血。以Element Plus为例完整引入和按需引入的体积差别能到3倍以上。Vite项目用unplugin-vue-components插件配合unplugin-auto-import组件和API都能自动按需引入配置一次后续基本无感知。Webpack项目则用babel-plugin-import或手动引入组件库的具体组件文件。// vite.config.js import Components from unplugin-vue-components/vite import { ElementPlusResolver } from unplugin-vue-components/resolvers export default { plugins: [ Components({ resolvers: [ElementPlusResolver({ importStyle: sass })], }), ], }按需引入之外我一直主张对重量级依赖做“体积换血”。moment.js换dayjs是我每到新项目必做的一道工序dayjs的API和moment高度兼容大部分代码只需要改一行import体积直接缩小90%以上。lodash如果用不到全部方法用单方法引入import debounce from lodash/debounce配合Tree Shaking或者干脆手写十几行替代方案性能更好。2.3 生产环境关闭source-map与启用压缩source-map在开发时是救命稻草打到生产环境就纯粹是拖后腿的。很多项目打包时没注意默认把source-map也带上了一个业务chunk的.map文件甚至比源码还大部署之后用户每次加载都要额外下载这些文件。构建配置里强制关闭或者只保留一个nosources-source-map用于线上报错定位既能减小体积又保住了排查能力。压缩方面Webpack项目可以引入TerserWebpackPlugin做JS压缩配合esbuild-loader先把TypeScript和部分JavaScript编译转译一遍速度比babel-loader快好几个量级实测下来大型项目冷启动能快一倍以上。Vite/Esbuild项目默认就走原生压缩不需要额外折腾。光压缩还不够别忘了开成gzip压缩。这里有个容易踩的坑如果你在Nginx层开了gzip应用代码里就不需要再引入compression-webpack-plugin两边同时压缩浪费构建时间反过来如果部署环境不归你管比如走了静态CDN就要在构建时用插件提前把.gz后缀的文件打出来。我建议都试一遍哪条链路通了用哪条确认一个维度就够。2.4 CDN加速与externals配置大依赖外置对于React和Vue这类框架以及体积特别大且几乎不会更新的库CDN外置比打包进项目更划算。思路是在Webpack/Vite里把vue、element-plus这类依赖标记为外部依赖打包时直接跳过它们运行时从CDN加载。// vite.config.js export default { build: { rollupOptions: { external: [vue, element-plus], }, }, }同时在index.html里通过script标签引入CDN上的库vue的全局实例会被挂到window上Webpack的resolve.alias要配一下否则运行时会找不到模块。还要把CDN地址固定到具体版本号不要用latest否则哪天第三方更新了个breaking change线上页面突然就白屏了。这种方案适合网络环境稳定、团队能接受多一层外部依赖的场景不是所有项目都推荐。3. 模板编译与渲染优化减少不必要的渲染开销3.1 v-if和v-show的使用边界v-if和v-show的区别很多人能背出来v-if是条件渲染不符合条件直接不渲染DOMv-show是CSS控制display切换DOM始终存在。但实际项目里大量人选错用错高频切换的弹窗用了v-if导致每次打开关闭都走一遍组件创建和销毁永远只展示一次的引导层用了v-show白白挂载了一堆无用DOM节点。我的使用准则是切换频率高于每秒钟几次的场景用v-show比如tab切换、气泡提示、多步骤表单的步骤面板低频、初始化后基本不变的场景用v-if比如权限控制的按钮区域、按用户类型展示的功能模块。还有一个折中方案v-if配合keep-alive缓存组件实例既避免重复创建又能在路由切换时保留组件内部状态但要注意内存占用不能无限缓存。3.2 v-for列表的key到底怎么用key是Vue diff算法的核心线索很多性能问题其实就出在一个个不合理的key上面。用数组index做key是新手最常见的做法这在列表顺序固定、只做尾部追加时没有大问题但一旦涉及排序、删除、中间插数据Vue会误判哪些节点需要复用哪些需要重建DOM更新量飙升还可能出现状态错乱。举一个真实案例一个表格分页组件key绑定的是item.id时排序正确、勾选状态稳定改成index之后翻页、排序操作后复选框状态错位用户勾选的是第二行高亮却出现在第五行。根源就是Vue按index复用节点组件实例被张冠李戴了。所以列表key的黄金法则是永不使用index除非列表是静态不可变的。优先绑定唯一id没有id就给数据源补一个生成逻辑id的生成成本远低于错乱排查成本。3.3 用好computed缓存避免重复计算computed和methods对于计算结果来说经常是等价的但性能上差距很大。computed是基于响应式依赖缓存的只有依赖项变化才会重新求值methods每次渲染函数执行都会重新跑一遍。一个表格筛选功能如果模板里直接调methods过滤一个1000条的数组页面任何数据的变化都会触发重新filter哪怕这次diff跟筛选结果毫无关系。我见过一个后台项目列表页里加了三个methods实时过滤页面还有轮询刷新数据每次轮询都导致三个过滤器全部重跑CPU占用常年30%以上。改成computed之后轮询刷新了不相关的数据computed检测到依赖没有变化直接返回缓存值CPU占用掉到5%以内。所以经验是涉及数据计算与派生的逻辑能用computed就不要用methods涉及事件处理和业务侧写的才用methods。3.4 善用v-memo与函数式组件的场景Vue3.3之后多了一个v-memo指令专门做模板片段的缓存控制。它接收一个数组当数组里的值不变时指令内的内容不会重新渲染。这个指令在处理大列表配合自定义渲染参数时特别有用比如列表项中有一小段动态展示用户等级的DOM结构给这段内容绑上v-memo[user.level]用户等级不变就完全不更新。函数式组件在Vue2时代能有效减少性能开销因为它没有实例、没有响应式数据创建和更新都更快。到了Vue3时代组件渲染机制优化了很多但函数式组件仍然适合高性能列表场景。只是函数式组件结构上和普通组件有差异可维护性稍微差点我的建议是优先保证代码可读性只有在一个列表里反复渲染几百上千次且这个组件逻辑极简的时候才值得动函数式这个手术刀。4. 数据响应式层面优化理解Vue的依赖追踪机制4.1 缩小响应式数据的范围Vue的响应式系统通过Object.definePropertyVue2或ProxyVue3拦截数据读写数据规模越大初始化转换和依赖收集的耗时就越长。很多人会忽略这个初始化的开销在一个大而全的对象上挂几十个字段实际用到的就两三个这就是极大的性能浪费。实践中有两个调整方向。第一个是初始化数据时就明确字段不要等组件运行到一半才突然新增一个不存在的属性。Vue2里通过this.$set新增响应式属性本身就是一次额外的响应式转换碰到复杂对象还会拖慢页面Vue3的Proxy虽然不用$set了但新增响应式属性的开销依然大于初始化时定义好。第二个是只对必要数据做响应式处理纯展示的配置信息、从接口获取后不会再变更的静态数据完全可以逃出响应式系统。4.2 大数据列表用虚拟滚动几千行数据一次性渲染到DOM上浏览器扛不住是必然的。虚拟滚动的核心思路非常朴素只渲染可视区域里的那几十个节点滚动时用transform平移和动态替换节点让浏览器以为你只创建了很少的DOM。实现方式有两种。一是用现成库Vue2常用vue-virtual-scrollerVue3可以用tanstack/vue-virtual配置相对简单传列表数据和每项高度就能跑。二是自己实现一个基础版核心代码就这三步// 伪代码虚拟滚动核心逻辑 const startIndex Math.max(0, Math.floor(scrollTop / rowHeight) - buffer) const endIndex Math.min(list.length, Math.ceil((scrollTop viewportHeight) / rowHeight) buffer) const visibleList list.slice(startIndex, endIndex) // 外层容器设置 paddingTop: startIndex * rowHeight, paddingBottom: (list.length - endIndex) * rowHeight注意动态行高会带来比较棘手的计算问题。如果每行高度不固定需要先测量并缓存每行高度滚动时用二分查找定位起始索引复杂度会上去不少。我的建议是行高固定的场景直接上虚拟滚动不同卡片高度差异大的场景先试着改设计让高度归拢实在改不了再考虑复杂方案。4.3 合理使用Object.freeze冻结纯展示数据这是个小众但很实用的技巧。从接口拿到的字典数据、城市列表、静态枚举值永远不会在代码里被修改但Vue不这么认为它会把这些数据里的每个字段都做响应式转换白花钱。这类数据可以用Object.freeze冻结之后赋值进Vue的dataVue检测到对象是冻结的会跳过响应式转换。// 优化前大型字典数据被转换为响应式对象 this.cityList await fetchCityList() // 优化后冻结后Vue不再做响应式代理 this.cityList Object.freeze(await fetchCityList())在某些数据量很大的场景下这个优化对初始化耗时的改善很直观。我在一个省市区联动组件里把地区数据冻结后页面加载时间实测少了大约400ms。代价是后续如果真要修改这个对象会不生效但“不该变的”数据让它不可变本来就是更安全的设计。4.4 watch深度监听和computed的性能边界watch深度监听一个大对象时只要内部任何一个字段变化回调就会触发。如果回调里带着复杂计算或发请求数据一波动就能把应用拖卡。深层监听的本质是递归遍历层级越深遍历越慢而且每次变更都全量对比开销极大。我的处理习惯是watch尽量指定具体的监听字段不要图省事整个对象一起监听。确实需要监听子项变化时可以在子组件里watch单独字段通过事件向上通信而不是父组件直接deep监听整个大列表。另一方面涉及筛选、排序、聚合这些派生数据的逻辑用computed比watch加手改数据要更贴合Vue的响应式设计代码更简洁性能也更可控。5. 网络资源与运行策略优化5.1 路由懒加载与keep-alive缓存的取舍单独抽出路由懒加载再做一层扩展除了按路由拆包之外还要思考“页面切换时要保留哪些组件状态”。keep-alive的机制是缓存组件实例缓存了就不重新走mounted和created再次进入时快速呈现这对用户体感提升很大。但keep-alive不是免费的。缓存意味着组件实例和DOM节点一直留在内存里缓存页面越多内存占用越大低端手机上容易被系统杀掉进程。我的策略是使用include或max限制缓存数量和范围只缓存用户高频往返的流程型页面列表页进详情页返回的场景对于一次性流程和展示页不缓存。keep-alive :max10 :include[ListPage, DetailPage] router-view / /keep-alive5.2 图片懒加载与字体子集化图片资源往往是首屏体积的大头。一个电商类项目首屏100张图片全部用img src直出每张算200KB光图片就要下载20MB。图片懒加载的本质是先给一张1x1像素的占位图真正划入视口时才加载真实地址。实现上可以用现成插件vue-lazyload也可以用IntersectionObserver自己写一个自定义指令几十行代码搞定。字体是另一个容易被忽略的体积炸弹。中文字体全量动辄几MB如果页面只用到了几个数字和标点完全没必要加载全部字形。用Fontmin、subset工具或者font-spider对字体文件做子集化只保留用到的字符合理使用font-display: swap避免文字不可见的FOIT问题大部分场景直接用系统字体栈不给页面加额外请求。5.3 骨架屏与首屏白屏优化首屏白屏的根因是路由组件还没有渲染出来用户面对一屏空白体感极其糟糕。骨架屏是一种“占位式加载”在数据和组件就绪前渲染出和真实页面结构一致的灰色色块让用户觉得页面正在加载而不是崩了。实现方式分几条路最轻量的是在index.html里直接写一个静态骨架的HTML/CSS任何框架都不用依赖路由加载完成后骨架自动被替换掉进阶做法是用vue-skeleton-webpack-plugin配合构建流程针对不同路由生成对应的骨架DOM片段最重的方案是做SSR或者预渲染不再多介绍普通业务项目用前两种就够。5.4 长任务的拆分与调度有时性能卡顿不是数据变多了而是单次JS执行量过大。比如一次性往表格里插入1万行数据或者处理一个大接口返回的复杂JSON一次执行时间可能超过500ms期间页面完全冻结。这种场景要分片处理。时间片拆分的思路参考requestIdleCallback把大任务切成小段每执行一小段就让出主线程给用户交互处理完一段再回来继续。React把这种思想做成了Schedule模块Vue生态里没有内建模块但可以自己封装。这里给一个处理超大数组的分片插入示例function processInChunks(items, processFn, chunkSize 100) { let index 0 function nextChunk() { const end Math.min(index chunkSize, items.length) for (; index end; index) { processFn(items[index], index) } if (index items.length) { requestAnimationFrame(nextChunk) } } nextChunk() }用requestAnimationFrame而不是setTimeout的原因动画帧在浏览器渲染周期内执行能自动跟屏幕刷新率对齐视觉卡顿感最小。如果业务场景不强求同步完成比如上报日志、统计分析这类可以延后的操作放到requestIdleCallback里做利用的是浏览器空闲时间完全不干扰主流程。6. 常见性能问题排查表与实战避坑记录症状可能原因排查思路与解决方案首屏白屏时间过长未做路由懒加载、依赖过大、CDN目录错误Performance看加载瀑布优先做代码分割和依赖瘦身打包后布局异常CSS代码分割顺序被更改、字体加载策略导致FOIT检查CSS chunk的顺序延长font-display: swap配置的兜底时间列表滚动掉帧渲染行数过多、行内组件响应式过度虚拟滚动、减少行内子组件数量、检查key视频播放如m3u8卡顿流媒体播放器与页面数据响应式冲突、内存过高播放器实例不要放进data、播放器单独分包加载、清理已销毁播放器低端手机直接卡死大量DOM节点和请求同时触发分片插入、做新能预算、操作节流接口返回后页面长时间无响应大规模数据一次性进入响应式系统Object.freeze冻结静态数据分批set数据组件点击反弹灵敏度低主线程被长任务阻塞Performance定位长任务拆分计算逻辑必要时上web worker路由切换体感慢路由组件过重或缺少缓存拆包keep-alive缓存高频页面限制缓存数量再集中分享几个我踩过的坑。第一个是webpack配置加过头导致构建速度骤降。有一回为了提高压缩率把TerserWebpackPlugin的并行数和cache配置改得很激进开发机内存直接干到95%构建一次要6分钟。后来恢复默认并行配置构建时间稳定在2分钟以内。优化没问题但要留出性能余量尤其团队共用开发机时更要克制。第二个是gzip打开了但没走对层。项目A的Nginx已经配了gzip on构建时又用compression-webpack-plugin打了一遍.gz文件导致构建产物里有一堆没必要的gz部署后部分服务器因为映射关系问题反而走了原始文件体积没降。现在我的习惯是只看一个维度要么纯Nginx实时压缩要么纯构建时生成gz文件不要两个方案重复叠加。第三个坑是大佬口中的v-once别乱用。v-once确实能跳过更新检测但它会让整个节点变成静态节点凡是内部有响应式变量的都失效。我见过把整个头部区域加了v-once结果用户头像变成了永远不可变的遗留问题。如果只是部分数据静态利用好Vue3的编译提升和v-memo就够了不到万不得已不要整块上v-once。第四个是关于微信内嵌浏览器WebView的场景。移动端H5项目性能瓶颈经常不在渲染而在WebView的缓存策略和网络IO。这类页面尽量用构建时gzip产物接口请求做缓存缓存策略能合并的接口尽量批量聚合减少在弱网环境下的请求往返次数。还要注意把移动端视频播放器比如m3u8场景绑定到原生video能力而不是纯JS解码性能差异能差一个量级。最后顺手送一套实操清单优化做到哪一步才算到位我个人习惯按这个顺序来基本能覆盖八成以上的Vue性能问题先用Lighthouse跑一遍基线数据接着做路由懒加载拆分然后按需引入和替换重型依赖再查列表渲染和大数据量问题最后再动用CDN外置和网络缓存这层手段。每一步做完都用Performance对比一遍数据不要盲改。做性能优化的过程还有一个容易被忽略的好处它逼着你把项目的依赖关系、数据流向、组件边界彻底梳理了一遍。很多时候项目卡顿背后牵出的问题是组件职责混乱、数据流绕来绕去优化完性能顺手把代码结构也理清了这个隐性收益比指标提升还值。希望这份汇总能帮你少走几条弯路把性能优化从一个玄学工程变成一套有方法、可复盘的流程。
阅读完成 · 觉得有帮助？
