前端性能优化这个话题我在团队内部讲过很多次每次讲完都觉得还能再展开不少。最近接了一个业务线的性能专项把从前端资源加载到交互流畅度这条链路重新捋了一遍顺手把过程中的经验和踩过的坑整理下来。这篇文章适合两类人看一类是刚开始接触性能优化的新手可以通过它建立整体认知避免东一榔头西一棒子另一类是已经在做优化的老手可以用这篇文章当一份检查清单看看有没有漏掉的关键点。我会尽量用实际工作中遇到的场景来说不讲学院派空话希望读完你就能按图索骥去排查自己的项目。1. 性能优化的底层逻辑先看浏览器是怎么干活的很多朋友一提到性能优化第一反应就是压缩图片开个缓存加个CDN这些操作本身没错但如果没有理解浏览器的工作流程就只能停留在别人说这样能优化的阶段遇到问题依然无从下手。这一章先把底层的运行机制讲清楚后面的所有手段都会回到这条主线上来。1.1 从输入网址到页面出现浏览器经历了什么一次普通的页面访问浏览器要做的事远比你想象得多。输入网址后要先做DNS解析把域名转成IP然后建立TCP连接接着发送HTTP请求、等待响应拿到HTML后开始解析文档边解析边构建DOM树和CSSOM树两棵树合并成渲染树之后浏览器要计算每个节点的几何位置完成布局然后把像素画上去最后还要经过合成才显示到屏幕上。如果用做菜来类比DNS解析相当于查清楚菜谱放在哪个书架上TCP连接相当于提前把火生好HTML解析相当于备菜CSSOM的构建相当于确认调味料配比布局相当于设计摆盘位置绘制才是真正下锅翻炒。任何一个环节慢了上菜时间都会受影响。理解了这条链路之后再看各种优化手段就会清晰很多有些优化是针对传输环节的比如CDN和HTTP缓存有些是针对解析构建环节的比如减少阻塞脚本有些是针对渲染绘制环节的比如减少重排重绘。它们各管一段互不冲突需要根据页面的实际情况组合使用。1.2 两个方向和一个顺序建议性能优化虽然手段繁多但归纳起来就是两个大方向一个是让页面更快地到达用户解决的是加载速度问题一个是让页面在用户操作过程中保持流畅解决的是交互体验问题。前者的核心指标是FCP、LCP、TTFB后者的核心指标是INP、CLS和长任务数量。我的建议是动手优化之前先花半天时间做两件事第一把页面当前的真实性能数据测出来用Lighthouse或者浏览器自带的Performance面板都可以第二把最近一个月的线上性能监控数据拉出来看找出趋势变化和异常点。有了数据再决定先优化哪个环节不要凭感觉挑几个看起来很高深的技巧硬上。我自己见过不少项目优化方向搞反了。有个页面布局抖动得很厉害团队却先去换图片格式结果收益微乎其微真正的问题在于列表渲染时不断修改DOM高度导致频繁重排。方向不对再努力的优化都是白费力气所以顺序建议放在所有手段之前。1.3 用指标替代感觉判断性能好不好不能靠感觉还行得有一组可量化的指标。现在业界比较公认的核心指标主要有这么几个指标全称衡量内容健康参考值FCPFirst Contentful Paint首次内容绘制页面出现第一个内容的时间小于1.8秒LCPLargest Contentful Paint最大内容绘制首屏最大元素出现的时间小于2.5秒CLSCumulative Layout Shift累积布局偏移页面元素意外移动的程度小于0.1INPInteraction to Next Paint交互到下一次绘制的延迟衡量交互响应小于200毫秒TTFBTime To First Byte首字节时间服务器响应速度小于800毫秒我自己在实际工作中最关注的就是LCP和INP一个管用户第一眼的感受一个管用户接下来所有操作的顺滑度。CLS也别忽视那种正要点按钮按钮突然跑了的体验比加载慢更劝退人。这些指标不需要每时每刻盯着看但优化前后一定要有对比数据。每个优化手段我都会在文章里顺带说明它对哪个指标的影响最大方便你对照判断。2. 加载链路上的优化网络开销怎么省加载速度的优化是性能优化里收益最直接的部分。用户访问一个页面除了等待服务器处理请求剩下的时间基本都花在网络传输上。把传输的东西变少、路径变短、次数变少加载自然就快了。这一章按照减体积、加缓存、短路径、延加载四个思路展开。2.1 资源体积是第一道关口压缩与图片选型先说最基础也最容易被忽视的资源体积。JavaScript和CSS在打包构建阶段就应该做压缩和混淆这一步现代构建工具默认都会做。但有些项目因为历史原因线上还跑着未压缩的脚本这就很离谱了。建议在构建配置里开启压缩插件去掉console输出和注释生产环境的脚本体积能减少不少。真正差距大的是图片。很多页面的总重量里图片占了大头。我接手的一个活动页面首屏三张横幅图加起来有2MB换用WebP之后直接降到900KB左右。图片格式选型上普通照片用JPEG过渡要求高的直接用WebP支持更好就上AVIF。WebP在同样画质下比JPEG小30%左右AVIF比WebP还能再小一些但AVIF的解码成本更高移动端低端机上要慎用。文本资源也不要放过Gzip和Brotli压缩。服务端开启Brotli后JavaScript和CSS这类文本资源通常能比Gzip再小15%到20%。第一次做这个优化的时候光开启压缩整个页面资源包从1.2MB降到了400KB出头用户体感完全是两个页面。给静态资源做压缩的性价比极高改动小、收益大值得作为优化优先级最高的任务之一。2.2 HTTP缓存让重复访问不再花钱网络传输再好都不如网络传输不发生。HTTP缓存就是解决这个问题的核心手段它的核心价值是让用户在第二次访问时能直接复用第一次下载的资源。强缓存让浏览器在缓存有效期内直接使用本地副本不再发请求到服务器。生产环境的静态资源要配好Cache-Control对于带内容哈希的文件名可以放心地把max-age设得很大甚至用immutable对于HTML页面本身则不要长缓存否则页面更新了用户看到的还是旧版本。协商缓存的原理是浏览器带条件请求到服务器服务器对比资源的修改时间或ETag没变化就返回304只传响应头不传响应体。这个机制的收益在于即使缓存过期了验证成本也远小于重新下载完整资源。这里要特别说一下内容哈希的作用。文件名里带上文件内容的哈希内容不变文件名就不变浏览器可以安心长缓存内容变了文件名就变了浏览器自然请求到新资源。这个机制是现代前端工程化缓存策略的核心。理解了它你就知道为什么每次发版后大部分静态资源都不用等用户强制刷新新用户拿到的永远是匹配版本的文件。2.3 CDN、预解析、预连接缩短网络路径资源体积降下来之后接着要解决的是网络路径问题。CDN的核心思路是把静态资源分发到离用户更近的边缘节点让用户从邻居家拿东西而不是每次都回老家扛。对跨地域用户比较多的站点来说CDN带来的加载提升非常明显特别是静态资源这类不常变化的文件。除了CDN还有一些零成本的链路加速手段写在HTML的head标签里就能生效。dns-prefetch可以在浏览器空闲时提前解析后续要访问的域名preconnect比dns-prefetch更进一步提前完成DNS解析、TCP握手和TLS协商preload用于当前页面马上要用到的关键资源prefetch用于用户未来可能访问的页面资源。这几者的区别用大白话说就是preload是我马上要用你先准备好prefetch是我以后可能用你有空再拿preconnect是我知道要去哪家店先把路探好。实际使用中字体文件、首屏大图、关键脚本适合preload下一页面的入口脚本适合prefetch跨域的资源接口域名适合preconnect。注意不要把所有资源都加preload那样反而会让关键资源和其他资源争抢带宽得不偿失。2.4 懒加载的收益和反例懒加载是一个经常被误解的优化手段。它的本质是让不在视口内的资源延迟加载从而减少首屏的网络请求量。图片懒加载可以用原生loadinglazy属性兼容性已经很好更精细的控制可以交给IntersectionObserver来监听元素何时进入视口。但懒加载有一个非常典型的大坑首屏LCP元素绝对不能懒加载。我就见过团队给首屏最大的商品主图加了loadinglazy结果LCP从2秒直接变成4秒。因为懒加载会让最大内容延后出现而LCP恰恰统计的就是这个元素出现的时间。懒加载体现在长列表、图片流这类场景才有意义不要无差别乱加。还要提醒一点图片不管懒不懒加载都要提前把宽高占住。不加宽高会导致图片加载完成后下方内容突然被顶开CLS直接爆表。要么在img标签上写死width和height属性要么用aspect-ratio配合容器宽度撑开比例。这两种方式都能给浏览器预留空间避免加载过程中的布局跳变。提示优化的第一原则是减少必须做的事第二原则才是让必须做的事更快。懒加载属于第一原则缓存和压缩属于第二原则两者配合使用不要本末倒置。3. 渲染阶段的优化页面怎么被画出来资源加载完之后浏览器开始解析、构建、渲染。这个阶段很多问题都出在浏览器主线程上主线程既要执行JavaScript又要计算样式、布局、绘制任务太多就会拥堵。这一章重点讲怎么减少渲染链路上的阻塞。3.1 关键渲染路径上的阻塞控制脚本加载时机HTML解析过程中遇到普通script标签会停下来先下载再执行脚本执行完才继续解析。这就是脚本阻塞渲染的原因。优化思路很简单要么让脚本晚点执行要么让它异步执行。async和defer是最常用的两个属性。async是下载完立即执行不保证执行顺序适合完全独立、不依赖其他脚本的代码defer是等HTML解析完成后按顺序执行适合依赖DOM操作或者有执行顺序要求的脚本。对于页面首屏而言不需要立即执行的脚本都应该用defer而不是默认同步加载。CSS也会阻塞渲染。浏览器只有把CSSOM构建完成才会进行渲染所以在CSS文件到达之前页面对用户是不可见的。这也是为什么关键CSS要内联到HTML里的原因首屏能看到的样式要尽量减少对额外网络请求的依赖。换个角度理解首屏的CSS是必需品应该跟HTML一起到达首屏之下的CSS可以由脚本动态加载不用拖慢初始渲染。我在实际项目里见过这样一个场景某个页面首屏只需要一个活动横幅却引入了完整的全局样式文件里面有大量用不到的组件样式。把首屏关键样式抽出来内联之后虽然只省了一次往返请求但FCP从2.8秒降到了1.9秒因为我让第一次渲染不再等那个300KB的CSS文件了。3.2 CSS优化从选择器到渲染容器CSS优化往往不是项目里的第一优先级但有些细节确实能减少渲染成本。选择器这块不要写那种过分复杂的选择器组合浏览器匹配元素的时候是从右往左匹配的标签选择器和通配符后面连着长串限定条件的写法匹配成本会明显上升。日常开发用类名搭配语义化的结构就够了。有一个很好用的CSS属性值得特别提一下content-visibility。长页面里视口外的区块渲染成本其实是可以省掉的。给这些区块加上content-visibility: auto浏览器会跳过它们的主渲染工作滚动到附近时才渲染。配合contain-intrinsic-size给元素一个预估尺寸可以避免滚动条跳动的问题。这个属性对长列表、长文档类页面收益很明显我试过的第一个版本页面整体渲染时间降了将近一半代价只是几行CSS。还有一点不要用import加载CSS文件。import会让CSS的加载变成串行依赖增加额外的往返请求。没有特殊理由全部用link标签加载。这是行业里公认的规范但总能在老项目里看到import出现值得复查一遍。3.3 重排与重绘布局抖动从哪来布局抖动是交互卡顿最常见的原因之一。要理解它先要分清重排和重绘的区别。重排是元素几何尺寸或位置变化后浏览器要重新计算布局重绘是元素外观变化后重新画像素但不影响布局。重排的代价远高于重绘因为它可能影响一大片元素的位置。动画场景里尽量用transform和opacity这两个属性可以通过合成器处理不触发重排也不触发重绘性能最好。用top/left做位移动画会让浏览器每一帧都去重新计算布局低端机上卡顿非常明显。这个优化我做过直接的对比测试同一个悬浮动画用top/left时低端机上掉帧明显改成transform后稳定60帧差距肉眼可见。还有一个特别隐蔽的性能杀手强制同步布局。如果你在脚本里先读取了一个元素的offsetHeight紧接着又修改了这个元素的height属性浏览器为了给你返回正确的offsetHeight被迫提前执行一次布局计算。这种模式在循环里出现时每轮迭代都触发一次全局布局性能直接崩掉。正确做法是读写分离先统一读取所有需要的数据再统一修改样式或者用requestAnimationFrame把写操作调度到下一帧。will-change属性可以提前告诉浏览器某个元素要变化把它提升到独立图层但这个属性不能滥用。每个独立的合成图层都会占用GPU内存几十个图层叠加会让移动端扛不住。常规做法是只有动画持续期间才加上动画结束后移除。滥用will-change造成内存压力过大的问题比不用它的问题更难排查因为现象是卡顿原因却在图层数量上。3.4 首屏体验组合拳骨架屏、预渲染与字体策略首屏加载的体验优化是一个组合场景。网络再快渲染总需要时间这时候给用户一个反馈很重要。骨架屏用灰色占位块勾勒出页面的布局结构让用户知道页面正在加载比白屏友好得多。实现方式可以是静态模板、服务端渲染的占位片段也可以是一个独立组件。注意骨架屏的宽高要和真实内容接近否则内容渲染出来后布局跳变骨架屏反而拉高CLS。更彻底的做法是预渲染或服务端渲染。对于一个内容型页面在构建时生成静态HTML用户首屏拿到的就是完整的DOM脚本执行只负责后续交互的增强LCP会有非常显著的变化。这个方案对部分内容站来说比在前端做一百个优化都更管用因为首屏HTML本身就是内容的最终形态。字体加载也要处理好这个坑很多团队都踩过。默认行为下字体文件加载期间文字会隐藏页面看起来一片空白。正确做法是给font-face加上font-display: swap文字先用系统字体显示Web字体就绪后再替换。如果对视觉一致性要求不是极高甚至可以使用font-display: optional浏览器可以跳过Web字体直接使用系统字体完全不阻塞渲染。再配合preload预加载字体文件可以把字体替换的闪动时间压到最小。4. JavaScript执行阶段如何保持交互流畅加载再快、渲染再顺脚本一旦把主线程占满页面一样卡成PPT。JavaScript执行阶段的优化核心目标就是让主线程随时有空闲能够及时响应交互。这一章从代码分割、长任务调度、事件与内存三个层面来拆解。4.1 代码分割只加载当前需要的用户访问首页不应该把整个应用几十个路由的代码全部下载下来。动态import()是现代前端工程标配的拆包手段把代码按路由、按组件、按实际使用时机拆成多个chunk用到再加载。拆包的方式非常直接以前可能是这样写// 原来无论是否用到全部打进主包 import { ChartModal } from ./components/ChartModal;这样的代价是用户只是浏览列表页也要下载图表弹窗的整套代码。优化后可以改成点击时才加载对应模块// 优化后点击时才加载对应模块 async function openChartModal() { const { ChartModal } await import(./components/ChartModal); modalRef.current new ChartModal(); modalRef.current.open(); }我接手的一个后台系统所有图表组件都在主包里主包1.6MB。改成动态import之后主包直接缩到600KB以下首屏加载时间从5秒多降到2秒出头。拆包的收益在没有做过的项目里总是被低估。公共依赖的处理上把长期不怎么变化的第三方库单独拆成一个vendor包利用长缓存让用户只下载一次。注意vendor包不要无脑放太多库否则一个库升级会导致整个vendor缓存失效反而波动更大。4.2 长任务与主线程调度浏览器的主线程是单线程的JavaScript任务执行期间页面的渲染和响应都被阻塞。一个超过50毫秒的长任务就意味着用户可能感知到一次卡顿。长任务堆积越多页面无响应的风险越大。遇到那种非做不可的大计算任务比如前端导出大数据表格、图片批量处理不要在一个同步循环里跑完所有逻辑。把大任务拆成小任务每一段执行后主动让出主线程让浏览器有机会处理用户交互和渲染。// 伪代码时间切片处理大数据任务 const allItems getLargeArray(); function processInChunks(items, totalChunks 4) { const chunkSize Math.ceil(items.length / totalChunks); let currentIndex 0; function processChunk() { const end Math.min(currentIndex chunkSize, items.length); for (let i currentIndex; i end; i) { processItem(items[i]); } currentIndex end; if (currentIndex items.length) { // 让出主线程浏览器插入渲染或交互处理 requestAnimationFrame(processChunk); } else { onFinish(); } } requestAnimationFrame(processChunk); }requestIdleCallback也可以用来处理优先级低的任务它会在主线程空闲时执行回调适合做上报、清理这类不影响核心体验的工作。不过这个API的兼容性和执行时机在不同浏览器里表现不一致依赖它的重要逻辑要自己写降级方案。再往深一层说现在主流框架都在往并发渲染的方向走把渲染工作切成可中断的单元在主线程繁忙时让出控制权给更高优先级的交互更新让路。理解这个背后的时间切片思想其实比追着框架特性跑更有价值因为你会发现主流框架优化的还是同一个问题主线程资源有限必须分优先级使用。4.3 事件与内存打好日常基本功交互卡顿不一定都是计算量大有时候是基本功没做到位。事件委托值得养成习惯。页面上几十个列表项每个都绑定click事件不如在列表容器上绑一个利用事件冒泡分发。减少监听器数量既能提升初始化的速度也能降低内存占用对长列表尤其是动态列表的收益很明显。高频事件要记得做节流和防抖。滚动、拖拽、窗口resize这些事件一秒能触发几十次如果不做限制事件处理函数也会跟着执行几十次频繁触发布局和绘制页面自然卡。// 节流固定时间内只执行一次 function throttle(fn, interval 200) { let last 0; return function(...args) { const now Date.now(); if (now - last interval) { last now; fn.apply(this, args); } }; } // 防抖事件停止触发一段时间后才执行 function debounce(fn, delay 300) { let timer; return function(...args) { clearTimeout(timer); timer setTimeout(() fn.apply(this, args), delay); }; }注意节流和防抖不是同一个东西。滚动条位置更新用节流合适因为它需要持续反馈但可以降低频率搜索框联想建议用防抖合适因为要等用户停顿下来再发起请求。内存泄漏是交互流畅度的隐形杀手。最常见的三个来源setInterval或setTimeout没有清理、事件监听器绑定后没有解绑、全局变量里保存了不断增长的数据。页面长时间运行后内存持续上涨最后就是卡顿和崩溃。排查内存泄漏用浏览器性能面板做堆快照连续做几次同样的操作对比内存曲线是否有持续攀升且不回落的情况。这个排查方法基本能定位出泄漏源在哪个模块。5. 数据监控与问题排查让优化可持续做了前面的优化只是完成了一半。优化效果怎么量化、线上问题怎么持续发现、后续性能怎么防止回退这是另外一半。没有数据和机制支撑的优化很容易回归原样。5.1 建立性能基线Lighthouse和Performance API开始优化之前先跑一次Lighthouse把性能、可访问性、最佳实践、SEO的得分记录存档。Lighthouse的好用之处是报告会直接给出量化数据和改进建议可以直接当成诊断报告用。不过它模拟的移动端网络环境偏弱更多是用来做相对对比看优化前后得分的相对变化。线上真实用户数据可以通过Performance API采集。performance.getEntriesByType(navigation)里有很多加载相关的时间点PerformanceObserver可以监听更多指标// 采集LCP等核心指标的真实用户数据 const observer new PerformanceObserver((list) { for (const entry of list.getEntries()) { if (entry.entryType largest-contentful-paint) { // 上报到自己的监控系统 report(LCP, entry.startTime); } } }); observer.observe({ type: largest-contentful-paint, buffered: true });浏览器性能面板是排查具体问题时必不可少的工具。录制一段交互过程通过火焰图看主线程上每个任务的耗时分布哪一段代码是瓶颈一目了然。网络面板看资源的体积、加载时序和缓存命中情况排查加载问题非常顺手。两个面板配合使用基本能定位绝大多数前端性能问题。5.2 关键场景排查速查表实际排查问题的时候很多时候不是从头分析而是根据现象快速定位方向。我把日常最常见的几类性能问题整理成了一张速查表现象可能原因优先检查方向白屏时间过长渲染阻塞脚本、首屏CSS未内联、网络太慢网络面板看HTML和TTFB检查首屏script是否使用defer首屏元素出现太晚LCP资源加载慢或被懒加载确认LCP元素是否被加懒加载用preload优先加载关键资源滚动或点击卡顿长任务过多、布局抖动Performance录制看主线程长任务和布局事件分布页面元素突然跳动图片没占位、字体加载导致布局变化检查图片宽高、font-display设置、广告位高度预留内存持续上涨定时器未清理、事件监听遗漏堆快照对比、检查全局引用和闭包图片加载缓慢格式体积大、未走CDN网络面板看单图体积换WebP或AVIF、接入CDN这张表不能覆盖所有场景但覆盖了日常遇到的八成问题。拿着现象去对照方向再用工具去验证细节排查效率远高于漫无目的地翻代码。排查完之后把现象和结论记录到项目文档里下次再遇到类似问题可以直接查时间能省一大半。5.3 防止性能回退性能预算与日常习惯性能优化最尴尬的事情是优化完过两个月又被人改回去了。新需求进来开发者顺手往主包塞了几百KB的依赖新图片上传没压缩就直接替换。性能回退几乎是必然的除非有机制防住。我的做法是建立性能预算。在构建产物上检查主包体积超过阈值就报警超过限制直接让构建失败。指标方面如果是大团队可以把LCP、CLS这类核心指标接入线上监控超过阈值触发告警。小团队实现不了那么重的体系至少每个月跑一次Lighthouse把得分趋势记录下来回退早点发现。更重要的是把优化意识变成日常开发的一部分。提交代码的时候想一想新引入的依赖体积是否合理UI同学切图的时候提醒压缩后再上传做首屏需求的时候先问一句这个模块能不能异步加载。我自己的体会是性能优化与其说是一次技术专项不如说是一种长期养成的工程习惯。它不需要你掌握多么冷门的技巧真正难的是持续地在意、持续地观测、持续地改进。把这一套思维固化到日常流程里比任何一次集中攻坚都更有价值。最后再分享一个小技巧每次性能优化动工之前先在项目根目录建一个performance.md记录当前的基线数据、待优化清单、每项改动后的前后对比。这个文件既是你的工作日志也是后续接手人的导航图。我靠这个简单的文档让好几个项目的性能优化工作从一次性活动变成了可持续流程每次新需求评审时翻一翻很多性能问题在源头就避免了。