JavaScript计算网页总传输大小与DevTools数值不符怎么办

统计结果与DevTools Network面板不一致的核心原因 #

• 代码存在基础错误：你在累加逻辑中使用的变量是totalTransferSize，最后打印输出时却调用了未定义的bytesSent变量，输出值本身就存在错误。
• 漏统计主文档传输体积：performance.getEntriesByType('resource')仅会返回图片、JS、CSS、接口请求等子资源的性能条目，当前页面的HTML主文档本身的传输体积不在这个范围内，需要单独从navigation类型的性能条目中获取，这部分是差值的主要来源之一。
• 跨域资源权限限制：对于跨域加载的资源，如果响应头没有配置Timing-Allow-Origin并允许当前页面域名访问，浏览器会出于安全考虑将该资源性能条目的transferSize、encodedBodySize等字段置为0，这部分体积前端JS无权限读取，自然无法统计。
• 统计时机过早：如果你在页面完全加载前就调用统计函数，后续懒加载的资源、按需加载的异步JS chunk、用户交互触发的动态请求还未生成性能条目，不会被计入总和。
• 性能缓冲区溢出：浏览器对性能条目存储有数量上限，如果页面请求量特别大，早期的性能条目可能被挤出缓冲区，导致统计不全。

修正后的前端统计实现 #

你可以参考下面的代码修复上述问题，尽可能贴近DevTools的统计值：

let totalTransferSize = 0;

// 实时监听所有新产生的性能条目，避免统计时机问题和缓冲区溢出问题
const observer = new PerformanceObserver((list) => {
  list.getEntries().forEach(entry => {
    totalTransferSize += entry.transferSize || 0;
  });
});
// 监听资源请求和导航请求，buffered设为true表示拿到注册监听前已经产生的条目
observer.observe({ type: 'resource', buffered: true });
observer.observe({ type: 'navigation', buffered: true });

// 页面所有资源加载完成后输出结果
window.addEventListener('load', () => {
  // 留一个宏任务的间隔，确保最后一批请求的条目都写入完成
  setTimeout(() => {
    console.log(`${(totalTransferSize / 1024 / 1024).toFixed(2)} MB`);
  }, 0);
});

注意：该方案的统计精度受跨域资源权限限制，如果页面存在未配置Timing-Allow-Origin的第三方资源，统计值仍然会比实际值偏小，这个问题前端层面没有解法。

Node.js服务端统计方案 #

如果需要100%准确的传输大小统计，服务端/网关层统计是更可靠的路径：

• 对于你自有服务托管的资源（包括主文档、自有静态资源、自有接口），可以在Nginx网关或者Node.js服务层，统计每个响应实际发送的字节数（注意要统计gzip/brotli压缩后的实际出站流量，包含响应头大小，和DevTools的传输大小口径完全一致），再通过请求的Referer头关联到对应页面，累加同个页面加载过程中所有关联请求的体积即可，得到的结果和DevTools显示值完全一致。
• 对于页面加载的第三方跨域资源，由于请求不会经过你的自有服务端，无法通过纯服务端方案统计。如果是自动化测试场景，可以通过Puppeteer对接Chrome DevTools Protocol，监听网络事件拿到所有请求（包括第三方请求）的实际传输大小，结果和DevTools面板完全一致。

内容的提问来源于stack exchange，提问作者Manu