前端性能优化：10个让你的应用飞起来的技巧

我最早接触性能优化，不是因为追求极致体验，而是被业务方在产品验收时当场打开DevTools，指着Network面板里的红条条问：“这个页面转圈转了3秒，用户早跑了，你们前端能不能行？”

那句话挺扎心的，但也确实点醒了我一个道理：性能优化不是锦上添花，是前端的基本功。这些年我经手过大大小小不下二十个前端项目，从早期的jQuery时代一路做到Vue 3和React 18，踩过的性能坑一个比一个深，排查起来一个比一个绕。这篇文章我想把这几年真正有效、能直接落地复用的10个前端性能优化技巧整理出来，不会只讲概念，会把每个技巧背后的原理、实操步骤、以及踩坑经历都讲透。

这篇文章适合谁看？前端开发工程师、准备跳槽需要系统性梳理前端面试题里性能优化部分的同学，以及接手了老旧项目需要做性能整改但不知从何下手的同行。文章涉及的技巧基本覆盖了页面加载链路、渲染运行链路、网络请求链路和监控反馈链路四个维度，读完你可以拿着清单对照自己的项目逐项排查。

1. 优化前先搞清楚一件事：你的页面到底慢在哪

很多人在做性能优化的时候，一上来就开干：压缩图片、合并请求、加懒加载……东一榔头西一棒子。这样做的结果往往是忙活了一两周，数据面板上确实好看了一点，但用户真实体感还是卡。为什么？因为你没有先度量，就开始优化了。

做性能优化之前，一定要先搞清楚页面慢在整个链路的哪个环节。打个比方，你觉得自己做饭慢，但到底是洗菜慢、切菜慢，还是炒菜慢？不搞清楚，闷头买了一口更快的锅，问题压根没解决。

对前端来说，“慢”主要分布在三个环节：

• 加载慢：从用户输入网址到页面首屏内容渲染出来，这期间经历了DNS解析、TCP连接、TLS握手、HTTP请求、HTML解析、资源下载、JS执行等一系列步骤。
• 渲染慢：页面框架已经搭好，但交互响应迟钝，点击按钮要等几百毫秒才有反馈，滚动列表掉帧。
• 运行时慢：页面越用越卡，占用的内存持续增长，最终导致浏览器崩溃或用户不得不手动刷新。

我个人的建议是：别凭感觉判断，用数据说话。先用Chrome DevTools的Performance面板录制一段页面从加载到可交互的完整过程，重点看几个节点：白屏时间、首屏时间、可交互时间（TTI）、以及长任务的数量。再用Lighthouse跑一次，拿到性能评分和各项细分的诊断建议。

当前业界最通用的性能度量标准是Web Vitals的三大核心指标：LCP（最大内容绘制，衡量加载性能）、INP（首次输入延迟的升级版，衡量交互响应）和CLS（累计布局偏移，衡量视觉稳定性）。这三个指标直接对应了用户的加载、交互、视觉三个维度的真实体感。如果你所在团队没有现成的性能监控平台，可以先在DevTools里手动测，跑完一轮有了基线数据，才有资格谈优化目标。

关键提醒：优化前必须建立基线。没有基线数据的所谓优化，最后你既证明不了效果，也说不清自己到底干了什么。

2. 加载链路上的十个“拦路虎”：从源头砍掉无效负担

当你用度量工具摸清了页面慢在哪个环节之后，就可以动手处理了。下面这10个技巧按推荐优先级从高到低排列，是我在多个项目中反复验证过、见效最明显的做法。

2.1 代码分割：不要把整个应用的代码一次性全发给用户

很多项目的首屏慢，罪魁祸首就是一个巨大的bundle文件。拿构建工具打包出来的main.js举例，有些项目能把所有第三方库和业务代码一股脑打进一个文件里，体积轻松超过1MB甚至2MB。浏览器要下载、解析、编译、执行这整套代码，用户才能看到能交互的页面，这中间的时间成本非常大。

代码分割的核心思路是：首屏只需要加载首屏要用的代码，其他代码等用到时再加载。

以Vue 3 + Vite项目为例，最简单的做法是利用动态import实现路由级别的懒加载：

javascript复制// 优化前：一次性引入所有路由组件
import Home from './views/Home.vue'
import About from './views/About.vue'
import UserCenter from './views/UserCenter.vue'

// 优化后：按路由懒加载
const Home = () => import('./views/Home.vue')
const About = () => import('./views/About.vue')
const UserCenter = () => import('./views/UserCenter.vue')

这样改完之后，构建产物会按照路由拆分成多个小块，首屏只加载当前路由对应的代码块。我在一个后台管理项目里实测，首屏JS体积从2.1MB降到了600KB左右，白屏时间从约2.8秒降到约1秒，效果立竿见影。

但这里有个容易忽略的坑：懒加载拆分太细，会导致HTTP请求数量暴涨，尤其在没有HTTP/2的服务器环境下，多请求的握手开销反而拖慢加载。所以代码分割的粒度不是越细越好，路由级别的分割对大多数项目来说是收益和复杂度最平衡的粒度。

2.2 资源压缩与Tree Shaking：把包里的“水分”挤干净

就算做了代码分割，每个代码块内部仍然可能存在大量“水分”：未使用的依赖代码、调试日志、重复的工具函数实现等。这些水分需要靠压缩和Tree Shaking处理。

构建工具的压缩能力是基础配置，以Vite为例，生产构建会默认启用esbuild或terser进行代码压缩，这一步能减少代码中空格、注释、变量名等冗余信息。但很多项目容易忽略的是Tree Shaking的生效条件：只有ES Module语法的静态import才能被静态分析并摇掉未使用代码，CommonJS的require语法是无法被可靠摇树的。

我接手过一个老项目，所有工具函数都用module.exports = {}的CommonJS写法，改造成ES Module之后，bundle体积硬生生减掉了近30%。这里有个实用小技巧：写工具函数库时，尽量保持函数独立导出、避免副作用，让构建工具能放心摇树。

2.3 图片资源：现代格式 + 响应式尺寸 + 懒加载

图片体积往往占一个页面总资源量的50%以上。很多项目里设计师导出的图片是PNG格式，一张1920宽的大图随随便便一两个MB，用户首屏加载自然就慢了。

图片优化的具体做法分三层：

第一层，选对格式。能上WebP或AVIF就尽量上，同等视觉质量下WebP比JPEG小25%到35%，AVIF比WebP更激进，体积能再降20%左右。现在主流浏览器对这两种格式的支持已经非常成熟，老浏览器可以走<picture>标签的fallback方案。

第二层，响应式尺寸。不要给所有设备都下发同一张2倍图。用srcset属性让浏览器根据视口宽度自行选择合适尺寸的图片：

html复制<img 
  srcset="img-480w.webp 480w, img-800w.webp 800w, img-1200w.webp 1200w"
  sizes="(max-width: 600px) 480px, (max-width: 900px) 800px, 1200px"
  src="img-800w.webp"
  alt="示例图片"
>

第三层，懒加载。首屏之外的图片，等用户滚动到可视区域附近再去加载。原生loading="lazy"属性已经能覆盖绝大部分需求，一个属性就搞定，零成本。

这三层全做完，图片相关的体积通常能下降70%以上。

2.4 字体优化：字体加载对首屏的影响比你想象中大

字体是前端性能优化里最容易被忽视的盲区。很多人只关注JS和图片，完全忘了页面里可能存在好几个字体文件。中文字体动辄几MB，字体加载不到，浏览器就一直在用fallback字体渲染，等字体加载完成后又突然替换，造成FOIT（不可见文本闪烁）或FOUT（无样式文本闪烁），用户体验非常糟糕。

字体优化的核心做法是：

• 使用font-display: swap，让文本先用系统字体渲染，Web字体加载完成后再替换，避免文本长时间不可见。
• 用unicode-range只加载页面真正用到的字符子集。比如页面只有数字和英文，就不要把整套中文字体都下发。
• 考虑把常用图标从字体图标切换为内联SVG，减少字体请求的同时还要清晰。

2.5 合理的HTTP缓存策略：别让用户每次都重新下载

前端性能优化有个很反直觉的事实：对老用户来说，最大的性能瓶颈不是你服务器的响应速度，而是缓存策略不合理导致的重复下载。

正确的缓存策略是按内容类型区分对待：

这套策略跑下来，二次访问的加载时间能从秒级直接降到百毫秒级。

2.6 去除渲染阻塞资源：CSS和JS的加载顺序不是拍脑袋定的

浏览器解析HTML时，遇到<link rel="stylesheet">会阻塞渲染，遇到<script>会阻塞解析。优化顺序的基本原则是：

• 关键CSS内联：首屏渲染需要的CSS直接内联进HTML，减少一次CSS请求的往返时间。非关键的CSS（比如弹窗、折叠面板区域的样式）再异步加载。
• JS加defer或async：非首屏逻辑的JS用defer属性，让浏览器在解析完HTML之后再执行；独立互不依赖的脚本可以用async。同时把script标签尽量放在body末尾，或者干脆用动态注入的方式加载。

2.7 服务端渲染或预渲染：首屏HTML直接发给用户

如果你的应用是纯客户端渲染（CSR），浏览器收到的HTML往往是一个空壳子，里面只有一堆JS链接，页面内容全靠JS跑完之后挂载。也就是说，在JS执行完毕之前，用户看到的是白屏。

解决这个问题有两条路：一是把首屏渲染放到服务端去做，也就是SSR，用户请求页面时服务端直接返回渲染完成的HTML，首屏时间大幅缩短；二是针对静态内容为主的页面做预渲染，构建时直接把页面生成静态HTML。Vue生态的Nuxt、React生态的Next.js都是成熟的SSR框架。

但SSR不是免费的，它引入了服务端渲染成本、更好的部署复杂度。如果项目暂时不具备SSR条件，可以考虑首页局部预渲染或骨架屏方案——至少让用户感知到页面在加载，而不是白屏一片。

2.8 预加载与预连接：把浏览器空闲时间利用起来

资源加载路径上有个很经典的优化思路：让浏览器在关键任务完成后立即去预热后续要用的连接。

• dns-prefetch：提前解析目标域的DNS。
• preconnect：提前进行TCP和TLS握手。
• preload：提前加载当前页面马上要用但还没被发现的资源。
• prefetch：提前下载用户下一步可能访问页面的资源。

html复制<link rel="preconnect" href="https://api.example.com">
<link rel="dns-prefetch" href="https://api.example.com">
<link rel="preload" href="/fonts/main.woff2" as="font" type="font/woff2" crossorigin>

实际项目里有个细节值得注意：preconnect和dns-prefetch的主要区别是握手时机，但两者都是消耗浏览器并发连接资源的，不要对超过三四个域名同时启用preconnect，过多的预热反而会挤占主页面资源加载的连接额度。

2.9 接口性能优化：不仅是后端的事，前端也能做缓存

接口响应慢，很多前端第一反应是“这是后端的问题”。但换个角度想，前端其实可以做三件事来减少接口延迟的影响：

• 请求合并：多个相关的小接口合并成一个批量接口，减少HTTP往返次数。比如详情页需要用户信息、订单列表、评论数据三个接口，可以合并成一个聚合接口。当然接口合并需要后端配合，但很多情况下后端是愿意做的，只要你说清楚性能收益。
• 前端缓存：对变化不频繁的数据（如部门列表、配置字典、城市列表），用内存缓存或localStorage缓存，设置合理的过期时间，可以完全避免重复请求。
• SWR策略：界面先展示缓存数据，再在后台静默更新为用户不可感知的新数据。这个策略在列表页体验提升上效果显著。

2.10 组件懒加载与按需引入：第三方库别整包导入

最后这个技巧和代码分割一脉相承，但很多人容易忽略。以UI组件库为例，很多人是这样用的：

javascript复制// 优化前：引入整个组件库
import ElementPlus from 'element-plus'
import 'element-plus/dist/index.css'
app.use(ElementPlus)

这段代码会把组件库所有组件和样式全部打入bundle。优化后只引项目里真正用到的组件和样式，个别复杂组件到时再按需加载。现在主流的UI组件库都提供了自动按需导入插件（如unplugin-vue-components），配置一次，构建时自动做按需引入，非常省事。

以我优化过的一个中后台项目为例，按需引入 + 路由懒加载的组合拳，首屏JS体积从1.8MB降到700KB左右，用户从输入网址到可交互的时间缩短了一半多，优化的性价比非常高。

3. 加载速度搞定后，运行时卡顿才是真正的硬骨头

加载慢的问题相对好排查，打开Network面板、跑一次Lighthouse，问题基本一目了然。但运行时卡顿不一样，它是隐形的——只在用户交互的瞬间出现。这类问题排查起来最费时间，也最能体现优化功力。

一个刷新过后看起来很流畅的页面，用户操作五分钟之后就开始点击没反应、滚动掉帧、输入文字卡顿，这种体验比加载慢更致命，因为用户已经进入使用状态了。运行时性能优化，核心是减少主线程的负担。

3.1 长任务切分：别让主线程被单个大任务独占

浏览器的主线程在同一时间只能处理一件事。如果有一个任务执行时间超过50毫秒，就会被Chrome标记为长任务（Long Task），长任务会阻塞用户的交互响应，表现为点击延迟、输入卡顿。

长任务最常见的来源是：一个大循环里同步处理了大量数据、复杂的计算、大批量的DOM操作。

我遇到过最典型的场景是：一个表格组件接收了后端一次性返回的5000条数据，前端循环遍历并逐个创建DOM节点去渲染。第一次渲染过程用了几秒钟，期间页面完全卡死。优化方案是分片渲染——把一个长任务拆分成多个小的任务，让浏览器有机会穿插处理用户的输入和渲染：

javascript复制// 使用requestIdleCallback在浏览器空闲时执行分批渲染
function renderInChunks(data, renderItem, chunkSize = 100) {
  let index = 0
  
  function processChunk() {
    const end = Math.min(index + chunkSize, data.length)
    for (let i = index; i < end; i++) {
      renderItem(data[i])
    }
    index = end
    
    if (index < data.length) {
      // 每一片渲染完成后让出主线程
      requestIdleCallback(processChunk, { timeout: 1000 })
    }
  }
  
  requestIdleCallback(processChunk)
}

50毫秒这个阈值是Chrome给长任务划的标准线，浏览器会预留出足够的时间来处理渲染和用户输入。分片方案实际上是把一个大任务人为切成每片不超过50毫秒的小任务，让主线程始终有空隙响应用户的操作。

3.2 避免强制同步布局：改样式和读位置要分开

这是一个非常隐蔽但非常常见的运行时性能问题。当你先修改了元素的样式（比如改变了宽度），紧接着又读取它的offsetHeight或getBoundingClientRect等属性时，浏览器被迫提前执行一次同步布局去获取最新的几何数据。如果这段代码在循环里执行，每次循环都触发一次重排，性能灾难就发生了。

我之前优化过一个滚动加载更多的列表页，原代码在遍历每一条数据时都会读取一次容器高度来判断滚动位置，导致页面滚动卡顿。优化思路很简单：把读取操作和写入操作分开，先统一读取需要的布局数据，再统一执行样式修改。

javascript复制// 性能差：读写交替，每次循环都强制同步布局
for (let i = 0; i < items.length; i++) {
  container.style.height = items[i].height + 'px'
  const offset = container.offsetHeight  // 这里强制同步布局
  list[i].top = offset
}

// 性能好：先读后写，布局只重算一次
const offsets = items.map(() => container.offsetHeight)
for (let i = 0; i < items.length; i++) {
  container.style.height = items[i].height + 'px'
  list[i].top = offsets[i]
}

3.3 事件委托与防抖节流：减少高频事件的执行次数

前端开发里，滚动、鼠标移动、窗口resize这类高频事件是主线程压力的主要来源之一。如果每个滚动事件里都做复杂的计算，页面必然卡顿。

两个常规手段：

• 事件委托：把子元素的事件绑定统一挂到父容器上，减少事件的监听器数量。一个列表有1000个按钮，与其给每个按钮单独绑定事件，不如在列表容器上绑定一个事件处理器，通过事件冒泡原理用e.target判断具体是哪个按钮被点击了。
• 防抖和节流：防抖适合搜索框输入这种“停止输入后才触发”的场景，节流适合滚动事件这种“需要周期性执行”的场景。

javascript复制// 节流：确保函数在指定时间内最多执行一次
function throttle(fn, delay = 100) {
  let lastTime = 0
  return function(...args) {
    const now = Date.now()
    if (now - lastTime >= delay) {
      lastTime = now
      fn.apply(this, args)
    }
  }
}

// 滚动监听加上节流后，从每帧触发降为每100ms最多一次
window.addEventListener('scroll', throttle(() => {
  // 处理滚动逻辑
}, 100))

3.4 大列表的终极解法：虚拟滚动

渲染5000条DOM节点的列表，无论怎么优化事件绑定，浏览器创建和销毁这么多节点的成本都是实打实的。解决大列表渲染问题的终极方案是虚拟滚动：只渲染可视区域内的节点，滚动时动态替换内容。可视区域外的数据全部不渲染，只用一个占位容器模拟滚动高度。

我在一个数据大屏项目里用虚拟滚动处理过全量三万条数据的滚动列表，渲染性能从打开页面要卡两秒，变成滚动全程保持60帧丝滑。

现在市面上有成熟的虚拟滚动库，Vue的vue-virtual-scroller、React的react-window / react-virtualized都是社区验证过的选择。自行实现虚拟滚动的核心是：计算可视区域高度、每个列表项的高度、滚动偏移量，然后基于这三个值推导出当前应该渲染哪些数据项。踩过坑之后我的建议是——除非列表结构非常特殊，否则别自己造轮子，直接用成熟库，性能和边界处理比自己写要可靠得多。

4. 构建产物层面的“减脂”：工程化配置决定性能上限

前面讲到的大部分优化手段都是业务代码层面的，但还有一类优化必须在工程化配置阶段就做好。构建配置不合理，后面业务代码写得再优化，也弥补不了产出物的先天缺陷。

4.1 构建体积分析：先找到“你到底肥在哪里”

做任何构建优化之前，先安装rollup-plugin-visualizer（Vite项目）或webpack-bundle-analyzer（Webpack项目），打开产物体积分析图。这张图会以矩形面积的大小直观展示每个依赖包在最终bundle中占据的体积，让你一眼看出是谁在拖后腿。

我判断一个项目的性能优化空间，第一件事就是看这个分析图。有的项目优化了半天，结果一看最肥的是把整个lodash全面引入了；有的项目还塞着一个远古版本的大体积图表库。体积分析图能帮你把优化目标锁定在最高性价比的区域。

4.2 依赖库版本替换与按需引入：用更轻的库替代重量级选手

看完体积分析图，如果要优化目标很明确，常见的处理思路有：

• 大而全的工具库（如lodash、moment.js）替换成按需引入或更轻的替代品。moment.js体积约300KB且不可摇树，换成day.js（约2KB）或date-fns（按需引入）能省下大量体积。
• 图表库里面ECharts体积非常大，如果只用折线图和柱状图，可以按需注册模块，或者考虑换更轻量的方案。当然换库有迁移成本，我通常建议先按需引入压缩体积，除非项目刚起步或功能简单，才考虑换轻量库。
• 检查是否引入了重复或功能重叠的库。比如同时引入了axios和fetch封装库，同时引入了两个UI组件库，这种情况在同项目里并不少见。

4.3 CDN与HTTP/2：让资源分发和并发传输各司其职

把静态资源部署到CDN，是国内项目标配了。CDN能把资源分发到离用户最近的边缘节点，大幅降低网络传输时间。同时，如果条件允许，建议服务器和CDN都开启HTTP/2，多路复用特性允许在同一个连接上并行传输多个资源，这能部分抵消大量小文件导致的请求延迟。

资源量大的项目，配合HTTP/2的多路复用，按需拆分的小块资源也能在下载上获得接近并行的效果，这也在一定程度上支持了上面第2.1小节提到的“代码分割粒度可以更细”的做法。

CDN部署有个容易踩的坑：CDN节点的缓存策略和源站不一致，导致上线新版本后用户还拿到旧资源。解决办法是上线流程设计好版本号管理——带hash的资源文件名一更新，旧内容自然失效；不带hash的HTML文档则要设置好缓存校验头，确保每次请求都回源校验。

4.4 构建配置中的“一次性优化”清单

这里分享几个我每次接手新项目都会第一时间检查的构建配置项：

• Vite项目确认build.target是否设置合理。默认的'modules'目标兼容性更广但代码体积更大，如果团队技术栈和用户群体都支持较新的浏览器版本，可以适当调高构建目标（如es2019），让构建产物使用更现代的语法特性，体积更小。
• 确认是否开启了build.minify，并确认压缩器选择合适。
• 确认CSS是否开启代码分割和压缩混淆。
• 检查是否有未使用的全局样式文件被打入了所有页面。
• 检查define配置是否正确设置环境变量，避免生产环境打包进调试代码。
• Source map在生产环境建议使用hidden模式或直接关闭，避免对用户暴露源码，也避免额外的文件体积。

注意：构建优化往往是最快见效的一类优化。我曾经花一个下午处理完体积分析图和依赖替换，页面加载时间直接降低了40%。

5. 用Performance API建立自己的性能监控体系

前面讲的所有优化技巧做完一轮之后，真正值得投入精力的事情是建立一套能持续监控性能的体系。没有监控，就没有数据；没有数据，后续做任何优化都是拍脑袋。

浏览器原生提供了Performance API，可以直接在业务代码里采集各个性能阶段的数值，这套代码不依赖任何第三方服务和平台，可配置性极高。我自己在多个项目里都是用它来做自建监控上报。

5.1 核心指标的采集代码模板

以下是一段可以在生产环境直接使用的性能指标采集代码：

javascript复制// 在页面加载完成后执行
window.addEventListener('load', () => {
  // 使用requestAnimationFrame确保在下一帧渲染完成后采集，数据更准确
  requestAnimationFrame(() => {
    const perfData = performance.getEntriesByType('navigation')[0]
    const paintEntries = performance.getEntriesByType('paint')
    
    // 导航计时
    const tcpTime = perfData.connectEnd - perfData.connectStart
    const ttfbTime = perfData.responseStart - perfData.requestStart
    const domLoadTime = perfData.domContentLoadedEventEnd - perfData.navigationStart
    
    // 从首次绘制（FP）和最大内容绘制（LCP）中提取所需数据
    let fpTime = 0
    let lcpTime = 0
    paintEntries.forEach(entry => {
      if (entry.name === 'first-paint') fpTime = entry.startTime
      if (entry.name === 'first-contentful-paint') {
        // FCP已单独用PerformanceObserver监听
      }
    })
    
    // 上报到自己的监控服务
    reportPerformance({
      type: 'page_load',
      ttfb: ttfbTime,
      tcp: tcpTime,
      domReady: domLoadTime,
      fp: fpTime,
      url: location.href,
      time: Date.now()
    })
  })
})

5.2 用PerformanceObserver监听动态变化的指标

像LCP、CLS、INP这类可能在页面生命周期中变化的指标，需要用PerformanceObserver来持续监听：

javascript复制// 监听LCP（最大内容绘制）
const lcpObserver = new PerformanceObserver((list) => {
  const entries = list.getEntries()
  const lastEntry = entries[entries.length - 1]
  reportPerformance({
    type: 'web_vital',
    name: 'LCP',
    value: lastEntry.startTime,
    url: location.href
  })
})
lcpObserver.observe({ type: 'largest-contentful-paint', buffered: true })

// 监听CLS（累计布局偏移）
const clsObserver = new PerformanceObserver((list) => {
  let clsValue = 0
  for (const entry of list.getEntries()) {
    if (!entry.hadRecentInput) {
      clsValue += entry.value
    }
  }
  reportPerformance({
    type: 'web_vital',
    name: 'CLS',
    value: clsValue,
    url: location.href
  })
})
clsObserver.observe({ type: 'layout-shift', buffered: true })

这套代码搭建好之后，你就能在自己熟悉的监控体系里看到线上真实用户的性能数据，而不是只在开发环境里自己测。这些数据对判断优化有没有生效、功能上线后性能有没有回退至关重要。

5.3 线上性能监控数据的具体用途

搭好监控之后，数据怎么用？我给你分享三个最实务的场景：

• 上线回归：每次发版后对比新版和旧版本的核心指标分布。如果某个版本LCP中位数从2秒涨到了3秒，大概率是新增了重资源或改坏了缓存策略，可以立刻定位到原因。
• 接入告警：针对核心指标设置告警阈值，比如某日LCP均值超过标准值20%就触发告警。性能问题在发酵成用户投诉之前先被干预，这是性能监控最大的价值。
• 支撑性能优化立项：向团队或业务方申请性能优化资源时，有线上真实数据做支撑，说服力会强很多，同时也能在优化完成后用数据验证成果。

6. 那些年我踩过的性能优化深坑：一次踩坑全程复盘

文章最后，我想分享几个真实的踩坑经历。这些坑在文档里几乎查不到，但每一个都曾经让我和团队加班到深夜。

6.1 图片格式转换的“灵异事件”

有次我把一个项目的所有图片用脚本统一转成了WebP，上传到CDN后，本地测试一切正常，但线上用户反馈说大量图片显示不出来。排查了很久才发现，老代码里有一部分图片是通过CSS的background-image引用的，而CSS里的URL后缀没有同步更新，浏览器还在请求原来的.png地址。更隐蔽的是，有一个页面的图片地址是后端在下发数据时动态拼的，后端配置指向的还是老图片域，和前端CDN的WebP地址完全不搭。

这个坑让我养成了一个习惯：做图片格式优化，必须全局搜索所有引用图片的方式，包括HTML里的img、CSS里的background、JS里动态拼接的URL、以及后端数据源里的配置，还要规划好新旧资源的渐进切换方案，先灰度再全量。

6.2 懒加载导致的首屏图片闪烁

有次给一个电商项目加图片懒加载，优化完一看Lighthouse评分涨了一大截，正准备庆祝，结果用户反馈说商品图在滚动时会闪烁。排查后发现原因：loading="lazy"的图片在进入可视区域后才开始加载，而图片没有预先占位，进入区域的一瞬间图片从无到有，触发了大量CLS布局偏移，而且慢网络下用户会先看到一片灰块再突然蹦出图片，体验非常差。

正确的做法是：给图片容器设置固定宽高（或使用宽高比占位），加载中显示骨架屏或模糊占位图，加载完成后再渐显。懒加载的本质是延迟请求，不是让布局裸奔。

6.3 缓存策略把用户“锁死”在老版本

这个坑相当经典。某次上线新版本后发现用户要强刷才能看到新页面，排查之后发现是HTML文档的缓存策略配置太长。当时负责的同事直接把所有文件都配置了Cache-Control: max-age=2592000（30天），包括HTML文件。浏览器把HTML文档也缓存了30天，用户自然拿不到新版本。

正确做法是：HTML文件用no-cache策略，每次回源校验；只有带内容hash的静态资源才配置长缓存。 这是2.5小节里强调的缓存策略的关键细节，任何场景下都不应该把HTML文档也做长缓存。

6.4 不要忘记二维码扫描等特殊访问场景

还有一次是给H5页面做性能优化，优化后自己用手机浏览器打开测了几次都觉得快多了，但用户还是反馈慢。最后才发现，很多用户不是直接在浏览器输入网址访问，而是通过微信扫二维码进入页面。微信内置浏览器的WebView域名复用、缓存策略和标准浏览器差异很大，再加上扫码页面没有设置合理的缓存头，每次进入都重新下载全部资源。

这个经历之后，我把所有H5项目的验收标准加了一条：必须在真机微信、支付宝内置浏览器环境实测一遍，而不仅仅是在Chrome模拟器里测。 前端性能优化，一定要以用户真实的使用环境为准，不能只看开发环境数据。

6.5 数据上报别拖累主业务

最后一个小提醒：自己做性能监控的时候，要避免上报代码本身影响页面性能。上报请求应该做采样（比如1%的用户上报）、合并（多条指标合并为一次请求）、并且用sendBeacon或img的src触发上报，而不是用fetch阻塞业务逻辑。性能监控是为了让应用更快，不是为了让应用再多一个拖后腿的请求。

前端性能优化这条路，说到底就是跟浏览器渲染机制、网络加载链路、代码执行效率打交道的过程。它不像写一个新功能那样有明确的“完成”边界，更像是一个持续校验、持续改进的循环。最理想的状态不是某一次大优化把所有指标都改到满分，而是建立起一套方法论和监控体系，让性能问题在爆发之前就被发现、被处理。文章里这10个技巧是我挑出来的高杠杆动作，但真正让你受益的，是动手去度量、去分析、去优化的这个过程。