9.1 性能优化：定位与手段

9.1 性能优化：定位与手段

本节摘要：性能优化先分类再动手——加载慢、渲染慢、列表慢三类瓶颈的定位路径与对应手段各不相同。本节给出测量工具的用法、六七个核心优化手段及其作用的管线环节，并强调任何优化都要有度量回归，防止"感觉变快了"的自欺。

学习目标

阅读完本节，你应当能够：

1. 用性能面板与 Vue 开发者工具区分三类瓶颈；
2. 说清每个优化手段作用于管线的哪个环节；
3. 实现基础虚拟列表并知道其前提条件；
4. 给团队的性能工作建立度量基线。

一、先定位，再动手

三类瓶颈的症状与确认方法：

加载慢——白屏久、首帧迟。看网络面板的瀑布图：主包体积、请求数、慢接口一眼可见。特征指标是首屏内容渲染时间（FCP）与最大内容绘制（LCP）。

交互卡顿——点一下反应半秒、输入顿挫。录一段性能面板，看长任务：脚本执行超过 50ms 的黄块。配合 Vue 开发者工具的组件面板，能看到哪个组件在反复渲染、每次渲染多久。

列表掉帧——滚动长列表时帧率骤降。性能面板里脚本与渲染时间双高，且与滚动事件同步出现。

三类瓶颈与对应手段地图

二、加载类手段的要点

路由懒加载与异步组件在前面章节已就位（第 5、7 章），这里补两条容易漏的：

按需引入组件库。全量引入一个组件库可能多出几百 KB；配置按需引入插件后，只有用到的组件进产物。收益直接写在打包报告里。

关键资源预取。对用户大概率会点到的下一个页面，用构建工具的魔法注释标记预取，浏览器空闲时提前下载分包，用户点击时包已在缓存——白屏变成即时切换。

三、渲染类手段：减少做了多少白工

计算属性缓存——第 2 章的老朋友，把重复计算压到依赖变化时一次。检查清单：模板里的方法调用、computed 里嵌套大循环，都是嫌疑对象。

组件拆分出更新边界——一个巨型组件里改一个小状态，整棵树重新渲染；拆出小组件后，props 未变的子树被跳过（第 4 章的边界复用）。这是"组件拆分既是架构也是性能"的直接兑现。

v-once 与 v-memo——前者把块标记为只渲染一次（此后任何更新都跳过它），适合纯静态的法律文案、说明区块；Vue 3 的 v-memo 是记忆化列表项：

<div v-for="item in items" :key="item.id" v-memo="[item.id, item.selected]">
  <!-- 只有 id 或 selected 变了才重渲染这一项 -->
</div>
​

高频事件节流——搜索输入、滚动监听里的重逻辑，防抖节流后进入管线的更新次数大幅下降。注意这是在管线入口减负，与后面环节的手段互补。

keep-alive——标签页、多步表单的切回场景零重渲染（第 5 章），配 include 与 max 控内存。

四、列表类手段：虚拟滚动

一万行数据全渲染，DOM 节点直接把浏览器压垮。虚拟滚动只渲染可视区加缓冲区的几十行，用顶部与底部的占位撑出总高度：

const { scrollTop, itemHeight, containerHeight } = state;
const startIndex = Math.floor(scrollTop / itemHeight);
const endIndex = Math.ceil((scrollTop + containerHeight) / itemHeight);
const visibleItems = items.slice(startIndex, endIndex);
const totalHeight = items.length * itemHeight;
const offsetY = startIndex * itemHeight;
​

<div class="viewport" @scroll="on_scroll" :style="{ height: containerHeight + 'px' }">
  <div :style="{ height: totalHeight + 'px', position: 'relative' }">
    <div :style="{ transform: 'translateY(' + offsetY + 'px)' }">
      <row v-for="item in visibleItems" :key="item.id" :item="item" />
    </div>
  </div>
</div>
​

可行前提：行高固定或可预测。不定高虚拟列表要额外做测量与修正，复杂度上一个量级，一般直接用成熟组件（各组件库的虚拟表格、社区虚拟滚动组件）。数据量上万、行结构简单时收益最大；几百行的列表上虚拟滚动是自找麻烦。

五、度量回归：让优化可信

每个优化动作的流程应该固定：改动前记录基线指标（打包体积、FCP/LCP、关键交互耗时），改动后同条件复测，留存对比。条件允许的话，把关键页面的性能指标接进监控（浏览器性能接口上报），上线后异常劣化能报警而不是等用户投诉。

这个习惯同时防住两类事故：负优化（改完更慢却没人发现）与性能回归（这次快了，三个月后某个需求把它改回去了）。团队里性能故事讲得再好，不如一张前后对比的截图有说服力。

本节要点回顾

• 三分类定位：加载看网络瀑布、卡顿看长任务与渲染次数、掉帧看滚动同步的双高；
• 加载手段：分包、异步、预取、按需引库，作用于下载解析环节；
• 渲染手段：计算属性缓存、拆分边界、v-once/v-memo、节流、keep-alive，作用于渲染与 diff 环节；
• 虚拟滚动：固定行高是前提，只渲染可视区，上万行才值得上；
• 度量回归：基线、复测、上报监控，无数据的优化不可信。

浏览器内的手段用尽，首屏还是慢？下一章把首帧搬到服务器上渲染。