前端性能优化实战：从加载速度到渲染效率的全面提升

我的写法，亲测靠谱

做前端这几年，性能优化从“锦上添花”变成了“上线必过”。我一开始也以为加个懒加载、压缩下图片就完事了，结果线上一跑，Lighthouse 分数还是 40 多，用户反馈“卡得像幻灯片”。折腾了几个项目后，才慢慢摸出点门道。今天不讲理论，就说说我实际怎么干的。

最核心的一条：**别等上线再优化，开发阶段就得埋点监控**。我现在新建项目第一件事，就是在关键路由里加 Performance API 的打点：

// 在路由切换或组件挂载时记录
const markName = 'page-load-start';
performance.mark(markName);

// 数据加载完成或渲染结束时
performance.measure('page-load-duration', markName);

本地跑 dev server 时看不出问题，但一上真机，网络延迟、低端机 JS 执行慢的问题全暴露了。有一次我在 iPhone 6 上测一个商品详情页，光解析 JSON 就花了 800ms，因为后端返回了 3MB 的嵌套数据（里面还带了整站的分类树）。这种问题，光靠 DevTools 模拟根本发现不了。

这几种错误写法，别再踩坑了

很多人一说性能优化，立马想到防抖节流。但用错了反而更糟。比如下面这种“万能防抖”：

// 错误示范：给所有事件无脑加 debounce
window.addEventListener('scroll', debounce(handleScroll, 300));

结果页面滚动直接卡成 PPT。为什么？因为 debounce 会把连续触发的事件攒到最后才执行一次，中间完全没响应。滚动这种需要即时反馈的操作，应该用 throttle 或者直接用 requestAnimationFrame：

// 正确做法：用 rAF 控制帧率
let ticking = false;
function handleScroll() {
  if (!ticking) {
    requestAnimationFrame(() => {
      // 实际滚动处理逻辑
      updateStickyHeader();
      ticking = false;
    });
    ticking = true;
  }
}
window.addEventListener('scroll', handleScroll);

另一个高频翻车点是图片懒加载。很多人直接用 getBoundingClientRect().top < window.innerHeight 判断是否进入视口，但在低端安卓机上，这个计算本身就很耗。更糟的是，如果页面有大量图片，每次滚动都遍历所有 img 元素，主线程直接被拖垮。

我的方案是：**优先用原生 loading="lazy"，兼容性不够再上 Intersection Observer**。而且一定要记得断开监听：

const imageObserver = new IntersectionObserver((entries, observer) => {
  entries.forEach(entry => {
    if (entry.isIntersecting) {
      const img = entry.target;
      img.src = img.dataset.src;
      observer.unobserve(img); // 关键！加载完就取消监听
    }
  });
});

document.querySelectorAll('img[data-src]').forEach(img => {
  imageObserver.observe(img);
});

实际项目中的坑

去年做了一个数据看板项目，图表多、实时更新频繁。一开始用 setInterval 每秒拉一次数据，结果内存占用蹭蹭涨，Chrome DevTools 里看到大量 detached DOM 节点。排查发现，组件卸载时没清理定时器，旧的回调还在不断操作已销毁的 DOM。

现在我强制自己遵守一条铁律：**任何副作用（定时器、事件监听、订阅）必须在组件卸载时清理**。React 里用 useEffect 的 return，Vue 里用 onBeforeUnmount，原生 JS 就手动管理：

// 原生 JS 示例
function setupComponent() {
  const timer = setInterval(fetchData, 5000);
  
  // 返回清理函数
  return () => {
    clearInterval(timer);
  };
}

// 使用时
const cleanup = setupComponent();
// 组件销毁时调用
cleanup();

还有个隐蔽的坑：CSS 动画性能。曾经为了一个“酷炫”的 hover 效果，用了 transform: scale(1.1) + box-shadow，结果在 Macbook Pro 上丝滑，到了 Surface Go 上直接掉帧。后来才知道，box-shadow 会触发 Paint，而低端设备 GPU 带不动。解决方案很简单：**动画只用 transform 和 opacity**，这两个属性能走合成层，不触发重排重绘。

/* 安全的动画写法 */
.button {
  transition: transform 0.2s, opacity 0.2s;
}
.button:hover {
  transform: scale(1.05);
  opacity: 0.9;
}

顺便提一句，别迷信 Webpack 的代码分割。我见过有人把每个组件都 React.lazy，结果首屏加载时发了 20+ 个小 chunk 请求，HTTP/1.1 下反而更慢。现在我的策略是：**首屏关键路径合并打包，非首屏路由级拆分**。用 Webpack Magic Comments 标注：

const Dashboard = React.lazy(() => import(
  /* webpackChunkName: "dashboard" */ './Dashboard'
));

改完后仍有一两个小问题，但无大碍

说实话，性能优化没有银弹。我最近一个项目用了 SWR 做数据缓存，理论上能减少重复请求，但发现某些接口缓存失效后，多个组件同时触发 revalidate，瞬间发出 5 个相同的请求。官方 issue 里说这是预期行为（stale-while-revalidate 的副作用），最后我只能在外层包一层 debounce 的 fetcher 函数。

还有 Lighthouse 的“避免巨大的 network payload”建议，经常让人头疼。图片压缩到极限了，JS 也做了 tree-shaking，但分数还是不高。后来发现是第三方 SDK 搞的鬼——一个小小的埋点库居然带了 200KB 的 polyfill。现在我会用 webpack-bundle-analyzer 定期检查依赖体积，大而无用的库直接砍掉。

对了，别忘了服务端配合。前端再怎么优化，如果 API 返回 5MB 的 JSON，照样白搭。我和后端约定了字段裁剪规则，比如列表页只返回 id/name，详情页再拉完整数据。接口地址类似这样：

// 列表页
fetch('https://jztheme.com/api/products?fields=id,name,price');

// 详情页
fetch('https://jztheme.com/api/products/123');

以上是我踩坑后的总结，希望对你有帮助

性能优化是个持续过程，没有一劳永逸的方案。我的经验是：**先用工具定位瓶颈（Lighthouse / Performance tab），再针对性解决，别瞎猜**。有时候花两天优化一个 10ms 的问题，不如花两小时砍掉一个 500KB 的无用依赖。

以上是我个人对性能优化的实战总结，有更优的实现方式欢迎评论区交流。这个话题能聊的还有很多，比如 Web Worker 分担计算、Service Worker 缓存策略，后续会继续分享这类博客。