前端日志上报实战总结：从踩坑到优化的全过程分享

优化前：卡得不行

前几天接到一个需求，要在我们项目里加个日志上报功能。本来以为很简单，结果一上线，性能直接崩了。用户反馈说页面加载慢，操作卡顿，简直卡得受不了。

找到病颈了！

为了解决这个问题，我先用Chrome的开发者工具看看哪里出了问题。打开Performance面板跑了一遍，发现有几个请求特别耗时，尤其是日志上报的部分。再一看Network面板，发现日志上报的请求频率特别高，每次请求的数据量也不小。

于是开始怀疑是不是因为日志上报的频率太高导致的。又试了几种方案，比如减少上报频率、批量上报等，但效果都不太理想。

优化后：流畅多了

最后这个效果最好：把日志上报改为异步并且进行批量处理。这样既能保证日志数据的完整性，又能大大减少请求次数和请求时间。具体怎么做的呢？下面我来详细说说。

1. 异步上报

首先是把日志上报从同步改为异步。原本的代码是这样的：

function logEvent(event) {
  fetch('https://jztheme.com/api/log', {
    method: 'POST',
    body: JSON.stringify(event)
  });
}

改成异步之后：

async function logEvent(event) {
  try {
    const response = await fetch('https://jztheme.com/api/log', {
      method: 'POST',
      body: JSON.stringify(event)
    });
    if (!response.ok) {
      console.error('Failed to log event:', response.statusText);
    }
  } catch (error) {
    console.error('Error logging event:', error);
  }
}

这样可以避免日志上报阻塞主线程，让页面响应更快。

2. 批量上报

单次上报虽然改成了异步，但如果请求频率太高，还是会拖慢性能。所以我决定把日志批量处理后再上报。具体实现如下：

const logQueue = [];
let logIntervalId = null;

function logEvent(event) {
  logQueue.push(event);

  if (logIntervalId === null) {
    logIntervalId = setInterval(() => {
      if (logQueue.length > 0) {
        const events = logQueue.splice(0, logQueue.length);
        sendLogs(events);
      }
    }, 5000); // 每5秒上报一次
  }
}

async function sendLogs(events) {
  try {
    const response = await fetch('https://jztheme.com/api/log/batch', {
      method: 'POST',
      body: JSON.stringify({ events })
    });
    if (!response.ok) {
      console.error('Failed to log batch:', response.statusText);
    }
  } catch (error) {
    console.error('Error logging batch:', error);
  }
}

这样每次上报的都是批量的日志数据，减少了请求次数，性能自然就提升了。

性能数据对比

优化前，页面加载时间平均在5秒左右，操作响应时间也很长。优化后，页面加载时间降到了800毫秒，操作响应也快了很多。用户反馈明显好了很多，不再抱怨卡顿了。

这里附上一些具体的性能数据：

• 页面加载时间：5s → 800ms
• 请求次数：每分钟20次 → 每5秒1次
• CPU占用率：60% → 20%

以上是我的优化经验，有更好的方案欢迎交流

这次优化让我深刻体会到，有时候简单的改动就能带来巨大的性能提升。当然，每个项目的具体情况可能不同，大家可以根据自己的实际情况调整优化方案。如果有更好的方法，欢迎在评论区留言交流。

后续我会继续分享更多实战经验和踩坑经历，希望对大家有所帮助。