爱吃超人的怪兽咱们直接进入正题。前端这行当，写了几年JavaScript之后，你迟早会遇到那个让你抓狂的瞬间：页面在本地开发时丝般顺滑，一上线、数据一多、用户一访问，帧率掉成PPT，点击按钮半天没反应，滚动跟拖泥带水似的。这个标题里的"JavaScript性能优化实战"不是让你背几条优化原则，而是要解决实际项目里那些肉眼可见的卡顿、白屏、响应慢问题。本文会从测量手段、网络加载、渲染机制、内存管理、移动端特性和工程化落地这几个维度展开，里面所有的方法、工具和坑，都是我这些年真刀真枪在项目里验证过的，可以直接用到你的代码里。
文章主要适合这几类人：写了一些业务代码、但觉得性能优化无从下手的前端工程师；正在被移动端H5卡顿困扰的开发者；还有做前端基建、需要搭性能监控体系的同学。底层原理我会讲透，实操步骤我会给全，保证你能照着做、能复现、能验证。
1. 先确定"慢"在哪：性能优化的起点不是写代码，而是测量
很多人的优化思路是：我猜这里慢，改一下；我猜那里卡，调一下。结果代码改了一堆，用户体感毫无变化。性能优化第一步不是改代码，而是搞清楚瓶颈到底在哪。这个道理说起来简单，实际执行的时候大部分人还是忍不住直接动手"优化"。你问十个人性能优化从哪开始，八个会说是压缩图片、合并请求、减少DOM操作。但真实情况是，你怎么知道该压缩这些？那是因为你已经被灌输了一堆"优化手段"，但你忽略了一个关键问题：这些手段对应你自己的项目，真的有效吗？
1.1 别拿直觉当依据：为什么性能问题要从测量开始
举个我实际遇到的例子。之前有个后台管理系统，用户反馈切换菜单的时候特别卡。按照当时我的第一直觉，下意识就会去查菜单组件是不是渲染的东西太多了。结果一测Performance面板，发现耗时大头根本不在渲染，而是每次切换菜单时，某个全局mixin会触发一次深拷贝的配置对象，这个对象包含了一张巨大的权限表，每次深拷贝耗时将近200毫秒。真正拖慢性能的是这个，而不是你辛辛苦苦优化的列表渲染。如果不测量，我大概率会去优化组件结构，费半天劲，用户依然卡成狗。
这就是为什么业内常说"测量先行"。不过测量也有测量的问题：Performance面板录制的数据，很容易把本地网络、后台接口波动这些噪音也算进去。我一般在用DevTools测量前，会先做两件小事：一是把网络环境切到Slow 4G或自定义的弱网，保证网络延迟不会掩盖JS执行时间的问题；二是用Chrome的无痕窗口打开页面，排除浏览器插件对性能的干扰。这两个操作能显著提升性能数据的可信度。
1.2 浏览器DevTools的Performance面板实测指南
Performance面板（Chrome DevTools里带火焰图的那个）是定位运行时性能问题的核心工具，但很多人只会录一段，然后看看红色的长条在哪就完了，完全没发挥出它的价值。我录制的步骤一般是这样的：
- 打开DevTools切到Performance面板，点击左上角的圆点开始录制。
- 在页面上执行你关心的交互，比如点击、滚动、切换路由。
- 点Stop，等待分析结果生成。
- 首先看顶部Overview区域的FPS（帧率）曲线。如果出现明显的红线，说明这一步交互掉帧了。
- 然后看Main轨道，找到那段交互对应的长任务（Long Task）。长任务指的是执行时间超过50毫秒的任务，浏览器规范里明确说超过50毫秒的任务会阻塞主线程，导致用户感觉卡顿。
- 点开这个长任务的火焰图，从下往上数，真正耗时的函数会被标成深色，往往就是你该优化的点。
实操里有个很反直觉的地方：火焰图里宽的函数不一定是最该优化的。宽说明它执行时间长，但如果你能看到某个函数在火焰图里反复出现、堆叠成很多层，那么整体时间可能更值得关注。因为它被调用了几千次，虽然单次不慢，但累计时间长，这时可以考虑缓存它的计算结果。
1.3 用Lighthouse给性能打分的实操解读
如果你的项目还处在"跟性能有关的指标一塌糊涂"的阶段，我建议先跑一次Lighthouse，拿到一个全局的基线分，再对比优化后的得分，这样有数据支撑，跟产品和老板也好沟通。但这个分数有很多容易误读的地方，我说几个常见坑。
Lighthouse在移动端模拟环境下跑出来的Performance得分，其实是一个综合了FCP（首次内容绘制）、LCP（最大内容绘制）、TBT（总阻塞时间）、CLS（布局偏移）等指标的加权分。我自己实际跑过的经验是，这个分数对"JS执行时间"的敏感度很高。如果你的首屏加载了一半时间都花在解析、编译、执行JS上，哪怕你的网络是宽带级别的，Lighthouse也能把你拉到非常低的分数。所以当你看到Performance分数低，第一反应不应该是"我换个更强的服务端"，而是打开面板里的Diagnostics，看看是不是JS执行时间太长。
还有一个容易忽略的点：Lighthouse适合做中长期回归对比，不适合做局部优化的微调验证。因为它每次跑分都受网络波动影响，同一页面连续跑两次相差5到10分都很正常。所以我一般在做优化验证时，会连续跑三次，取中间值或中位数来对比，如果项目比较大的话，直接用性能监控系统的数据更稳。
1.4 Long Tasks和INP：影响用户感知的关键指标
几年前大家还在聊TTI（可交互时间），最近一两年，Chrome团队已经把INP（Interaction to Next Paint，交互到下一帧绘制的时间）提到了很高的优先级，并且在2024年3月把INP正式替换了FID（First Input Delay），成为Core Web Vitals里的核心指标之一。为什么会有这个变化？因为FID只统计第一次输入到浏览器响应之间的延迟，衡量的是"页面首次能不能快速响应"。但用户的真实体验是全过程的，比如页面已经加载完了，用户开始正常操作了，这时候你的按钮每点一次都要卡一会儿，那体验照样糟糕。INP衡量的是整个页面生命周期内所有交互的延迟，取最差的那个近似值。
我在项目里做性能监控的时候，指标采集主要就看两个：一是LCP看加载快不快，二是INP看交互跟不跟手。INP的临界值一般不超过200毫秒是良好，200到500毫秒需要改进，超过500毫秒就是差。而这个指标跟JS长任务高度相关：主线程被长任务占住，用户点啥都得等。所以当你看到INP偏高，优先去找那几段占用主线程超过50毫秒的长任务，比什么都有效。
2. 网络加载优化：把资源体积和请求成本打下来
性能和网络请求的关系，是前端优化里最简单也最直白的一块。但要命的是，很多项目在网络层面就已经输在起跑线上了——整个应用的JavaScript打包产物动不动就几MB，首屏全部加载完，在移动端那网络环境下，白屏时间自然就长了。
2.1 代码分割与懒加载的落地做法
代码分割（Code Splitting）是我最推荐优先做的优化手段，因为它往往能带来立竿见影的效果。我们的目标是：首屏只加载首屏需要的代码，其他代码等真正用到的时候再去加载。现在用Webpack或者Vite的项目，做代码分割基本是零成本的事情。Webpack里dynamic import是天然的分割点，你用import('./xxx.js')引入的路由组件，Webpack会自动帮你切分成独立的chunk。Vite在Rollup基础上已经把这个能力内建了，你只需要保证路由级别用的是component: () => import('./views/Home.vue')这种写法，构建出来的产物就会自动按路由懒加载拆分。
我见过很多项目迟迟不拆包，问就是"以后再说"。但实际上路由懒加载的技术已经成熟到了不需要动业务代码的程度，就是把组件的静态引入改成动态引入而已，收益基本都是几倍的差距。之前一个后台管理系统，全量打包后首屏JS接近4MB，直接切路由懒加载之后，首屏体积降到了400多KB，LCP从接近5秒降到2秒左右，不需要任何其他优化。这个量级的提升，几乎是我所有优化手段里性价比最高的。
2.2 压缩、Tree Shaking与Gzip/Brotli的搭配
代码分割解决的是"加载多少"的问题，而压缩方案解决的是"加载大小"的问题。这里要讲清楚几个不同层级的压缩，它们管的事不同：
- JS代码本身压缩（minify）：去掉空格、缩短变量名，这个现在构建工具默认做了。
- Tree Shaking：去掉你导入但没有用到的模块代码，这个依赖ES Module的静态结构，CommonJS的模块没法做Tree Shaking，所以你在引入第三方库时尽量选择支持ES Module的版本。
- Gzip/Brotli压缩：在服务器端对资源做传输压缩，这个压缩率非常可观。Brotli比Gzip的压缩率通常能再高15%到20%，但需要服务器和浏览器都支持。现在的项目基本都是HTTPS环境，主流浏览器对Brotli的支持已经很完整了，可以直接上。
在实践里有个特别容易被忽视的点：很多人把Gzip压缩配在了Node层，却没配静态资源服务器（比如Nginx）。你用webpack构建出来的产物已经很大了，Nginx这边如果不开启gzip或brotli，那传输大小没有任何减少。我的习惯是Nginx里统一开启Brotli和Gzip两个模块，Brotli优先，不支持的浏览器自动降级到Gzip。前端项目在构建时不建议手动做生成gz文件这一步，直接把压缩交给服务器层处理就行，省心而且不会有缓存不一致的风险。
2.3 缓存策略与JSON.stringify的前端性能怪圈
HTTP缓存策略是否设置得当，对二次访问的速度影响极大。最常见的方案是这样的：给带有hash指纹的文件（比如app.8f3kd2.js）设置一个很长的max-age，比如一年，因为这种文件的文件名一旦内容变了就会变，所以可以放心缓存；然后HTML文件设置一个短的max-age，比如0到几分钟，这样你发新版本时，用户访问HTML能拿到最新的，再通过新文件名的引用去加载新的JS和CSS。
这是标准做法，我用了很多年。但真正让我想单独拎出来说的，是JSON.stringify在性能优化里的特殊位置。很多前端开发在"性能优化"的语境下，提到JSON字符串化就想到大数据量传输压缩，容易忽略它在页面运行时可能造成的主线程阻塞。我之前排查过一个在线表格项目，用户输入一大段数据后，页面会明显卡死几秒钟。打开Performance面板一看，问题就出在自动保存逻辑里对整张表格数据做JSON.stringify的操作上——那张表格有几万个单元格，深嵌套的数组对象每敲一个字就得全量序列化一次，总耗时经常超过1秒，直接卡死主线程。
所以这里我建议：第一，高频触发的自动保存逻辑，必须加防抖，至少等用户停止输入500毫秒到1秒再序列化；第二，如果数据结构确实很大，考虑用增量保存的思路，只把修改过的行或单元格发给服务端；第三，如果序列化的对象里有大量重复引用，可以试试用JSON.stringify的replacer参数，把无关紧要的字段过滤掉，减少序列化体积。这些小技巧在中小型项目里非常有实用价值。
2.4 第三方脚本的拖累和优化
第三方脚本是页面性能的隐形杀手。埋点统计、客服系统、广告SDK、监控SDK，这些JS往往加载量大、执行时机不可控，而且它们会共用你的浏览器主线程和网络带宽。我的处理思路有三个层次：
第一层，能不用就不用。市面上很多功能都有替代方案，比如监控统计，优先选择一个SDK更轻的，别让后端同学图省事塞一堆全功能SDK进来。
第二层，必须要用就延迟加载。给script标签加defer或async属性，让它们不阻塞首屏渲染。如果跟首屏无关，甚至可以直接把脚本放到onload事件之后动态创建script标签加载，保证不拖累页面整体加载流程。
第三层，必要时用requestIdleCallback在浏览器空闲时加载。这个方法适合那些"可以晚一点出现但最终要出现"的东西，比如用户行为回放、广告位初始化。
我真实处理过一个案例：项目里有个第三方客服插件，JS就有200多KB，而且是在head里同步加载的，直接把FCP给拖到了3秒以上。后来改成在window.onload之后动态加载，首屏FCP直接降了几百毫秒。客服功能用户可以晚几百毫秒再看到，但页面能不能快速打开，决定了他愿不愿意留下来。
3. 渲染与运行时优化：让操作跟手、帧率稳定
网络加载优化管的是首屏快不快，渲染与运行时优化管的是交互顺不顺。这一块的优化空间，有时候比网络优化还大。毕竟一个页面的首屏再快，如果用户点按钮没反应、滚动掉帧、动画卡顿，体验照样是负分。
3.1 重排与重绘的本质，以及如何批量处理DOM操作
重排（Reflow）和重绘（Repaint）是渲染性能里的核心概念，但很多人对它们各自触发条件的理解是模糊的。先说结论：重排的代价远大于重绘。重排是当你改变元素的几何属性（宽度、高度、位置）或读取某些布局属性时，浏览器需要重新计算整个页面的几何信息；重绘只是元素样式变化但布局没变，浏览器只需重新画一遍。为了让读者理解重排为什么贵，我举个例子：一个文档里有1000个节点，你改了一个节点的宽度，浏览器可能要把这1000个节点都重新布局一遍，这个计算量本身就是可观的，再加上如果页面里有复杂的CSS选择器，那开销不可忽略。
常见的会引起重排的操作包括：修改宽度、高度、padding、margin，改变字体大小，增删DOM节点，改class改变布局属性。读取offsetWidth、clientWidth、getBoundingClientRect这些属性时，为了拿到准确的值，浏览器也会被迫执行一次同步布局，如果你在一个循环里反复读写这类属性，就很容易造成布局抖动（Layout Thrashing），性能断崖式下降。
批量修改DOM的正确姿势是：尽量减少读写交叉。比如你想修改一个列表里100个元素的宽度，不要循环里每次读一个值又set一个值，先把所有新值算好，再一次性地更新DOM；或者用DocumentFragment先把DOM构建好，一次性插入到文档中；再或者用CSS类来切换样式，让浏览器把样式变更合并到一次重排里。现代框架里Vue和React已经在虚拟DOM层帮你做了批量更新，但如果你在项目里直接操作DOM（比如写jQuery或原生JS），这些细节就特别值得注意。
3.2 事件委托与高频事件的节流防抖
高频事件处理得不好，是交互卡顿的常见来源。scroll、resize、mousemove、touchmove这类事件，触发频率远超你的处理函数执行时间，如果你在每个事件回调里都做了大量计算，肯定堵住主线程。处理思路基本是两个方向：节流（throttle）和防抖（debounce）。
节流的意思是，在指定时间间隔内最多执行一次。适合滚动监听、拖拽这类需要持续响应、但不需要每一帧都响应的场景。防抖的意思是，只在事件停止触发后执行一次。适合输入框搜索、窗口resize结束后的布局调整这类需要等用户停下来再处理的场景。这两个概念看着简单，但实际实现的时候有很多边界情况。我建议直接用lodash的throttle和debounce，它们对leading、trailing、取消这些细节处理得很完善，比自己写一版在各种边缘情况下出bug要靠谱得多。
事件委托是另一个非常实用的技巧，它本质上是利用事件冒泡机制，把子元素的事件处理挂在父元素上。这样不只可以减少内存中事件监听器的数量（频繁动态增删列表时尤其有用），还能避免新插入的元素没绑定事件的问题。我们可以在一个管理后台的表格组件里，这个技巧就特别实用：几千行数据只挂一个click监听器，通过event.target判断点到了哪一行的哪个按钮，性能表现非常稳定。
3.3 requestAnimationFrame与动画性能
动画性能优化的核心原则是：凡是能用CSS动画实现的，就不要用JavaScript驱动；凡是能用transform和opacity实现的，就不要直接改width、height、left、top这些引起重排的属性。
为什么？CSS动画大部分由浏览器的合成器（Compositor）单独处理，不占用主线程，效率极高；而JavaScript动画每一帧都要跑在JS主线程里，容易受其他JS任务干扰造成卡顿。使用transform: translate()而不是left属性来移动元素，是因为transform不会触发重排，它只触发合成阶段，GPU可以帮忙加速，性能开销非常小。
如果JS动画无法避免（比如需要跟数据联动），那么驱动循环应该使用requestAnimationFrame而不是setInterval。requestAnimationFrame会跟随屏幕的刷新频率执行，通常是60帧每秒，而且当页面在后台时它会自动暂停，减少不必要的性能消耗。setInterval固定间隔执行，既可能跟屏幕刷新错位导致掉帧，又不会自动暂停，浪费资源。
3.4 Web Worker与长任务拆分的实战应用
如果你遇到一个计算量特别大的功能，比如数据加密、大量数据的排序和过滤、图片处理，这些任务不管你怎么优化算法，单次计算时间依然可能超过几十毫秒，那这时候就必须考虑把任务扔出主线程，用Web Worker在后台线程里处理。
我之前做一个离线的Excel导入功能，文件有大几万行数据，解析加校验计算量很大，如果放在主线程，页面会直接冻结好几秒。用Web Worker处理之后，主线程只负责发数据、收结果，整个过程页面保持流畅，用户还能看到一个转圈提示。Web Worker的用法也不复杂：
javascript复制// 主线程
const worker = new Worker('worker.js');
worker.postMessage({ fileData: largeArray });
worker.onmessage = (e) => {
const result = e.data;
// 处理结果，更新UI
};
// worker.js
self.onmessage = (e) => {
const { fileData } = e.data;
// 在这里做耗时计算
const result = processData(fileData);
// 把结果发回主线程
self.postMessage(result);
};
要注意的是，Worker里没有DOM、window、document这些对象，所以你不能在Worker里操作DOM，只能让它完成纯计算。Web Worker也不是没有成本，每次创建都需要时间和内存，所以它比较适合耗时明显、不会太频繁调用的任务。如果任务本身只耗时几毫秒，丢给Worker反而增加了额外开销，不划算。
4. 内存管理：性能优化里被忽视的隐形杀手
加载性能和渲染性能通常是大家关注的焦点，内存管理却经常被忽略，直到页面运行久了越来越卡、最后直接崩溃。内存问题不像网络性能那样从LCP、FCP这些指标里一眼能看出来，但它对用户体验的影响同样巨大。
4.1 内存泄漏的常见来源与检测方法
JavaScript有垃圾回收机制，听起来好像不用管内存，但垃圾回收只能回收"不再被引用"的对象。如果你的代码里还有个变量引用着一个你已经不需要的对象，那这块内存就永远回收不了，这就是内存泄漏。常见的泄漏来源有这么几类：全局变量意外创建（比如在严格模式没开启的函数里给未声明的变量赋值）、被遗忘的定时器和回调、脱离DOM的引用、闭包中持有大对象的引用、以及事件监听器未及时移除。
检测方法，用Chrome的Memory面板做两次以上堆快照。操作方法是：先在页面加载完时录制一次内存快照，然后执行你想监控的操作（比如打开关闭某个弹窗几次），再录制一次快照，对比两次快照的"Retained Size"，看看哪些对象不断增加却没有被回收。如果多次操作后某个对象类型的内存占用只增不减，那基本可以断定存在泄漏。不用看太细，先看整体的趋势，再定位到具体的构造函数或引用路径。
4.2 定时器、闭包和事件监听器的引用问题
定时器是内存泄漏的大户。你写了一个setInterval去轮询某个接口，然后在某个页面关闭的钩子里忘记了clearInterval，那这个定时器会一直存在，它引用的变量甚至它所在的组件数据就永远无法释放。这在SPA应用里特别严重，因为组件销毁了但定时器还在，内存不断累积。规范做法是，在组件销毁的生命周期里，把创建的定时器统一清理掉。
闭包的内存问题要隐蔽得多。闭包本身是JavaScript的核心特性，但如果你在闭包里引用了外部的一个大对象，而这个闭包又被某个长期存活的变量引用，那么那个大对象就无法被回收。举个例子：一个全站通用的服务模块里有一个函数，它不小心捕获了一个包含大量数据的配置对象，那这个配置对象就会一直留在内存里，即使你后面再也不需要它了。解决思路是：闭包引用外部变量时，尽量只引用必要的小数据；如果你在闭包里需要用到一个大对象，可以在用完后显式把它置为null，切断引用。
关于事件监听器，现代框架（Vue、React）在组件卸载时通常会帮你清理组件内绑定的事件，但如果你是在组件里直接操作window或document——比如添加全局的scroll或keydown监听——框架不会帮你清理，因为框架不知道这个监听器的存在。我建议开发者在绑定全局事件的组件中，记住在销毁回调里调用removeEventListener，并确保传入的是同一个函数引用，而不是一个匿名箭头函数。
4.3 弱引用和高频调用的累积问题
JavaScript里有WeakMap、WeakSet、WeakRef这些弱引用结构，它们在内存管理中很有作用。Map和Set的键是强引用，如果你把一个对象当作Map的键，只要Map存在，这个对象就不可能被回收。而WeakMap的键是弱引用，当没有其他强引用指向这个键时，垃圾回收会直接把它收掉。在缓存、事件处理、对象关联数据这些场景，WeakMap能让你在不额外清空的情况下，避免内存泄漏。
另一个平时不显眼、但一上规模就致命的，是高频调用产生的对象累积。比如在一个性能敏感的循环里，你每次都new一个大对象，循环完了它本该被回收，但如果被某个闭包或数组收集了起来，就再也没机会回收了。我在处理一个可视化大屏项目时遇到过这种情况：一帧一帧重绘数据，每次重绘都会产生一个包含几百个点的大数组，如果不及时清空，内存曲线一路走高。解决办法就是复用对象池，把不再使用的对象回收到池子里，下次需要时直接取用，减少创建和回收的开销。这种对象池的思路在游戏开发里非常常用，在大前端项目里也同样适用。
5. 移动端与多端场景的专项优化
移动端H5的性能问题，比PC端更严峻。移动设备的CPU和内存远不如PC，网络也更不稳定，屏幕还小、交互靠触摸。同样的页面在PC上能跑40帧，到手机上可能就只有十几帧。这一节我们只聊移动端特有的几个坑和对应的处理办法。
5.1 移动端交互响应的特殊性
移动端的点击延迟问题，在老版本的浏览器里非常明显：点击一个按钮，浏览器要等300毫秒才能确定你是点击还是双击缩放。现在大多数新浏览器和设置了viewport的H5页面都已经通过touch-action: manipulation消除了这个延迟，但如果你在页面上遇到点击不够跟手的情况，可能还有几个地方需要注意。
一是touchmove事件里做了太多事。移动端触摸事件触发频率极高，如果你在touchmove里同步做了很多计算，帧率会直线下降。必要时可以用passive: true这个监听选项告诉浏览器："我不会调用preventDefault"，这样浏览器可以做滚动优化，不需要等待你的JS执行完再决定是否手势生效。
二是interaction、动画和滚动要尽量走合成器线程而不是主线程。比如滚动时想给元素加个阴影，用position: sticky加CSS实现，而不是监听scroll事件动态改样式。一旦走了主线程，就会受到主线程拥堵的影响。
5.2 大数据量渲染的列表虚拟化
移动端内存本来就紧张，如果一次渲染几千条数据生成几千个DOM节点，页面基本就卡死了。列表虚拟化（Virtual Scrolling）是解决这类问题的核心方案。它的思路是：只渲染可视区域内的列表项，上下超出视野的部分用空白占位，随着滚动动态更新可见项。这样不管数据有多少，页面里实际存在的DOM始终是几十个。
虚拟列表的实现方案很多，自己写的话要注意这些细节：首先要测量每项的高度，如果是固定高度，计算就很简单；如果是动态高度，需要在渲染后测量并缓存。其次要正确设置滚动容器的总高度，让滚动条长度看起来是全部数据的；第三，滚动更新可见项时要注意避免频繁的DOM操作，尽量改用transform做偏移。市面上有成熟的库，比如react-window、vue-virtual-scroller，直接集成比自己造轮子更稳。自己做一版只适合学习场景，生产环境还是要用社区方案。
5.3 字体、图片与本地存储的取舍
移动端首屏加载，字体和图片体积占比通常非常大。字体文件动辄几百KB，中文的更是超大，如果一进页面就加载full字体文件，白屏时间会很感人。实用做法是用font-display: swap属性，让文字先用系统字体渲染，等字体文件加载完再切换，避免文字不可见导致的FOIT问题；更进一步，可以做字体子集化，只保留页面上用到的字符，体积可以大幅缩减。
图片优化这块，响应式图片是最该上但常常没上的方案。用srcset配合sizes属性，让浏览器根据屏幕宽度选择合适的分辨率图片，大屏设备下载大图、小屏设备下载小图，省掉的流量非常可观。图片格式上也建议启用WebP，同样的质量下体积比JPEG和PNG小不少。现在的主流浏览器对WebP支持已经很完善，构建工具处理也比较成熟，直接在打包阶段转换即可。
本地存储的方式也值得重新审视。移动端浏览器对localStorage的写入是同步的，而且各域名有5MB左右的限制，如果频繁写入大字符串，本身就会阻塞主线程。遇到需要存储较大数据的情况，可以考虑IndexedDB，它是异步API，不会阻塞渲染，容量也大得多，是实时场景下更合适的选择。
6. 性能优化的工程化落地：从一次优化到长期稳定
性能优化往往容易陷入"优化一波，过段时间又回去了"的循环。因为代码是持续进化的，每个开发都可能引入新的性能问题。要让性能保持稳定，光靠一次优化是不够的，得把它工程化、指标化，纳入日常开发和CI流程里。
6.1 性能预算与回归测试
我的建议是给项目设置性能预算（Performance Budget），就像给财务报表设预算一样，明确规定允许的资源大小和执行时间上限。常见的预算指标包括：首屏JS体积不超过多少KB、LCP不超过多少秒、INP不超过多少毫秒、每个页面的最大DOM节点数。把这些预算写进CI，每次构建时自动检查，超了就失败或者报警，开发者在提交代码之前就能发现性能问题。
Lighthouse CI是个很好用的工具，它可以把Lighthouse跑分集成到GitHub Actions或GitLab CI中，每次代码合并前自动跑一次，对比base分支的得分，如果分数下降超过阈值就阻止合并，或者至少给出提醒。我实践下来的体感是，这种自动化的效果比靠口头提醒要好太多。人总会疏忽，但CI不会。
6.2 性能优化的优先级排序
不同的项目，性能优化的性价比是完全不同的，尤其在人力、时间有限的情况下，更要把劲用在刀刃上。这里我按性价比排一下优先级：
- 网络资源体积：代码分割、压缩、图片优化。这是投入产出比最高的，改动成本低，收益立竿见影。
- 渲染路径优化：减少DOM操作、批量更新样式、事件委托、对象池复用。这需要你对页面交互有清晰的理解，但收益也很可观。
- 数据请求优化：防抖、增量更新、缓存数据。它对交互卡顿的改善很直接。
- 内存管理：查泄漏、用弱引用。这是兜底工作，排查成本比较高，但它决定了页面能不能长时间稳定运行。
- 底层架构调整：比如重写组件、上WebAssembly。这种往往是最后的选择，成本高、周期长，要慎重。
我一般会先动手做第一类，然后根据线上性能监控数据决定要不要继续做第二类。如果首屏还很慢，就别急着去优化一个内部列表的渲染，那是捡芝麻丢西瓜。
6.3 实际项目中的经验总结
最后说几句真实项目里踩坑总结出来的经验，不是教科书内容，但都是真实工作里的血泪教训。
一是性能优化从改代码到上线，别只看开发环境的性能。开发环境没有压缩、没有懒加载、网络也是本地的，跟线上完全两个世界。我见过有人在本地跑得飞快，以为优化已经很到位了，结果一上生产，LCP还是高得吓人。一定要在预发布环境或线上环境用模拟弱网的方式做验证。
二是别为了优化而优化。有一些优化手段比如把组件拆成微前端、上WebAssembly，在某些场景下确实能提升性能，但引入的复杂度是惊人的，维护成本也随之上升。如果业务规模没有到那个程度，强行上只会让团队和项目都痛苦。性能优化是服务业务体验的，不是给简历添砖加瓦的。
三是性能数据的采集要长期做。我建议在新项目开始时就埋下性能监控的种子，用PerformanceObserver去监听LCP、INP、CLS这些指标，把数据上报到你们自己的监控平台或云厂商的前端监控服务。有了长期的数据积累，你才能知道哪次改版让性能变好了、哪次改版让性能恶化了。没有数据，优化就永远是在开盲盒。
四是如果你在一个大公司或者成熟团队，一定要把性能优化的经验沉淀成文档和工具。新人入职，与其让他们踩一遍你踩过的坑，不如直接把"性能优化自查清单"发给他们，能省下大量的隐性成本。
实际操作中的一点个人体会
写到这，其实性能优化的大部分知识框架都覆盖了，但有些东西不在框架里，却又特别重要。我自己做了这么多年性能优化，最大的感受是：性能优化是一个永无止境的过程，你永远不可能把一个页面的性能优化到"完美"，因为业务在增长、技术在演进、用户设备在变化，你今天优化的结果明天可能就不适用了。所以比起掌握那几条具体的优化手段，更重要的是建立"测量-分析-优化-验证"的循环意识。以数据说话，用工具定位，再有的放矢地修改代码，这比什么花哨技巧都可靠。
另外想和读者说的一点是，不要被"性能优化"这个词吓到。它听起来像是个高阶话题，但在日常开发中，你只需要在写代码时多留个心眼——少写一点不必要的循环、避免在渲染路径上做重活、记得清理定时器和事件监听器、用懒加载减少首屏负担——这些基本的习惯，累积起来比你在项目后期做一次大型重构有效得多。根据我的个人经验，把"性能意识"变成"肌肉记忆"，比任何一次性的优化专项都更有价值。
如果你看完这篇文章，准备立刻优化手头的项目，那么我建议你从"跑一次Lighthouse"开始，找到那个最低分的指标，顺着我上面提到的思路去排查，大概率不会走弯路。祝你的Web早日飞起来。