几年前我刚接手一个H5商城项目时首屏白屏时间平均3秒多运营那边反馈转化率掉得很厉害。一开始我也以为性能优化就是压缩图片、加个缓存结果真正把指标从2.8秒优化到0.9秒之后我才意识到这事儿更像是在给整个前端工程做一次全面体检——指标、网络、渲染、构建、监控每个环节都得动手。这篇内容适合正在做前端性能优化的同学也适合准备前端面试时被问到你怎么做性能优化时能讲出完整方法论的朋友。我不会只列一份优化清单而是把每个决策背后的原因、踩过的坑、可复现的步骤都摊开来说。技术方案我尽量用最贴近工程实践的写法不同基础的人都能在自己的项目里找到对应点。1. 先别急着优化把指标、工具、基线一次备齐1.1 你真正该盯住的六个核心指标很多人一上来就开干——压缩图片、加CDN、搞代码分割。其实第一步应该是先回答一个问题你现在到底慢在哪里我自己的做法是先把核心指标定下来前后端对齐一个目标。当前Web性能领域公认的核心指标主要是这六个FCP首次内容绘制、LCP最大内容绘制、CLS累积布局偏移、INP交互到下一次绘制的延迟、TTFB首字节时间、TTI可交互时间。其中LCP、CLS、INP这三个是Google定义的Core Web Vitals核心三件套也是目前行业里做性能评估时最常被引用的。为什么先定指标因为没有基线你就无法验证优化有没有效。你改了一版代码感觉好像变快了这只是错觉。只有把LCP从3.2秒压到2.1秒把CLS从0.18降到0.05你才知道这版改动到底值不值得上线。实际优化时我一般按优先级排序先看TTFB这个是后端和网络层的事如果首字节都要1秒前端再折腾也是白费再看LCP这是用户感知最明显的一环然后看CLS页面加载过程中图片、广告位把布局顶来顶去用户体验会非常糟糕最后看INP点击按钮半天没反应这种卡顿在移动端尤其恼人。FCP和TTI可以作为参考不用太纠结。1.2 用PerformanceObserver拿到真实的用户数据Lighthouse跑出来的数据只是实验室数据lab data它反映的是在特定设备、特定网络条件下的结果。但真实用户分布在各种各样的网络和设备上所以我还建议你在项目里直接采集真实用户数据field data。日常运维里我用的方式是PerformanceObserver这个API。// 监听LCP const lcpObserver new PerformanceObserver((list) { for (const entry of list.getEntries()) { console.log(LCP:, entry.startTime); // 上报到监控平台 } }); lcpObserver.observe({ type: largest-contentful-paint, buffered: true }); // 监听CLS const clsObserver new PerformanceObserver((list) { for (const entry of list.getEntries()) { if (!entry.hadRecentInput) { console.log(CLS:, entry.value); } } }); clsObserver.observe({ type: layout-shift, buffered: true });这里有两个细节容易踩坑。第一个是buffered: true加上它之后PerformanceObserver会回放当前页面已经产生的性能条目否则你如果是在脚本加载完成后才创建观察器很可能会漏掉页面早期的LCP记录。第二个是CLS的hadRecentInput字段它用来过滤用户主动交互导致的布局偏移比如用户点击了一个按钮弹出了一个菜单这种偏移不应该算作性能问题。这个API在目前的主流浏览器里面支持度已经比较好了生产环境可以直接用不需要再引入额外的polyfill。1.3 Lighthouse跑分只能当参考别当信仰Lighthouse是我每次优化前后必跑的工具但我得提醒一句别把Lighthouse的分数当成最终KPI。原因是Lighthouse在模拟移动端环境下会固定CPU降频倍数和网络延迟它测出来的性能分代表的是在限定环境下的大致水平而不是用户的真实体验。我见过一个项目Lighthouse跑出98分但用户在低端安卓机上打开页面卡得跟幻灯片一样。差异就出在实验室环境和真实环境的不同——用户的机型千奇百怪网络也不稳定。更合理的做法是Lighthouse用于发现问题和验证大方向真实线上指标通过PerformanceObserver和埋点上报来监控。两者结合才是一个完整的度量体系。另外提一句这类关于前端性能优化从哪里开始的问题面试里经常会被问到。如果你能说出先定指标、再分层优化、最后做监控闭环面试官通常会觉得你有工程化思维而不是简单背了一堆优化点。2. 网络层资源加载的三座大山怎么拆2.1 第一座山请求数量太多——合并与预连接网络层的优化我习惯用一个比喻页面加载就像搬家如果家具资源太多、路又窄网络慢一次搬一件肯定效率低。所以优化的第一方向就是减少关键路径上的请求数量。在HTTP/1.1时代合并文件是主流做法CSS和JS经常被打成一个包。但到了HTTP/2时代多路复用已经让请求数量不再是最大瓶颈过度合并反而会破坏缓存粒度——你改了一行代码用户就得重新下载整个大文件包。所以我现在的策略是关键资源尽量内联非关键资源做合理的拆分。比如首屏CSS如果只有几KB干脆直接内联到HTML里省掉一次RTT。首屏相关的接口和数据请求从上到下保证一个合理的并行度不要搞几十个请求同时涌出去。另外还有一个性价比极高的操作preconnect和dns-prefetch。如果你的页面要请求第三方域名下的资源比如字体、接口、图片CDN提前在HTML里声明好连接预建就能省下DNS解析和TCP握手的时间。link relpreconnect hrefhttps://api.example.com crossorigin link reldns-prefetch hrefhttps://cdn.example.com这个改动几乎是零成本的但对于有第三方依赖的项目来说首屏时间能肉眼可见地快一些。2.2 第二座山单包体积太大——拆包与压缩请求数量控制住之后下一步就是看单个资源包的大小。特别是JS文件超过200KB未压缩的时候在低端手机上解析和执行的时间会显著拉长。这里推荐一个核心操作按路由拆包 按需加载。首屏只加载当前页面需要的那部分代码其余的路由组件等用户真正跳过去的时候再加载。Webpack的配置大概是这样的// webpack.config.js module.exports { optimization: { splitChunks: { chunks: all, cacheGroups: { vendor: { test: /[\\/]node_modules[\\/]/, name: vendors, priority: 10, reuseExistingChunk: true, }, }, }, }, };这里把node_modules里的第三方依赖单独拆成vendors包可以避免业务代码和依赖混在一起改业务代码时用户不用重新下载巨大的第三方库。Vite项目类似的逻辑在build.rollupOptions里配置。压缩方面现在主流的方案是Brotli它比Gzip的压缩率通常能再高15%到20%。前提是你的Nginx或者网关层支持开启方式很简单# nginx.conf brotli on; brotli_comp_level 6; brotli_types text/css application/javascript application/json image/svgxml;第一次启用Brotli之后我的实际经验是JS文件平均体积下降了18%左右。注意Brotli的压缩级别一般设5到6就够了过高的压缩级别会明显增加服务端CPU开销收益却很有限。2.3 第三座山缓存命中率上不去——缓存策略才是长期收益比起一次性压缩资源的短期收益更重要的其实是缓存策略——这决定了用户离开之后再次回来时还需不需要重复下载资源。我的做法是分类处理HTML文件禁用强缓存使用协商缓存ETag保证每次发布后用户能拿到最新版本带hash的静态资源JS/CSS/图片使用长强缓存Cache-Control: max-age31536000, immutable因为文件名hash变了才代表内容变了没变就直接用本地缓存字体、图片等大体积资源设置合理的过期时间同时配合CDN。location /assets/ { add_header Cache-Control public, max-age31536000, immutable; } location / { add_header Cache-Control no-cache; }这里有一个容易踩的坑很多团队在打包时没有给文件名加hash而是固定叫app.js然后靠服务端改Cache-Control来强制刷新。这做法在发布新版本后会带来一个问题——因为文件名没变、强缓存还没过期用户会一直用旧版本必须手动强刷才看得到新内容。所以一定记得让打包工具给文件名带上内容hash。2.4 移动端弱网下的降级打法前面说的都是通用策略但如果你做的是移动端H5项目还得为弱网场景做专门的降级处理。我遇到过最典型的场景是用户在电梯、地铁、地下车库里打开页面网络信号差得离谱图片一张张转圈整个页面白花花一片。移动端弱网下的几个有效手段图片使用WebP或AVIF格式同质量下体积能再降30%左右首屏用懒加载占位滚到哪加载到哪关键数据接口加超时和重试机制避免白屏转圈等半天用骨架屏替代loading动画给用户内容马上来的心理暗示。其中图片格式这块很多项目不敢上WebP怕老机型不支持。其实可以通过picture标签做优雅降级支持WebP的浏览器加载WebP不支持的就加载JPEGpicture source srcsetimg.webp typeimage/webp img srcimg.jpg alt示例图片 /picture这类移动端性能优化的问题也是面试常客尤其是你做过哪些移动端性能优化这类题目。你能说出弱网场景的降级策略比只会说我压缩了图片要出彩得多。3. 渲染层长列表、大文本、图表闪烁这类老问题怎么破3.1 一万行数据的列表不能靠少渲染一点糊弄网络层搞定之后真正的硬仗在渲染层。最经典的老问题接口一次性返回上万条数据前端直接v-for或者map渲染出来页面直接卡死。为什么会卡因为浏览器要创建一万个DOM节点然后完成布局Layout、绘制Paint、合成Composite这一整套流程。DOM节点越多布局计算量越大重绘范围越广主线程直接崩溃。正解是虚拟滚动虚拟列表只渲染可视区域内那几十条数据。核心思路很简单外层容器固定高度内部用一个占位元素撑起总高度然后根据滚动位置计算当前可见区间的起始索引只渲染这部分数据再用transform: translateY把列表拉到正确位置。如果你不想引入第三方库一个最简版本的思路是// 核心伪代码根据scrollTop计算startIndex和endIndex const startIndex Math.floor(scrollTop / rowHeight); const endIndex Math.min(startIndex visibleCount, total); // 只渲染[startIndex, endIndex]范围内的数据还有一个更低成本的替代方案content-visibility: auto。这个CSS属性可以跳过屏外元素的渲染某些场景下能白捡到不错的性能提升但浏览器兼容性还没有到100%生产环境需要评估一下。虚拟滚动的问题面试里被问到的频率非常高而且面试官通常喜欢追问你能讲一下实现原理吗。上面那段伪代码虽然简单但能把核心原理讲清楚加上为什么不能一次性渲染一万条的原因分析基本上就能过关。3.2 markdown-it渲染大量文字卡顿的解法另一个高频场景是用markdown-it渲染一篇超长文档几万字的文章页面直接卡顿好几秒。这个问题的根源不在于markdown-it本身解析慢而在于解析结果一次性插入了大量DOM节点主线程一直在忙。我当时的解法分三步第一步把markdown的解析过程放到Web Worker里做主线程只负责接收解析好的HTML字符串第二步对解析结果做缓存同一个文档只解析一次切换回来直接用缓存第三步插入DOM时不要一次全部插入用分帧渲染比如每次插入100个节点通过requestIdleCallback分批执行让主线程有喘息的机会。// 分帧渲染的简单示例 function insertInChunks(container, htmlChunks) { let index 0; function insertNext() { if (index htmlChunks.length) return; container.insertAdjacentHTML(beforeend, htmlChunks[index]); index; requestIdleCallback(insertNext, { timeout: 100 }); } insertNext(); }这里面最容易被忽略的是第一步——把解析放到Worker里。很多人觉得markdown-it解析挺快的不需要Worker但文档一旦长到几万字解析本身耗时还好加上生成HTML字符串和DOM节点插入的连续操作主线程就会被长时间占住用户滚动页面都会掉帧。提前用Worker分离出去相当于把阻塞从用户交互的关键路径上挪走体验马上不一样。3.3 ECharts数据刷新闪烁setOption的第二个参数才是关键图表类的性能问题也很典型用ECharts做实时数据展示每秒刷新一次数据结果图表老是闪烁视觉上很难受。这个问题的根源在于**setOption的默认行为**。chart.setOption(option)默认是合并模式也就是新老配置会做合并和diff。如果数据更新很频繁而你的数据结构又比较复杂合并过程可能产生一些过渡动画或者数据替换视觉上就成了闪烁。解决方式有几个方向// 方案一数据完全替换不做合并动画 chart.setOption(option, { notMerge: true, lazyUpdate: true }); // 方案二关闭动画 chart.setOption({ animation: false, });notMerge: true表示不要合并旧配置直接替换lazyUpdate: true表示延迟更新把多次setOption合并成一次渲染。高频数据场景下这两个参数能明显减少闪烁。还有一点如果你做的是纯数据流转的可视化建议优先用ECharts的dataset方式来管理数据它比直接在series里改data性能更好。原理是dataset把数据和配置解耦更新数据时图表的内部diff效率更高。这个优化在数据吞吐量大的监控大屏场景下特别明显。3.4 回流的隐形杀手强制同步布局最后一个渲染层的老问题是强制同步布局Forced Synchronous Layout。它通常不是某个大功能造成的而是代码里不经意的一行操作比如const height element.offsetHeight; // 先读取布局信息 element.style.height height * 2 px; // 再修改样式看似简单的读后写如果放在循环里就会让浏览器反复读布局-触发重排-再读布局性能瞬间爆炸。这在操作大量DOM的表格、列表、拖拽场景里尤为致命。优化的核心原则是把读操作和写操作分开然后统一在用requestAnimationFrame组织的下一帧里执行写操作。或者干脆用transform来做动画和位移因为transform不会触发layout只走合成层性能开销小非常多。这里有一个很实用的排查技巧在Chrome DevTools的Performance面板里录制一段操作如果看到大量紫色的Layout任务挤在一起并且前面有黄色的Schedule Style Recalculation密集出现基本就是强制同步布局在作祟了。4. 构建产物从Webpack到Vite的产物体积控制术4.1 先看产物体积再谈优化构建层面的优化第一步永远是分析产物。不分析就直接配置各种插件等于蒙着眼睛开车。我自己习惯的工具是source-map-explorerWebpack项目和rollup-plugin-visualizerVite项目。跑完后你会得到一个很直观的饼图哪个依赖占了半壁江山哪个组件被打进去了两次一目了然。我见过一个项目一个echarts全量引入就占了打包体积的40%多但实际只用到了折线图和柱状图。这种问题不看体积分析是根本没意识到的。分析完产物之后要给自己定一个预算Performance Budget比如首屏JS总大小不超过200KBgzip后单个chunk不超过150KB页面总请求数不超过30个。定好预算之后后续每次发布前都对照一下超了就拦住这样优化成果才不会在迭代中慢慢腐化。4.2 Tree Shaking到底是怎么丢掉的以及怎么捡回来Tree Shaking是摇树意思是在打包时把没用到的那部分代码干掉。原理依赖ES Module的静态分析特性——import和export语句是静态声明的打包器可以在编译阶段确定哪些导出没有被引用从而把它们从产物体积里剔除。但我在实际项目里遇到过Tree Shaking失效的情况最常见的原因是Babel的编译配置。很多老项目用babel/preset-env时没有设置modules: falseBabel会把ES Module转换成CommonJS的require/module.exports。一旦变成了CommonJS打包器就没法做静态分析了Tree Shaking直接失效。解决办法是在Babel配置里显式声明// babel.config.js module.exports { presets: [ [babel/preset-env, { modules: false }] ] };另外一个容易被忽略的是package.json里的sideEffects字段。如果第三方库没有正确声明sideEffects: false打包器会保守地认为每个模块都有副作用不敢摇掉任何代码。你在项目里排查Tree Shaking不生效的依赖时先去看看那个包是不是忘了声明这个字段。4.3 依赖瘦身日常决策比大重构更管用构建层面的优化很多时候不是靠某个惊天动地的配置而是靠一个个日常决策。我做过几次效果最直接的改动用dayjs替换momentmoment的体积大约300KBdayjs只有2KB且API兼容。替换成本极低产物体积直接瘦掉一块lodash按需引入改成import debounce from lodash/debounce而不是import { debounce } from lodashecharts按需注册只注册用到的图表类型和组件而不是import * as echarts from echarts。这些改动单个看起来都很小但积少成多。我给一个项目做完这三项调整后首屏JS体积下降了将近35%用户反馈最直观的感受是打开页面明显快了。4.4 迁移Vite后的真实收益与隐藏成本最后聊一下从Webpack迁移到Vite。这两年越来越多新项目直接用Vite老项目也有不少在迁移。Vite最直观的收益是开发环境的速度启动一个中大型项目Webpack可能就要20到30秒热更新也要2到3秒Vite基于原生ES Module按需编译启动基本是秒级热更新几乎是瞬间的。构建方面Vite底层用的Rollup产物体积控制做得比Webpack更激进一些比如它默认会做更精细的依赖预打包。但注意Vite的生产构建和开发环境是两套机制不要以为开发环境跑得快构建就一定快。实际对比下来生产构建时间和Webpack互有胜负主要取决于项目的依赖复杂度。迁移时最容易踩的坑是CommonJS依赖。老项目里如果有大量require风格的第三方包Vite需要依赖originjs/vite-plugin-commonjs或者vite-plugin-require这类插件来兼容。另外一些老牌UI库可能需要手动配置optimizeDeps.include否则冷启动时会报outdated optimize dep之类的警告。我的建议是新项目直接Vite老项目不要为了追新而强行迁移除非开发体验已经严重拖后腿。用Webpack的先把splitChunks、Brotli、缓存这些配置做到位收益同样可观。5. 高负载场景Worker上传、微前端、内存占用的实战应对5.1 大文件上传为什么一定要用Web Worker上传大文件比如视频、压缩包时主线程经常卡顿。原因不只是网络传输还在于文件分片前需要计算MD5等哈希值一个几百MB的文件做完整性校验在主线程里跑几秒钟页面就会卡死用户连进度条拖都拖不动。正解就是把耗时的哈希计算放到Web Worker里去。文件读取用File.slice()切成多个分片然后worker负责逐块计算hash主线程只负责调度和展示进度条。// main.js const worker new Worker(/upload-worker.js); // 主线程把文件切片交给worker const file fileInput.files[0]; const chunkSize 2 * 1024 * 1024; // 2MB一个分片 const chunks []; for (let i 0; i file.size; i chunkSize) { chunks.push(file.slice(i, i chunkSize)); } worker.postMessage({ type: calculateHash, file, chunks }); // 监听进度 worker.onmessage (e) { if (e.data.type progress) { // 更新进度条 } };Worker里计算完hash后再把分片依次上传到服务端每个分片都有独立的序号和hash值服务端校验之后可以合并。这个方案还天然支持断点续传——已经上传过的分片直接跳过。这套实现的核心思路是把重活挪出主线程。只要遇到计算密集型任务第一反应就应该是Worker而不是在主线程里硬扛。5.2 qiankun微前端的性能代价与预加载策略如果你在用qiankun做微前端也会碰到性能优化问题。微前端的好处是应用独立发布、独立部署但代价是应用切换时有额外的解析和执行成本。子应用的JS和CSS总量可能比单体应用还多每次切应用都要重新加载、执行沙箱逻辑。qiankun的性能优化我实际用下来有效的手段有三个开启预加载start({ prefetch: true })在浏览器空闲时提前加载其他子应用的资源切换时几乎秒开公共依赖做成external多个子应用都用了同一个React或Vue版本通过CDN加载一份避免每个子应用打包一份减少沙箱开销子应用尽量不在运行时创建全局变量这样沙箱代理的开销会小一些。需要注意预加载虽好但不能无脑全量预加载。如果你的子应用很多预加载所有资源反而会让首屏带宽被抢占。我一般会在用户登录后、主应用稳定了再手动loadMicroApp加载用户最可能访问的一两个子应用。5.3 前端内存泄漏的排查与跨领域优化思维前端内存泄漏的问题在单页应用里特别隐蔽因为它不像崩溃那样明显而是页面越用越卡。常见的泄漏来源有这些全局事件监听器没有移除、setInterval/setTimeout没有清理、组件销毁但echarts实例还在、闭包引用了大对象、DOM节点被JS变量引用导致无法回收。排查方法我推荐用Chrome DevTools的Performance面板记录一段操作然后看内存曲线。如果操作后内存没有回落到操作前的水平基本就是有泄漏了。更精确的做法是用Memory面板做Heap snapshot对比操作前后的对象快照找出那些没被回收的对象。这里有一个很有意思的点优化思维是跨领域通用的。前阵子看人讨论Julia的性能优化与内存管理还有Oracle SQL的性能优化本质上都是在回答同一个问题——资源花到哪里去了有没有浪费前端的内存泄漏排查和排查一条慢SQL、一次Julia的内存抖动思路其实一模一样先度量定位再消除浪费最后验证结果。所以做前端优化久了你会发现自己看问题的视角变宽了。前端这一块给一个最实际的经验在SPA的路由切换钩子里统一销毁资源。比如Vue的onUnmounted里removeEventListenerReact的useEffectcleanup函数里调用echarts.dispose()。把这些收尾动作做成规范能消灭大部分内存泄漏问题。6. 优化完不是终点监控、预算和防回归6.1 用web-vitals做真实用户性能采集优化做完了怎么保证它不反弹答案是建立监控。现在业界最方便的采集方式是用web-vitals这个npm包它封装了PerformanceObserver几行代码就能上报Core Web Vitals指标import { onLCP, onCLS, onINP } from web-vitals; onLCP((metric) { reportToMonitor(LCP, metric.value); }); onCLS((metric) { reportToMonitor(CLS, metric.value); }); onINP((metric) { reportToMonitor(INP, metric.value); });上报接口可以打到你自己的监控平台也可以接入市面上成熟的前端监控服务。关键是把数据按页面、版本、网络类型分组这样你才能知道优化效果在哪些条件下有效、哪些条件下失效。6.2 CI里卡Lighthouse性能预算只有监控还不够因为监控发现问题的时候用户已经受到影响。更主动的做法是在CI流程里加一道关卡每次构建后自动跑一次Lighthouse性能得分低于阈值就直接拦截不让合并。比如你可以在package.json里配上lighthouse-ci相关命令在CI流水线里预设一个性能预算LCP小于2.5秒、CLS小于0.1、性能分不低于90。跑不过就不放行。这样性能问题在合入主分支之前就被拦住了而不是上线后被用户教育。6.3 一次线上复盘优化成果是怎么被毁掉的我印象最深的一次线上事故和性能优化直接相关我们团队花了两周把首屏LCP从3.5秒优化到了1.8秒结果一个月后指标悄悄涨回了3.0秒用户投诉量也上来了。复盘的时候发现原因有三个一是某个业务同学为了赶需求直接在首屏页面里引入了一个体积巨大的第三方SDK二是没人注意到CI跑出来的性能预算已经红了直接点击了通过三是性能监控平台虽然一直在采集数据但没有设置告警阈值指标恶化没人看到。这三条任何一个环节起作用这次性能回退都不会发生。那次之后我在团队里立了两条规矩涉及首屏链路的依赖引入必须走perf review性能告警阈值设好红了就拉群不跳过。所以性能优化这件事到后面根本不是一个技术问题而是一个工程管理问题。你要有工具、有流程、有预算还要有人在真正的指标恶化时能第一时间响应。最后聊一点个人体会做前端性能优化这几年我最大的感受是它没有一劳永逸的银弹而是一套需要持续维护的机制。你不需要一开始就掌握所有底层细节从定指标-找瓶颈-做优化-建监控这个循环开始跑通一遍之后项目的性能水平和你的优化经验都会肉眼可见地提升。等下次面试再被问你怎么做前端性能优化你就能从指标讲到网络、渲染、构建、监控讲出一个完整的实战故事了。