React与Vue性能对比实战分析

性能对比？别一上来就跑分

我做前端这几年，最怕听到的一句话就是：这个方案和那个方案比一下性能呗。听着挺合理，但真做起来坑太多了。很多人一上来就用 console.time 包个函数，跑十次取个平均值，然后说 A 比 B 快 30% —— 这种结论我一般当笑话看。

为啥？因为真实项目里根本不是这么回事。你测的可能是空数据、理想网络、本地开发环境，而线上可能是一堆副作用叠加出来的卡顿。所以我的经验是：性能对比不能只看“快慢”，要看“稳不稳”“能不能扛住真实场景”。

我的写法，亲测靠谱

我现在做性能对比，基本都用这套流程：

• 模拟真实用户行为（比如连续点击、快速滑动）
• 记录关键指标：FCP、LCP、TTFB、内存占用、主线程阻塞时间
• 多环境测试：低端机、弱网、高并发 mock 数据
• 用 PerformanceObserver 监听实际渲染表现

比如我要对比两种图片懒加载方案，不会只看谁先 load，而是看滚动过程会不会掉帧、会不会有闪烁、内存会不会一直涨。

下面是我常用的性能采集代码，已经用在好几个项目里了：

function startPerformanceMonitor() {
  const observer = new PerformanceObserver((list) => {
    for (const entry of list.getEntries()) {
      if (entry.entryType === 'paint') {
        console.log('Paint:', entry.name, entry.startTime);
      }
      if (entry.entryType === 'largest-contentful-paint') {
        console.log('LCP:', entry.startTime, 'size:', entry.size);
      }
    }
  });

  observer.observe({ entryTypes: ['paint', 'largest-contentful-paint', 'layout-shift'] });

  // 主线程阻塞监控
  const measureBlocking = () => {
    performance.mark('frame-start');
    // 强制重排触发一次 layout
    document.body.offsetHeight;
    performance.mark('frame-end');
    performance.measure('frame-blocking', 'frame-start', 'frame-end');

    const measures = performance.getEntriesByName('frame-blocking');
    if (measures.length > 0) {
      const duration = measures[measures.length - 1].duration;
      if (duration > 50) { // 超过 50ms 就算长任务
        console.warn('长任务检测:', duration);
      }
    }

    requestAnimationFrame(measureBlocking);
  };

  requestAnimationFrame(measureBlocking);
}

这段代码的核心是：你不光要看浏览器报告的指标，还得自己动手测主线程的实际压力。特别是那些看似轻量的操作，比如频繁读取 offsetHeight，积少成多就会导致严重阻塞。

启动它很简单：

if (process.env.NODE_ENV === 'development') {
  startPerformanceMonitor();
}

上线前我会在测试环境手动跑一遍核心流程，比如列表滚动 30 秒、反复切换 Tab、连续提交表单，一边看控制台输出一边记问题点。

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

下面这些写法我都见过，甚至我自己也写过，结果全翻车了。

❌ 错误一：只用 console.time 简单包裹

console.time('fetchData');
await fetch('https://jztheme.com/api/data');
console.timeEnd('fetchData');

这种写法最大的问题是：它只测了网络请求时间，但忽略了后续的解析、渲染、DOM 更新成本。更离谱的是，有些人把 await 写在外面，测出来的其实是 Promise 创建时间……

建议避开这种写法，除非你明确知道自己在测什么阶段。

❌ 错误二：在 useEffect 里疯狂打点

useEffect(() => {
  console.time('render-cost');
  // 渲染逻辑
  console.timeEnd('render-cost');
}, [deps]);

React 的 useEffect 是异步调度的，你打的时间点很可能和实际渲染对不上。而且组件多次更新时，这些日志会混在一起，根本没法分析。

正确的做法是结合 useLayoutEffect + performance.now()，或者直接上 DevTools 的 Performance 面板。

❌ 错误三：拿开发环境数据当结论

这是最气人的。有人在 M1 Mac 上测出某个库快 2 倍，就推到生产，结果安卓机上直接卡死。开发环境 CPU 快、内存足、网络好，测出来全是虚假繁荣。

我的建议是：至少找个低端 Android 手机（比如红米某款），开 Chrome 远程调试，用 Network Throttling 模拟 3G，再跑一遍测试。

实际项目中的坑

去年我们有个列表页，初期用的是 IntersectionObserver 做懒加载，看起来很现代、很高效。但上线后发现，用户滑动到底部时经常卡一下，尤其是老机型。

折腾了半天才发现，是因为同时监听了上百个 img 元素的交叉状态，导致每帧都有 JS 回调执行，主线程被占满。后来改成了“视口附近预加载 + 批量观察”的策略，才缓解。

所以我现在做性能对比，一定会关注资源规模的增长曲线。比如：

• 数据量从 10 条增到 1000 条，渲染耗时是不是线性增长？
• 组件数量变多后，内存占用有没有泄漏？
• 频繁更新时，reconcile 时间是否失控？

有时候一个方案在小数据下慢一点，但在大数据下反而更稳，这种才是生产环境真正需要的。

还有一点容易被忽视：第三方脚本的影响。比如你在对比两个轮播图组件，但如果页面同时加载了广告 SDK 或埋点脚本，测出来的数据可能完全失真。我的做法是：在纯净环境下测试，再在完整环境下验证。

别迷信“最优解”

说实话，很多性能优化到最后都是妥协。你可能找到一个理论上最快的算法，但它维护成本高、可读性差、团队没人敢动。

比如我之前试过用 Web Worker 处理大量 DOM 计算，确实快，但 debug 成本太高，改个 bug 得来回传 message，最后还是换回了普通实现 + 分片更新。

所以我的原则是：能用简单方法解决的，就不上复杂方案。只要不明显影响用户体验，稍微慢一点也没关系。毕竟我们做的是产品，不是 benchmarks。

工具推荐：别只靠肉眼看

除了手动打点，这几个工具我也常用：

• Lighthouse：生成报告方便，适合做前后对比
• Chrome Performance 面板：看帧率、长任务、GC 触发非常直观
• Webpack Bundle Analyzer：查包体积膨胀原因
• Siege / Artillery：做接口压测，配合前端行为模拟

特别提醒：Lighthouse 的分数会受网络波动影响，建议多跑几次取中位数，别盯着那根绿柱子较真。

总结一下

性能对比不是跑个分就完事了。我踩过的坑太多，总结下来最重要的是三点：

1. 测试场景要贴近真实用户行为
2. 指标要全面，不只是 JS 执行时间
3. 环境要覆盖低端设备和弱网情况

以上是我个人在多个项目中踩坑后的总结，希望对你有帮助。有更好的方案或不同看法，欢迎评论区交流。