1. 性能优化先想清楚你是在优化“感受”还是在优化“数字”先说个我踩过好几次的坑拿到一个JS性能问题直接就开始看代码、找循环、改算法折腾大半天最后发现用户该卡还是卡。为什么因为大多数性能问题根本不在代码本身而在加载路径和渲染时机上。JavaScript性能优化这件事本质上不是“让代码跑得更快”而是“让用户觉得更快”。这俩有本质区别。用户感知到的性能由几个关键节点决定首屏能看到的等待时间、交互后的响应延迟、滚动和动画的流畅度。如果你只盯着V8引擎里某个函数的执行时间那基本属于用错了力。我之前接手过一个移动端H5项目首屏加载要4秒多产品天天催。我一开始也是先去看JS有没有性能瓶颈结果发现压缩后的业务代码才100多KB根本不至于这样。后来一查真正的问题是页面里有8个独立第三方SDK的script标签全部同步加载而且图片资源没做尺寸裁剪一张首图2MB。把这些东西理顺之后首屏直接进1.5秒以内JS代码一行没改。这就是我想说的第一件事性能优化第一步是建立正确的问题定位方式而不是急着写优化代码。你得先搞明白瓶颈在哪一层——网络层、渲染层、还是纯计算层。网络层慢你优化算法没用渲染层卡你优化网络也没用。另外要注意的是性能优化不是一锤子买卖。代码在不断演进依赖在不断升级性能也会随之波动。所以科学的做法是把性能优化做成一个可持续的流程建立基线、持续监控、回归对比。很多团队做了第一轮优化就完事了三个月后性能又烂回去了就是因为缺少监控和兜底机制。所以这篇文章我不会只讲技巧我会把完整的优化思路、工具链、实战套路都过一遍。你跟着这个路径去做至少能把80%的JavaScript性能问题都解决掉剩下的20%才需要靠极致的底层调优去拼。2. 先测量再动手没有数据支撑的优化都是瞎折腾2.1 性能基线怎么建立别靠“感觉卡了”去立项做性能优化最容易犯的错就是靠感觉判断哪里卡。你觉得这个页面卡但卡的是什么是加载慢是滚动掉帧是按钮点击没反应每种卡顿的成因完全不同解决方案也完全不同。一个合格的性能优化项目开工前必须建立量化基线。我最常用的组合是以下几个工具覆盖不同维度工具作用使用场景Lighthouse生成性能评分和关键指标整体评估、定基线Performance面板录制或实时查看调用栈和耗时定位CPU瓶颈和长任务Network面板分析资源加载时间和顺序定位网络层瓶颈Bundle分析器看打包产物的体积构成定位依赖过重和冗余代码Performance API在真实用户环境采集指标线上监控、长期追踪Lighthouse测出来的评分只是一个参考维度我更关注它下面的几个具体指标First Contentful Paint、Largest Contentful Paint、Speed Index、Time to Interactive。这些指标直接对应了用户能感知的加载体验。第一次跑Lighthouse的时候一定要记录所有数据这就是你的基线。业内常用的基线整理方式是这样的固定一个测试设备比如一台中端Android真机固定网络环境比如用DevTools的Slow 4G模拟然后跑三次取中位数。不能用高端PC和Wi-Fi去测那样测出来的数据对真实用户没有参考意义。我之前给一个项目做优化用Mac上的Chrome测出来Lighthouse能打95分结果拿同事的小米手机一测首屏要5秒。设备的性能差距在JS处理上放大得非常明显。Performance面板则是定位运行时问题的核心工具。录制一段操作过程重点看几个地方有没有长任务Long Tasks超过50ms的任务都会在Timeline上标红、脚本执行时间在整个耗时里占比多少、有没有明显的强制同步布局Forced Reflow标记。我之前排查一个表格页卡的滚动问题就是用Performance面板录了三秒钟的滚动发现几乎每一帧都有一个紫色高亮的Layout标记说明是在滚动过程中反复改样式导致的强制重排。这问题用肉眼是不可能看出来的。2.2 必看的Core Web Vitals别再盯着PV和UV做性能了从用户角度来度量性能Google推行的Web Core Vitals是你绕不开的框架。它包含三项指标LCP最大内容绘制、INP交互到下一次绘制的延迟、CLS累积布局偏移。这三项分别对应加载体验、交互体验、视觉稳定性。LCP衡量的是页面最大元素通常是首屏图或者大标题渲染出来的时间。超过2.5秒就算差。优化LCP的核心思路就一条让最大的那个元素尽早开始加载并渲染。通常手段包括预加载关键图片link relpreload、避免用JS动态插入首屏内容、服务端渲染或者预渲染SSR/SSG、去掉阻塞渲染的同步脚本。INP是2024年Google用Interaction to Next Paint替代了原来的First Input Delay用来衡量用户交互后页面响应的快慢。这个指标考察的是从用户点击到页面画出视觉反馈的时间。要优化INP核心就是减少事件处理中的主线程阻塞时间把复杂的计算拆开做或者挪到Web Worker中避免在事件回调里做重型操作。CLS衡量的是页面加载过程中元素突然跳动的程度。这个往往是前端容易忽略的点没有给图片和广告位预留尺寸、字体加载后导致文字位置变化、异步插入的DOM把下面的内容挤下去——这些都是CLS的元凶。修起来其实不复杂给媒体元素加上宽高属性用aspect-ratio预留空间字体用font-display: swap但就是需要你有这个意识。提示如果你们团队有条件可以用web-vitals这个npm包把真实的指标数据上报到自己的监控平台这是我从“靠工具测”升级到“线上持续观测”的关键一步。2.3 用Performance API做线上真实性能监控本地测Lighthouse只能代表理想环境真实用户手里的手机千奇百怪网络环境更是复杂。所以我建议任何有点规模的项目都要接线上性能监控。不用非得买商业产品自己用Performance API就能搭一个轻量的方案。PerformanceObserver可以监听largest-contentful-paint和layout-shift等性能条目。我分享一个简单的采集代码思路// 一个极简的线上性能数据采集示例 const observer new PerformanceObserver((list) { for (const entry of list.getEntries()) { if (entry.entryType largest-contentful-paint) { // 这里把数据发送到你的监控服务器 sendBeacon(/api/perf, JSON.stringify({ type: LCP, value: entry.startTime, url: location.href })); observer.disconnect(); } } }); observer.observe({ type: largest-contentful-paint, buffered: true });navigator.sendBeacon这个方法很适合发送性能日志因为它在页面卸载时也能可靠地把数据发出去不会因为跳转丢数据。采集到的数据存下来之后按设备、网络、页面维度去聚合就能看出哪些页面在哪些场景下性能差再针对性去优化。这里我就不展开讲监控平台的搭建了核心思路就是真实用户数据才是最终裁判。3. 加载阶段提速让页面更早可交互3.1 JS体积控制从依赖和构建产物下刀JavaScript性能优化的第一刀应该砍在不需要执行的代码上。你让浏览器下载并解析的每一KB代码都在消耗用户的流量和CPU。尤其是移动端低端手机的JS解析速度比桌面端慢4到5倍。我处理过一个项目打包后的JS有800KB压缩后也有近250KB。用Bundle分析器一看好家伙moment.js一个库就占了50KB但整个项目只用到了它的format功能。换成dayjs之后直接少了45KB。后来又发现lodash全量引入但实际只用了debounce和get两个函数改成按需引入后又省了30KB。这里要给大家说一个具体可操作的原则任何依赖库能按需引入就按需引入能用轻量替代品就果断替换。引入依赖前问自己两个问题这个库的功能我能不能用原生API实现如果能节省的代码量值不值得我用一个库原生fetch已经很好用了非要为了兼容引入axiosArray.prototype.flat、Object.fromEntries这些ES2019能力都已经普及了没必要为了它们引入工具库。构建层面的配置也很重要。如果你是Webpack 5注意开启moduleConcatenation提升作用域配合terser-webpack-plugin做极致压缩。如果你用的是Vite构建时用的是Rollup天然会做tree shaking。但不管哪个构建工具都需要你自己去检查两件事有没有把整个库的dist文件直接import进来导致tree shaking失效有没有在入口文件里import了一个有很多副作用的模块。还有一点就是按需加载和动态import。把首屏不需要的代码比如弹窗组件、详情页逻辑、图表库拆成独立的chunk用户用到时才加载。这个在Webpack和Vite里都支持语法就是const { default: Chart } await import(./Chart.vue)这种方式。拆完之后要注意检查chunk体积如果一个异步chunk还是很大就要继续拆。实操心得拆代码之后我一般会同时做两件事给chunk起可读性强的名字Webpack的magic comments方便在Network面板里定位在代码分割点上加错误边界逻辑异步加载失败时提示用户刷新而不是白屏。3.2 用对缓存策略HTTP缓存和Service Worker两手都要硬缓存这个环节经常被低估。很多团队觉得上线就完事了结果老用户每次打开页面都要重新下载所有资源。这体验能不慢吗HTTP缓存的核心原则是内容不变的资源让浏览器永远用缓存内容变化的资源让URL跟着内容变。典型的做法给静态资源文件名加上内容哈希app.8f7d2c.js然后设置Cache-Control: max-age31536000, immutable。文件名变了URL就变了用户自然加载新文件文件名不变就直接用缓存连网络请求都不发。但HTTP缓存的局限在于首次访问没有缓存还是要走完整的下载流程。要突破这个局限就得靠Service Worker做App Shell缓存。Service Worker的思路是在你第一次访问页面的时候把框架代码、基础样式、公共图片这些“外壳”资源全部预缓存到本地。第二次访问的时候直接从Service Worker缓存里读取几乎可以做到秒开。我参与的一个项目加了Service Worker预缓存之后老用户从二次进入到页面完全渲染时间从1.8秒降到了0.4秒。用户体验的提升是质变级别的。当然Service Worker的坑也不少更新策略、缓存版本管理、白屏风险。一个稳妥的方案是采用stale-while-revalidate策略页面永远先用缓存的旧版本渲染后台静默拉取新版本拉到了就更新缓存并在下次加载时切换。这样用户永远能看到内容不会因为缓存更新而白屏。还有一个大家问得多的问题图片和视频这类大资源要不要进Service Worker我的建议是大部分不要。图片走HTTP缓存就够了Service Worker缓存图片容易撑爆存储配额。除非是用户最高频使用的页面配图否则别做这个收益有限还增加复杂度。3.3 图片和字体是性能隐形杀手别只盯着JSJS是主线程的计算负担但页面上绝大多数体积来自图片。如果图片没优化好JS优化得再彻底加载体验实际也提升不了多少。图片优化的核心就三件事格式、尺寸、解码方式。格式上能上WebP就上WebP甚至可以考虑AVIF大部分现代浏览器都支持。尺寸上上一套响应式图片方案用srcset让移动端只加载480px宽的图桌面端加载1920px宽的图别让手机用户下载一张2MB的高清大图。解码方式上开启loadinglazy做懒加载优先加载首屏的图。图片懒加载这个属性现在是原生支持的了不用再引库。字体这块是个隐性痛点。中文字体动辄几MB如果直接用font-face包裹一整份中文字体文件那是一场灾难。我现在处理中文字体的套路是只加载页面上实际出现的文字对应的子集字体通过字体子集化工具比如fontmin只保留需要的字形或者直接用unicode-range把字体切分成多个子集浏览器按需加载。如果条件实在有限就把字体优先级调低优先保证系统字体渲染项目字体加载完再替换这就是font-display: swap的作用代价是有FOIT无样式文字闪烁但总比白屏好。注意图片懒加载也不是无脑加的首屏图片千万别加loadinglazy因为浏览器可能不知道哪张图优先导致首屏图被推迟到很晚才加载。这也是加了懒加载反而首屏变慢的常见原因。4. 运行时流畅度从主线程手里抢时间4.1 主线程的长任务拆分从“一次干完”到“分次干完”JS是单线程语言所有DOM操作、事件回调、计算逻辑都挤在主线程上。如果某个任务的执行时间超过50ms浏览器就有可能出现掉帧、卡顿。这就是为什么我们做运行时优化时核心目标就是消灭长任务或者至少把它们拆短。拆分长任务的最简单方案是让出主线程。思路是把一个需要几百毫秒才能执行完的逻辑拆成多个小块每个小块之间用setTimeout或者MessageChannel让浏览器有空闲时间插入渲染。这里我推荐优先用MessageChannel因为setTimeout在浏览器里有一个最小4ms的延迟限制嵌套层数较多时MessageChannel能更快地把任务交还给主线程。// 用MessageChannel做任务分片调度的示例 function scheduleYield() { return new Promise(resolve { const channel new MessageChannel(); channel.port1.onmessage () resolve(); channel.port2.postMessage(null); }); } async function processLargeArray(items) { const CHUNK_SIZE 1000; for (let i 0; i items.length; i CHUNK_SIZE) { // 处理当前分片 const chunk items.slice(i, i CHUNK_SIZE); processChunk(chunk); // 让出主线程让浏览器有机会渲染和响应输入 await scheduleYield(); } }另一个更现代、更优雅的方案是Scheduler API里的await scheduler.yield()。虽然目前它的浏览器兼容性还没有全覆盖但在Chrome 119里已经可以用了而且它是由浏览器原生调度上下文和优先级比手写MessageChannel方案更可靠。如果项目对浏览器内核版本要求高比如必须支持老版本WebView使用MessageChannel方案做降级即可。还有一类任务是“拆了也白拆”的——比如用户在滚动中scroll事件高频触发你有大量逻辑在处理。这时候除了拆任务更关键的是防抖和节流以及把部分逻辑挪出主线程。4.2 防抖和节流高频事件的保命手段前端性能优化的基础功就是防抖和节流。防抖适合处理搜索输入这类“只关心最后一次输入结果”的场景用户连续输入时只有在停止输入多少毫秒后才会执行真正的逻辑。节流适合处理滚动、鼠标移动、窗口缩放这些“在一定时间内最多执行一次”的场景保证逻辑不会因为事件高频触发而崩溃。但很多人的误解在于用了防抖就一定能提升性能。其实不是的防抖和节流对浏览器的scroll事件提升有限因为scroll的触发频率本身就很高而且无法取消。真正的关键其实是在事件回调里尽量少做DOM读写操作以及在下一帧渲染之前批量更新样式。我举个例子一个列表页滚动时需要在导航栏顶部显示滚动距离。如果你在scroll回调里直接读取scrollTop然后设置某个元素的transform这本身问题不大。但如果你在scroll回调里还做了getBoundingClientRect()、读取offsetTop这种布局信息再设置样式那就容易触发强制同步布局导致掉帧。因为浏览器会为了拿到最新的布局信息强制同步计算一次Layout。正确姿势是做一波读写分离先把所有需要的数据读出来攒到requestAnimationFrame回调里统一执行写操作比如设置样式、插入DOM。下面是一个简易的读写分离实现// 读写分离读操作立即执行写操作延迟到下一帧 const state { scrollY: 0, rects: [] }; let rafId null; function onScroll() { // 读操作立即执行不需要等渲染 state.scrollY window.scrollY; const items document.querySelectorAll(.item); state.rects Array.from(items, el el.getBoundingClientRect().top); // 写操作交给requestAnimationFrame统一执行 if (rafId null) { rafId requestAnimationFrame(() { applyChanges(state); rafId null; }); } }这个模式的收益在元素数量多或者操作频率高的场景下非常明显。我处理过一个图片瀑布流项目的滚动卡顿通过读写分离加requestAnimationFrame批量更新掉帧率从45%降到了8%。4.3 DOM操作是性能黑洞批量更新、文档片段、虚拟列表前端性能书上说了无数遍的“减少DOM操作”但实际操作起来大家总觉得无从下手。这里给出一条清晰的行动路径按优先级从高到低。第一优先级是批量更新减少布局抖动。不要一个数据一个数据地改样式把多次DOM写操作合并到一次里执行。Vue和React这类框架天然帮你做了一部分批处理工作但如果你写的是原生JS就需要自己控制。插入大量节点时用DocumentFragment先组织好再一次性插入修改样式时优先用style.cssText或者一次性修改class不要逐条改style.width、style.height。第二优先级是减少节点数量和层级。DOM节点太多浏览器维护节点树本身就要消耗内存和计算布局计算也会更慢。有一次我接手一个聊天页面节点数量超过5000个滚动时每帧都要做布局计算卡得没法用。后来做了虚拟列表只渲染可视区域加缓冲区的节点节点数量降到100个以内性能问题直接消失。虚拟列表是长列表场景的必选项市面上有成熟的库比如react-virtualized、vue-virtual-scroller也可以自己实现核心就是计算可视区的起始索引和结束索引上下各留几行缓冲然后根据滚动位置裁剪或复用DOM节点。第三优先级是事件代理。如果一个列表里有1000个按钮每个按钮都绑定一个click事件那就有1000个监听器。事件代理的思路是只给列表容器绑定一个监听器通过event.target判断用户点击的是哪个按钮然后分发逻辑。这不仅减少了内存占用还简化了后续新增节点的处理——新增按钮不用再单独绑定事件了。原生JS的事件代理语法很简单而且Vue和React也在底层帮你做了类似的事情但对原生JS项目来说这件事依然重要。4.4 requestAnimationFrame和requestIdleCallback的正确打开方式很多前端只知道requestAnimationFrame可以用来做动画其实它也是跟帧同步的最佳工具。动画的本质是每一帧渲染之前浏览器要把你设置的样式变化计算并绘制出来。所以样式更新放在requestAnimationFrame里能保证更新跟渲染同步不会错位导致跳帧。但要注意requestAnimationFrame回调里的代码如果执行时间过长依然会拖垮帧率。因为它是在帧的开头执行的如果你的回调执行了100ms那这一帧就没法在16.7ms内完成掉帧就是必然的。所以在requestAnimationFrame里你只应该做轻量级的更新重计算应该在它之前用普通异步完成。而requestIdleCallback是用来处理低优先级任务的在浏览器的空闲时间段执行不紧急的工作。典型场景上报日志、预处理可能用得上的数据、懒加载的资源和缓存预热。它的执行优先级很低不会影响动画和交互。// 用requestIdleCallback做空闲时间的预处理 if (requestIdleCallback in window) { requestIdleCallback(() { precomputeUserData(); }, { timeout: 2000 }); } else { // 兼容性兜底不给不支持的低版本浏览器增加负担 setTimeout(() precomputeUserData(), 2000); }这里有一个兼容性提醒requestIdleCallback在Safari上长期不支持所以适应性处理还是必须的。其次别在requestIdleCallback里做任何会触发布局或绘制的操作否则它就不再是“空闲”了。5. 内存管理别让页面越用越卡5.1 内存泄漏是流畅度的隐形杀手用户打开你的页面用着用着越来越卡最后直接闪退——这大概率是内存泄漏。内存泄漏的意思是你创建了对象、注册了事件、启动了定时器但在不需要的时候没有及时释放导致内存占用只增不减。常见的JS内存泄漏场景集中在几个地方全局变量挂载无意间把对象挂到了window上进程结束前都不会被回收。定时器未清理setInterval启动后组件销毁时忘了clearInterval回调还在引用着旧的DOM和数据。事件监听器未移除尤其是把匿名函数当作事件监听器绑在全局对象或DOM上移除的时候removeEventListener用的却是另一个函数等于没移除。闭包引用一个被全局变量引用的函数它的闭包作用域里还链接着一大堆本来早就可以释放的数据。持续增加的缓存自己实现的数据缓存Map只增不减没有做LRU淘汰或容量限制。排查内存泄漏最直观的方式是Chrome的Memory面板做三次“操作→快照”的对照先记录一个堆快照执行某个操作比如打开弹窗再关闭再记录一次快照然后重复几次。如果堆大小在单调上升且没有回落基本就是泄漏了。然后用Comparison视图看新增的对象里有哪些是意外的——那帮你锁定了泄漏源。5.2 数据结构和闭包的隐藏成本内存泄漏之外还有一个更隐蔽的问题不合理的对象结构导致GC压力过大。这里要引出V8引擎的隐藏类Hidden Class和内联缓存Inline Cache概念。简单来说V8为了快速读取对象属性会为对象创建隐藏类。如果你在代码里给一个对象不断添加新属性obj.a 1; obj.b 2; obj.c 3;V8就得不断更新隐藏类导致属性读取速度下降。更常见的GC压力来源是“频繁创建对象但不长期使用”。比如在循环体里const temp { a: i, b: i * 2 }这个对象在下一轮循环就没人引用了但每循环一次就创建一次短时间内创建大量短生命周期的对象会迫使GC频繁执行。解决思路就是对象复用在循环外只创建一次循环里只改属性值。这和C里循环外分配内存的做法异曲同工。闭包的问题在于只要闭包函数还被引用它捕获的所有变量都会一直存活。我见过一个项目因为一个简单的useCallback依赖数组写错导致回调返回新的闭包这个闭包又引用了大量的数据结果导致组件一遍遍重新渲染加累积内存。这种现象在React项目里尤其常见。不是不能用闭包而是要知道闭包会持有外部变量直到闭包本身被回收所以不要让长生命周期的闭包轻易捕获大对象。5.3 Web Worker把计算负担从主线程挪走JS是单线程的但浏览器的多线程能力其实一直摆在那里——Web Worker就是那个能帮你把主线程计算压力转移出去的工具。任何CPU密集型任务比如图像处理、数据解析、加密解密、大规模数组运算都适合挪进Worker里做。Worker在后台线程执行不占用主线程所以不会影响页面渲染和交互。举个实战场景页面上传一个几十MB的文件需要做内容预览比如生成hash、解析元数据。这些操作在主线程做会让页面卡死几秒甚至十几秒——用户在这个期间没法滚动也没法点击。把逻辑挪到Worker之后主线程只是发个消息过去用户该干嘛干嘛Worker算完再PostMessage回来更新UI。// 主线程中的调用 const worker new Worker(/worker.js); worker.postMessage({ type: process, payload: fileData }); worker.onmessage (e) { updatePreview(e.data.result); }; // worker.js 内部逻辑 self.onmessage (e) { const { payload } e.data; const result heavyProcessing(payload); self.postMessage({ result }); };对于“不能改造成Worker”的计算因为要操作DOM可以退而求其次用前面讲的任务分片方案在主线程的间隙里做完。两者思路互补共同目标都是把主线程留给渲染和交互降低掉帧和点击延迟的概率。Worker的限制也提一下它不能访问DOM所以数据需要PostMessage序列化传输大对象的拷贝成本可能吃掉优化收益。新版浏览器支持Transferable Objects可以把ArrayBuffer的所有权移交给Worker实现零拷贝传输。在处理大型二进制数据时用这个方案可以避免结构克隆的开销。6. 实操避坑总结这些坑我替你先踩了6.1 JavaScript性能误区自查清单写做性能优化这些年我踩过不少坑也有过很多“原来如此”的时刻。最后整理几个高频误区给大家做自查用。第一个误区只看Lighthouse分数而不看具体指标项。Lighthouse总分高不代表体验好。有次我优化一个项目Lighthouse打到了98分但真实用户在微信内置浏览器里打开还是很慢。原因在于微信内置浏览器有一些自己的缓存和加载策略Lighthouse模拟的环境覆盖不到。这类问题只能靠真实设备和真实网络环境去测再结合线上监控数据才能暴露。第二个误区把所有代码都拆成异步加载。异步加载能减少首屏阻塞但异步chunk太多也有代价——更多网络请求、更复杂的加载依赖、更长的加载链路。拆分的粒度应该以“首屏所需之外的东西才拆”为原则为拆而拆反而可能更慢。第三个误区只优化代码不优化网络和服务器。JS由服务器返回服务器的响应速度、CDN覆盖、HTTP/2/3的开启情况直接影响JS的加载速度。有时候你代码写得再干净源站服务器在海外用户在国内无论如何都慢。第四个误区忽视低版本设备和WebView。在Chrome上测出60fps不等于所有用户都60fps。现在很多H5页面运行在各种品牌的Android WebView里它们的内核版本差异极大。优化完一定要做设备矩阵实测——一台千元Android机跑一遍你的页面你就知道什么叫现实了。6.2 高频性能问题的排查套路速查表下面把性能问题按现象归类给出对应的排查入口和首选方案供大家定位问题时直接翻阅。现象优先排查方向常用手段页面加载慢资源体积、请求数量、缓存代码分割、压缩、CDN、HTTP缓存首屏长时间空白渲染路径、同步脚本defer/async、内联关键CSS、SSR滚动/动画掉帧主线程长任务、强制重排读写分离、防抖节流、Worker点击响应延迟事件处理中的重计算逻辑拆分、减负回调、避免同步布局越用越卡内存泄漏、对象失控堆快照、事件清理、定时器清理低端机白屏代码兼容性、内存溢出降级策略、动态import、压缩尺寸这套速查表的特点是按“现象”来组织而不是按“工具”来组织。遇到问题先归类再对症下药。实战中90%以上的性能问题都能在这张表里找到对应的处理路径。6.3 给自己设一条性能预算红线最后一个建议是把性能优化制度化给项目设一条性能预算的红线。比如首屏JS总体积不超过200KB压缩后LCP不超过2.5秒CLS不超过0.1任何单次构建新增依赖的体积增量超过5KB必须review。把这条红线写进CI流程里构建时检查超出就报警。这样性能问题才能被拦截在发布之前而不是上线后靠用户投诉来驱动。我实际执行过一版简单的体积预算检查脚本构建完成后解析打包产物读取每个chunk的gzip后大小和预算文件里设定的阈值对比超了就让构建失败。这个机制大概花了半天时间来搭建之后的收益是持续的。从此再也没有出现过“加了个80KB的图表库没人发现”这种事后尴尬。性能优化从来不是某个“大版本”的事而是一种持续工程习惯。基线数据、监控日志、预算红线一个都不能少。这些东西搭好之后后面的手段都是锦上添花了。
JavaScript性能优化全攻略：从用户感知到工程落地
1. 性能优化先想清楚你是在优化“感受”还是在优化“数字”先说个我踩过好几次的坑拿到一个JS性能问题直接就开始看代码、找循环、改算法折腾大半天最后发现用户该卡还是卡。为什么因为大多数性能问题根本不在代码本身而在加载路径和渲染时机上。JavaScript性能优化这件事本质上不是“让代码跑得更快”而是“让用户觉得更快”。这俩有本质区别。用户感知到的性能由几个关键节点决定首屏能看到的等待时间、交互后的响应延迟、滚动和动画的流畅度。如果你只盯着V8引擎里某个函数的执行时间那基本属于用错了力。我之前接手过一个移动端H5项目首屏加载要4秒多产品天天催。我一开始也是先去看JS有没有性能瓶颈结果发现压缩后的业务代码才100多KB根本不至于这样。后来一查真正的问题是页面里有8个独立第三方SDK的script标签全部同步加载而且图片资源没做尺寸裁剪一张首图2MB。把这些东西理顺之后首屏直接进1.5秒以内JS代码一行没改。这就是我想说的第一件事性能优化第一步是建立正确的问题定位方式而不是急着写优化代码。你得先搞明白瓶颈在哪一层——网络层、渲染层、还是纯计算层。网络层慢你优化算法没用渲染层卡你优化网络也没用。另外要注意的是性能优化不是一锤子买卖。代码在不断演进依赖在不断升级性能也会随之波动。所以科学的做法是把性能优化做成一个可持续的流程建立基线、持续监控、回归对比。很多团队做了第一轮优化就完事了三个月后性能又烂回去了就是因为缺少监控和兜底机制。所以这篇文章我不会只讲技巧我会把完整的优化思路、工具链、实战套路都过一遍。你跟着这个路径去做至少能把80%的JavaScript性能问题都解决掉剩下的20%才需要靠极致的底层调优去拼。2. 先测量再动手没有数据支撑的优化都是瞎折腾2.1 性能基线怎么建立别靠“感觉卡了”去立项做性能优化最容易犯的错就是靠感觉判断哪里卡。你觉得这个页面卡但卡的是什么是加载慢是滚动掉帧是按钮点击没反应每种卡顿的成因完全不同解决方案也完全不同。一个合格的性能优化项目开工前必须建立量化基线。我最常用的组合是以下几个工具覆盖不同维度工具作用使用场景Lighthouse生成性能评分和关键指标整体评估、定基线Performance面板录制或实时查看调用栈和耗时定位CPU瓶颈和长任务Network面板分析资源加载时间和顺序定位网络层瓶颈Bundle分析器看打包产物的体积构成定位依赖过重和冗余代码Performance API在真实用户环境采集指标线上监控、长期追踪Lighthouse测出来的评分只是一个参考维度我更关注它下面的几个具体指标First Contentful Paint、Largest Contentful Paint、Speed Index、Time to Interactive。这些指标直接对应了用户能感知的加载体验。第一次跑Lighthouse的时候一定要记录所有数据这就是你的基线。业内常用的基线整理方式是这样的固定一个测试设备比如一台中端Android真机固定网络环境比如用DevTools的Slow 4G模拟然后跑三次取中位数。不能用高端PC和Wi-Fi去测那样测出来的数据对真实用户没有参考意义。我之前给一个项目做优化用Mac上的Chrome测出来Lighthouse能打95分结果拿同事的小米手机一测首屏要5秒。设备的性能差距在JS处理上放大得非常明显。Performance面板则是定位运行时问题的核心工具。录制一段操作过程重点看几个地方有没有长任务Long Tasks超过50ms的任务都会在Timeline上标红、脚本执行时间在整个耗时里占比多少、有没有明显的强制同步布局Forced Reflow标记。我之前排查一个表格页卡的滚动问题就是用Performance面板录了三秒钟的滚动发现几乎每一帧都有一个紫色高亮的Layout标记说明是在滚动过程中反复改样式导致的强制重排。这问题用肉眼是不可能看出来的。2.2 必看的Core Web Vitals别再盯着PV和UV做性能了从用户角度来度量性能Google推行的Web Core Vitals是你绕不开的框架。它包含三项指标LCP最大内容绘制、INP交互到下一次绘制的延迟、CLS累积布局偏移。这三项分别对应加载体验、交互体验、视觉稳定性。LCP衡量的是页面最大元素通常是首屏图或者大标题渲染出来的时间。超过2.5秒就算差。优化LCP的核心思路就一条让最大的那个元素尽早开始加载并渲染。通常手段包括预加载关键图片link relpreload、避免用JS动态插入首屏内容、服务端渲染或者预渲染SSR/SSG、去掉阻塞渲染的同步脚本。INP是2024年Google用Interaction to Next Paint替代了原来的First Input Delay用来衡量用户交互后页面响应的快慢。这个指标考察的是从用户点击到页面画出视觉反馈的时间。要优化INP核心就是减少事件处理中的主线程阻塞时间把复杂的计算拆开做或者挪到Web Worker中避免在事件回调里做重型操作。CLS衡量的是页面加载过程中元素突然跳动的程度。这个往往是前端容易忽略的点没有给图片和广告位预留尺寸、字体加载后导致文字位置变化、异步插入的DOM把下面的内容挤下去——这些都是CLS的元凶。修起来其实不复杂给媒体元素加上宽高属性用aspect-ratio预留空间字体用font-display: swap但就是需要你有这个意识。提示如果你们团队有条件可以用web-vitals这个npm包把真实的指标数据上报到自己的监控平台这是我从“靠工具测”升级到“线上持续观测”的关键一步。2.3 用Performance API做线上真实性能监控本地测Lighthouse只能代表理想环境真实用户手里的手机千奇百怪网络环境更是复杂。所以我建议任何有点规模的项目都要接线上性能监控。不用非得买商业产品自己用Performance API就能搭一个轻量的方案。PerformanceObserver可以监听largest-contentful-paint和layout-shift等性能条目。我分享一个简单的采集代码思路// 一个极简的线上性能数据采集示例 const observer new PerformanceObserver((list) { for (const entry of list.getEntries()) { if (entry.entryType largest-contentful-paint) { // 这里把数据发送到你的监控服务器 sendBeacon(/api/perf, JSON.stringify({ type: LCP, value: entry.startTime, url: location.href })); observer.disconnect(); } } }); observer.observe({ type: largest-contentful-paint, buffered: true });navigator.sendBeacon这个方法很适合发送性能日志因为它在页面卸载时也能可靠地把数据发出去不会因为跳转丢数据。采集到的数据存下来之后按设备、网络、页面维度去聚合就能看出哪些页面在哪些场景下性能差再针对性去优化。这里我就不展开讲监控平台的搭建了核心思路就是真实用户数据才是最终裁判。3. 加载阶段提速让页面更早可交互3.1 JS体积控制从依赖和构建产物下刀JavaScript性能优化的第一刀应该砍在不需要执行的代码上。你让浏览器下载并解析的每一KB代码都在消耗用户的流量和CPU。尤其是移动端低端手机的JS解析速度比桌面端慢4到5倍。我处理过一个项目打包后的JS有800KB压缩后也有近250KB。用Bundle分析器一看好家伙moment.js一个库就占了50KB但整个项目只用到了它的format功能。换成dayjs之后直接少了45KB。后来又发现lodash全量引入但实际只用了debounce和get两个函数改成按需引入后又省了30KB。这里要给大家说一个具体可操作的原则任何依赖库能按需引入就按需引入能用轻量替代品就果断替换。引入依赖前问自己两个问题这个库的功能我能不能用原生API实现如果能节省的代码量值不值得我用一个库原生fetch已经很好用了非要为了兼容引入axiosArray.prototype.flat、Object.fromEntries这些ES2019能力都已经普及了没必要为了它们引入工具库。构建层面的配置也很重要。如果你是Webpack 5注意开启moduleConcatenation提升作用域配合terser-webpack-plugin做极致压缩。如果你用的是Vite构建时用的是Rollup天然会做tree shaking。但不管哪个构建工具都需要你自己去检查两件事有没有把整个库的dist文件直接import进来导致tree shaking失效有没有在入口文件里import了一个有很多副作用的模块。还有一点就是按需加载和动态import。把首屏不需要的代码比如弹窗组件、详情页逻辑、图表库拆成独立的chunk用户用到时才加载。这个在Webpack和Vite里都支持语法就是const { default: Chart } await import(./Chart.vue)这种方式。拆完之后要注意检查chunk体积如果一个异步chunk还是很大就要继续拆。实操心得拆代码之后我一般会同时做两件事给chunk起可读性强的名字Webpack的magic comments方便在Network面板里定位在代码分割点上加错误边界逻辑异步加载失败时提示用户刷新而不是白屏。3.2 用对缓存策略HTTP缓存和Service Worker两手都要硬缓存这个环节经常被低估。很多团队觉得上线就完事了结果老用户每次打开页面都要重新下载所有资源。这体验能不慢吗HTTP缓存的核心原则是内容不变的资源让浏览器永远用缓存内容变化的资源让URL跟着内容变。典型的做法给静态资源文件名加上内容哈希app.8f7d2c.js然后设置Cache-Control: max-age31536000, immutable。文件名变了URL就变了用户自然加载新文件文件名不变就直接用缓存连网络请求都不发。但HTTP缓存的局限在于首次访问没有缓存还是要走完整的下载流程。要突破这个局限就得靠Service Worker做App Shell缓存。Service Worker的思路是在你第一次访问页面的时候把框架代码、基础样式、公共图片这些“外壳”资源全部预缓存到本地。第二次访问的时候直接从Service Worker缓存里读取几乎可以做到秒开。我参与的一个项目加了Service Worker预缓存之后老用户从二次进入到页面完全渲染时间从1.8秒降到了0.4秒。用户体验的提升是质变级别的。当然Service Worker的坑也不少更新策略、缓存版本管理、白屏风险。一个稳妥的方案是采用stale-while-revalidate策略页面永远先用缓存的旧版本渲染后台静默拉取新版本拉到了就更新缓存并在下次加载时切换。这样用户永远能看到内容不会因为缓存更新而白屏。还有一个大家问得多的问题图片和视频这类大资源要不要进Service Worker我的建议是大部分不要。图片走HTTP缓存就够了Service Worker缓存图片容易撑爆存储配额。除非是用户最高频使用的页面配图否则别做这个收益有限还增加复杂度。3.3 图片和字体是性能隐形杀手别只盯着JSJS是主线程的计算负担但页面上绝大多数体积来自图片。如果图片没优化好JS优化得再彻底加载体验实际也提升不了多少。图片优化的核心就三件事格式、尺寸、解码方式。格式上能上WebP就上WebP甚至可以考虑AVIF大部分现代浏览器都支持。尺寸上上一套响应式图片方案用srcset让移动端只加载480px宽的图桌面端加载1920px宽的图别让手机用户下载一张2MB的高清大图。解码方式上开启loadinglazy做懒加载优先加载首屏的图。图片懒加载这个属性现在是原生支持的了不用再引库。字体这块是个隐性痛点。中文字体动辄几MB如果直接用font-face包裹一整份中文字体文件那是一场灾难。我现在处理中文字体的套路是只加载页面上实际出现的文字对应的子集字体通过字体子集化工具比如fontmin只保留需要的字形或者直接用unicode-range把字体切分成多个子集浏览器按需加载。如果条件实在有限就把字体优先级调低优先保证系统字体渲染项目字体加载完再替换这就是font-display: swap的作用代价是有FOIT无样式文字闪烁但总比白屏好。注意图片懒加载也不是无脑加的首屏图片千万别加loadinglazy因为浏览器可能不知道哪张图优先导致首屏图被推迟到很晚才加载。这也是加了懒加载反而首屏变慢的常见原因。4. 运行时流畅度从主线程手里抢时间4.1 主线程的长任务拆分从“一次干完”到“分次干完”JS是单线程语言所有DOM操作、事件回调、计算逻辑都挤在主线程上。如果某个任务的执行时间超过50ms浏览器就有可能出现掉帧、卡顿。这就是为什么我们做运行时优化时核心目标就是消灭长任务或者至少把它们拆短。拆分长任务的最简单方案是让出主线程。思路是把一个需要几百毫秒才能执行完的逻辑拆成多个小块每个小块之间用setTimeout或者MessageChannel让浏览器有空闲时间插入渲染。这里我推荐优先用MessageChannel因为setTimeout在浏览器里有一个最小4ms的延迟限制嵌套层数较多时MessageChannel能更快地把任务交还给主线程。// 用MessageChannel做任务分片调度的示例 function scheduleYield() { return new Promise(resolve { const channel new MessageChannel(); channel.port1.onmessage () resolve(); channel.port2.postMessage(null); }); } async function processLargeArray(items) { const CHUNK_SIZE 1000; for (let i 0; i items.length; i CHUNK_SIZE) { // 处理当前分片 const chunk items.slice(i, i CHUNK_SIZE); processChunk(chunk); // 让出主线程让浏览器有机会渲染和响应输入 await scheduleYield(); } }另一个更现代、更优雅的方案是Scheduler API里的await scheduler.yield()。虽然目前它的浏览器兼容性还没有全覆盖但在Chrome 119里已经可以用了而且它是由浏览器原生调度上下文和优先级比手写MessageChannel方案更可靠。如果项目对浏览器内核版本要求高比如必须支持老版本WebView使用MessageChannel方案做降级即可。还有一类任务是“拆了也白拆”的——比如用户在滚动中scroll事件高频触发你有大量逻辑在处理。这时候除了拆任务更关键的是防抖和节流以及把部分逻辑挪出主线程。4.2 防抖和节流高频事件的保命手段前端性能优化的基础功就是防抖和节流。防抖适合处理搜索输入这类“只关心最后一次输入结果”的场景用户连续输入时只有在停止输入多少毫秒后才会执行真正的逻辑。节流适合处理滚动、鼠标移动、窗口缩放这些“在一定时间内最多执行一次”的场景保证逻辑不会因为事件高频触发而崩溃。但很多人的误解在于用了防抖就一定能提升性能。其实不是的防抖和节流对浏览器的scroll事件提升有限因为scroll的触发频率本身就很高而且无法取消。真正的关键其实是在事件回调里尽量少做DOM读写操作以及在下一帧渲染之前批量更新样式。我举个例子一个列表页滚动时需要在导航栏顶部显示滚动距离。如果你在scroll回调里直接读取scrollTop然后设置某个元素的transform这本身问题不大。但如果你在scroll回调里还做了getBoundingClientRect()、读取offsetTop这种布局信息再设置样式那就容易触发强制同步布局导致掉帧。因为浏览器会为了拿到最新的布局信息强制同步计算一次Layout。正确姿势是做一波读写分离先把所有需要的数据读出来攒到requestAnimationFrame回调里统一执行写操作比如设置样式、插入DOM。下面是一个简易的读写分离实现// 读写分离读操作立即执行写操作延迟到下一帧 const state { scrollY: 0, rects: [] }; let rafId null; function onScroll() { // 读操作立即执行不需要等渲染 state.scrollY window.scrollY; const items document.querySelectorAll(.item); state.rects Array.from(items, el el.getBoundingClientRect().top); // 写操作交给requestAnimationFrame统一执行 if (rafId null) { rafId requestAnimationFrame(() { applyChanges(state); rafId null; }); } }这个模式的收益在元素数量多或者操作频率高的场景下非常明显。我处理过一个图片瀑布流项目的滚动卡顿通过读写分离加requestAnimationFrame批量更新掉帧率从45%降到了8%。4.3 DOM操作是性能黑洞批量更新、文档片段、虚拟列表前端性能书上说了无数遍的“减少DOM操作”但实际操作起来大家总觉得无从下手。这里给出一条清晰的行动路径按优先级从高到低。第一优先级是批量更新减少布局抖动。不要一个数据一个数据地改样式把多次DOM写操作合并到一次里执行。Vue和React这类框架天然帮你做了一部分批处理工作但如果你写的是原生JS就需要自己控制。插入大量节点时用DocumentFragment先组织好再一次性插入修改样式时优先用style.cssText或者一次性修改class不要逐条改style.width、style.height。第二优先级是减少节点数量和层级。DOM节点太多浏览器维护节点树本身就要消耗内存和计算布局计算也会更慢。有一次我接手一个聊天页面节点数量超过5000个滚动时每帧都要做布局计算卡得没法用。后来做了虚拟列表只渲染可视区域加缓冲区的节点节点数量降到100个以内性能问题直接消失。虚拟列表是长列表场景的必选项市面上有成熟的库比如react-virtualized、vue-virtual-scroller也可以自己实现核心就是计算可视区的起始索引和结束索引上下各留几行缓冲然后根据滚动位置裁剪或复用DOM节点。第三优先级是事件代理。如果一个列表里有1000个按钮每个按钮都绑定一个click事件那就有1000个监听器。事件代理的思路是只给列表容器绑定一个监听器通过event.target判断用户点击的是哪个按钮然后分发逻辑。这不仅减少了内存占用还简化了后续新增节点的处理——新增按钮不用再单独绑定事件了。原生JS的事件代理语法很简单而且Vue和React也在底层帮你做了类似的事情但对原生JS项目来说这件事依然重要。4.4 requestAnimationFrame和requestIdleCallback的正确打开方式很多前端只知道requestAnimationFrame可以用来做动画其实它也是跟帧同步的最佳工具。动画的本质是每一帧渲染之前浏览器要把你设置的样式变化计算并绘制出来。所以样式更新放在requestAnimationFrame里能保证更新跟渲染同步不会错位导致跳帧。但要注意requestAnimationFrame回调里的代码如果执行时间过长依然会拖垮帧率。因为它是在帧的开头执行的如果你的回调执行了100ms那这一帧就没法在16.7ms内完成掉帧就是必然的。所以在requestAnimationFrame里你只应该做轻量级的更新重计算应该在它之前用普通异步完成。而requestIdleCallback是用来处理低优先级任务的在浏览器的空闲时间段执行不紧急的工作。典型场景上报日志、预处理可能用得上的数据、懒加载的资源和缓存预热。它的执行优先级很低不会影响动画和交互。// 用requestIdleCallback做空闲时间的预处理 if (requestIdleCallback in window) { requestIdleCallback(() { precomputeUserData(); }, { timeout: 2000 }); } else { // 兼容性兜底不给不支持的低版本浏览器增加负担 setTimeout(() precomputeUserData(), 2000); }这里有一个兼容性提醒requestIdleCallback在Safari上长期不支持所以适应性处理还是必须的。其次别在requestIdleCallback里做任何会触发布局或绘制的操作否则它就不再是“空闲”了。5. 内存管理别让页面越用越卡5.1 内存泄漏是流畅度的隐形杀手用户打开你的页面用着用着越来越卡最后直接闪退——这大概率是内存泄漏。内存泄漏的意思是你创建了对象、注册了事件、启动了定时器但在不需要的时候没有及时释放导致内存占用只增不减。常见的JS内存泄漏场景集中在几个地方全局变量挂载无意间把对象挂到了window上进程结束前都不会被回收。定时器未清理setInterval启动后组件销毁时忘了clearInterval回调还在引用着旧的DOM和数据。事件监听器未移除尤其是把匿名函数当作事件监听器绑在全局对象或DOM上移除的时候removeEventListener用的却是另一个函数等于没移除。闭包引用一个被全局变量引用的函数它的闭包作用域里还链接着一大堆本来早就可以释放的数据。持续增加的缓存自己实现的数据缓存Map只增不减没有做LRU淘汰或容量限制。排查内存泄漏最直观的方式是Chrome的Memory面板做三次“操作→快照”的对照先记录一个堆快照执行某个操作比如打开弹窗再关闭再记录一次快照然后重复几次。如果堆大小在单调上升且没有回落基本就是泄漏了。然后用Comparison视图看新增的对象里有哪些是意外的——那帮你锁定了泄漏源。5.2 数据结构和闭包的隐藏成本内存泄漏之外还有一个更隐蔽的问题不合理的对象结构导致GC压力过大。这里要引出V8引擎的隐藏类Hidden Class和内联缓存Inline Cache概念。简单来说V8为了快速读取对象属性会为对象创建隐藏类。如果你在代码里给一个对象不断添加新属性obj.a 1; obj.b 2; obj.c 3;V8就得不断更新隐藏类导致属性读取速度下降。更常见的GC压力来源是“频繁创建对象但不长期使用”。比如在循环体里const temp { a: i, b: i * 2 }这个对象在下一轮循环就没人引用了但每循环一次就创建一次短时间内创建大量短生命周期的对象会迫使GC频繁执行。解决思路就是对象复用在循环外只创建一次循环里只改属性值。这和C里循环外分配内存的做法异曲同工。闭包的问题在于只要闭包函数还被引用它捕获的所有变量都会一直存活。我见过一个项目因为一个简单的useCallback依赖数组写错导致回调返回新的闭包这个闭包又引用了大量的数据结果导致组件一遍遍重新渲染加累积内存。这种现象在React项目里尤其常见。不是不能用闭包而是要知道闭包会持有外部变量直到闭包本身被回收所以不要让长生命周期的闭包轻易捕获大对象。5.3 Web Worker把计算负担从主线程挪走JS是单线程的但浏览器的多线程能力其实一直摆在那里——Web Worker就是那个能帮你把主线程计算压力转移出去的工具。任何CPU密集型任务比如图像处理、数据解析、加密解密、大规模数组运算都适合挪进Worker里做。Worker在后台线程执行不占用主线程所以不会影响页面渲染和交互。举个实战场景页面上传一个几十MB的文件需要做内容预览比如生成hash、解析元数据。这些操作在主线程做会让页面卡死几秒甚至十几秒——用户在这个期间没法滚动也没法点击。把逻辑挪到Worker之后主线程只是发个消息过去用户该干嘛干嘛Worker算完再PostMessage回来更新UI。// 主线程中的调用 const worker new Worker(/worker.js); worker.postMessage({ type: process, payload: fileData }); worker.onmessage (e) { updatePreview(e.data.result); }; // worker.js 内部逻辑 self.onmessage (e) { const { payload } e.data; const result heavyProcessing(payload); self.postMessage({ result }); };对于“不能改造成Worker”的计算因为要操作DOM可以退而求其次用前面讲的任务分片方案在主线程的间隙里做完。两者思路互补共同目标都是把主线程留给渲染和交互降低掉帧和点击延迟的概率。Worker的限制也提一下它不能访问DOM所以数据需要PostMessage序列化传输大对象的拷贝成本可能吃掉优化收益。新版浏览器支持Transferable Objects可以把ArrayBuffer的所有权移交给Worker实现零拷贝传输。在处理大型二进制数据时用这个方案可以避免结构克隆的开销。6. 实操避坑总结这些坑我替你先踩了6.1 JavaScript性能误区自查清单写做性能优化这些年我踩过不少坑也有过很多“原来如此”的时刻。最后整理几个高频误区给大家做自查用。第一个误区只看Lighthouse分数而不看具体指标项。Lighthouse总分高不代表体验好。有次我优化一个项目Lighthouse打到了98分但真实用户在微信内置浏览器里打开还是很慢。原因在于微信内置浏览器有一些自己的缓存和加载策略Lighthouse模拟的环境覆盖不到。这类问题只能靠真实设备和真实网络环境去测再结合线上监控数据才能暴露。第二个误区把所有代码都拆成异步加载。异步加载能减少首屏阻塞但异步chunk太多也有代价——更多网络请求、更复杂的加载依赖、更长的加载链路。拆分的粒度应该以“首屏所需之外的东西才拆”为原则为拆而拆反而可能更慢。第三个误区只优化代码不优化网络和服务器。JS由服务器返回服务器的响应速度、CDN覆盖、HTTP/2/3的开启情况直接影响JS的加载速度。有时候你代码写得再干净源站服务器在海外用户在国内无论如何都慢。第四个误区忽视低版本设备和WebView。在Chrome上测出60fps不等于所有用户都60fps。现在很多H5页面运行在各种品牌的Android WebView里它们的内核版本差异极大。优化完一定要做设备矩阵实测——一台千元Android机跑一遍你的页面你就知道什么叫现实了。6.2 高频性能问题的排查套路速查表下面把性能问题按现象归类给出对应的排查入口和首选方案供大家定位问题时直接翻阅。现象优先排查方向常用手段页面加载慢资源体积、请求数量、缓存代码分割、压缩、CDN、HTTP缓存首屏长时间空白渲染路径、同步脚本defer/async、内联关键CSS、SSR滚动/动画掉帧主线程长任务、强制重排读写分离、防抖节流、Worker点击响应延迟事件处理中的重计算逻辑拆分、减负回调、避免同步布局越用越卡内存泄漏、对象失控堆快照、事件清理、定时器清理低端机白屏代码兼容性、内存溢出降级策略、动态import、压缩尺寸这套速查表的特点是按“现象”来组织而不是按“工具”来组织。遇到问题先归类再对症下药。实战中90%以上的性能问题都能在这张表里找到对应的处理路径。6.3 给自己设一条性能预算红线最后一个建议是把性能优化制度化给项目设一条性能预算的红线。比如首屏JS总体积不超过200KB压缩后LCP不超过2.5秒CLS不超过0.1任何单次构建新增依赖的体积增量超过5KB必须review。把这条红线写进CI流程里构建时检查超出就报警。这样性能问题才能被拦截在发布之前而不是上线后靠用户投诉来驱动。我实际执行过一版简单的体积预算检查脚本构建完成后解析打包产物读取每个chunk的gzip后大小和预算文件里设定的阈值对比超了就让构建失败。这个机制大概花了半天时间来搭建之后的收益是持续的。从此再也没有出现过“加了个80KB的图表库没人发现”这种事后尴尬。性能优化从来不是某个“大版本”的事而是一种持续工程习惯。基线数据、监控日志、预算红线一个都不能少。这些东西搭好之后后面的手段都是锦上添花了。
