免费工具 统计脚本体积对比：实测数字，不抄官网宣传
每家统计工具都说自己的脚本很小。我们在同一天从公开网址把它们逐个下载下来数字节：未压缩、gzip、Brotli，以及 Chrome 实际收到的大小。表里写了测量日期和准确网址，你可以自己复核；下面的小工具还能测你粘贴进来的任意脚本。
- 2026-11-10 实测
- 10 个脚本，附网址
- 你的脚本不离开浏览器
统计脚本下载体积
按 gzip 体积排序。TapCub 那一行高亮是因为它是我们自己的；它的数字和其他家用同一种方法测出来。
实测脚本体积
每个文件用 curl 下载三次：不要压缩、要 gzip、要 Brotli。「Chrome 收到」是服务器针对 Chrome 常用的 Accept-Encoding 请求头选的编码和大小。
| 脚本和网址 | gzip | Brotli | Chrome 收到 | 未压缩 | JS 文件数 |
|---|---|---|---|---|---|
| Plausible (script.js)plausible.io/js/script.js经典的脚本网址，仍在提供。 | 1,283 B | 1,271 B | 1,361 Bzstd | 2,841 B | 1 |
| Fathomcdn.usefathom.com/script.js | 2,090 B | 2,100 B | 2,283 Bzstd | 6,981 B | 1 |
| Plausible (pa-….js)plausible.io/js/pa-6_srOGVV9SLMWJ1ZpUAbG.jsplausible.io 自己网站加载的按站点生成的脚本，大小取决于开了哪些选项。 | 2,487 B | 2,493 B | 2,658 Bzstd | 5,972 B | 1 |
| TapCub1.0.5static.pathclue.com/client.js核心脚本。下一张表里的扩展只在对应功能打开时才加载。 | 2,852 B | 2,828 B | 2,970 Bzstd | 5,631 B | 1 |
| Umami Cloudcloud.umami.is/script.js | 4,134 B | 4,334 B | 4,334 Bbr | 9,246 B | 1 |
| Simple Analyticsscripts.simpleanalyticscdn.com/latest.js | 4,860 B | 4,895 B | 5,147 Bzstd | 9,611 B | 1 |
| Cloudflare Web Analyticsstatic.cloudflareinsights.com/beacon.min.js这次测试服务器没有提供 Brotli。 | 10,264 B | 未提供 | 10,264 Bgzip | 31,853 B | 1 |
| Matomo (matomo.js)5.14.2cdn.jsdelivr.net/gh/matomo-org/matomo@5.14.2/matomo.js5.14.2 版本自带的文件，经 jsDelivr 的 GitHub 镜像下载。自建部署时压缩取决于你的服务器配置，插件还可能加脚本。 | 22,178 B | 19,293 B | 19,293 Bbr | 68,294 B | 1 |
| Microsoft Clarity (clarity.js)0.8.77scripts.clarity.ms/0.8.77/clarity.js先加载按项目生成的标签（www.clarity.ms/tag/…，未测），再由它加载这个文件；其它模块按需加载。 | 26,564 B | 25,350 B | 25,350 Bbr | 73,892 B | 2 |
| PostHog (array.js)us-assets.i.posthog.com/static/array.js完整库。录屏、问卷等扩展打开后作为单独文件加载。 | 120,880 B | 121,277 B | 121,115 Bbr | 376,161 B | 1 |
字节数只算脚本文件本身走过网络的部分。上报请求（发回去的数据）不算，「JS 文件数」只算默认安装时下载的脚本。有的 CDN 现场压缩用的是较快的等级，所以 Brotli 偶尔比 gzip 还大。
没列：Google Analytics 4（gtag.js）、Google 跟踪代码管理器、百度统计、51.la、Mixpanel。测量当天我们连 googletagmanager.com、hm.baidu.com、sdk.51.la、cdn.mxpnl.com 都被重置连接，而且 gtag.js、gtm.js、hm.js 是按站点 ID 生成的，本来就没有一个可复核的统一数字。可以用下面的小工具测你自己网站上的那一份。
TapCub 按需加载的扩展
TapCub 默认安装只下载 2,852 B（gzip）的核心脚本。下面这些只在你打开对应功能时才加载，同一天实测。
| 文件 | gzip | Brotli | 未压缩 | 什么时候加载 |
|---|---|---|---|---|
| client-id-1.0.5.js | 3,003 B | 3,044 B | 6,443 B | 站点开了用户识别、要求同意或全埋点 |
| client-auto-1.0.5.js | 2,541 B | 2,568 B | 5,418 B | 开了全埋点（套餐和站点设置） |
| client-attr-1.0.5.js | 1,166 B | 1,136 B | 2,321 B | 嵌码带 data-attribution |
| client-replay-1.0.5.js | 1,297 B | 1,268 B | 2,274 B | 开了会话回放 |
| client-rec-1.0.5.js | 23,683 B | 24,378 B | 77,145 B | 某个会话被抽中回放时（rrweb 录制器） |
在线客服组件是另一个脚本，不在这里。
测你自己的脚本
粘贴脚本代码，或者填网址再点按钮。大小和 gzip 大小在你的浏览器里用 CompressionStream 算（浏览器默认的 gzip 等级，和服务器的结果会差几个百分点）。浏览器里算不了 Brotli。
点按钮时，你的浏览器会直接向这个地址发一次请求（不带 Cookie）。对方服务器允许跨域才能读到；读不到就在新标签页打开网址，复制代码粘贴进来。
粘贴的内容不会离开这个页面。
未压缩
—
gzip
—
gzip（KB）
—
gzip ÷ 未压缩
—
版本 v1.0更新于 更新记录
脚本体积说明了什么，没说明什么
字节数好比较，但它对页面的影响取决于脚本怎么跑、什么时候跑。
gzip 和 Brotli
压缩后的大小就是访客要下载的量。差几 KB 单独看很难察觉；在慢速移动网络上多几十 KB 就能感觉到了。
未压缩大小
浏览器要在主线程上解析、执行未压缩的代码。这部分开销随原始大小和脚本启动时做的事增加，体现在交互响应上，而不是下载时间上。
JS 文件数
多一个文件就可能多一次请求；放在另一个域名上的脚本还要单独建立连接。一个小加载器再去拉一个大文件，两样开销都有。
异步加载
统计代码一般用 async 或 defer 加载，不会挡住首屏渲染。但页面本来就重、或者在低端手机上，体积还是有影响。
这些是文件大小，不是测速分数。要看对你自己页面的影响，就对比装和不装脚本时的 Core Web Vitals，或者在浏览器开发者工具的网络和性能面板里看。
先对比，再测你自己的
表格只是起点，你网站上那段代码才是关键。
-
1
按问题选列
关心下载量看 gzip 或 Brotli，关心解析执行开销看未压缩，关心请求数看 JS 文件数。
-
2
看网址和日期
每一行都链到实测的那个文件。厂商之后发了新版本的话，体积多半已经变了。
-
3
测你网站上的脚本
在网页源代码里找到统计脚本的网址，填进上面的工具下载测量，或者直接粘贴代码。gtag.js、百度统计 hm.js 这类按站点生成的脚本只能这样测。
这些数字是怎么测的
同一台机器、同一天、公开网址、不走缓存。命令很简单，可以重复。
- 未压缩：
curl -H "Accept-Encoding: identity"，响应体的字节数 - gzip / Brotli：
Accept-Encoding: gzip或br，服务器实际发来的字节数（我们没有重新压缩） - Chrome 收到：
Accept-Encoding: gzip, deflate, br, zstd，由服务器选编码 - TapCub 线上文件和我们仓库里 1.0.5 的构建产物逐字节相同，gzip 体积和构建时的体积检查一致
| 列 | 请求头 | 说明 |
|---|---|---|
| 未压缩 | Accept-Encoding: identity | 浏览器要解析执行的代码 |
| gzip | Accept-Encoding: gzip | 老客户端和很多代理下载的大小 |
| Brotli | Accept-Encoding: br | 服务器提供 Brotli 时的下载大小 |
| Chrome 收到 | gzip, deflate, br, zstd | 新版 Chrome 实际下载的（支持的服务器会给 zstd） |
| JS 文件数 | — | 默认安装下载的脚本文件，不算上报请求 |
小、中、大三个脚本怎么看
从表里挑三行，看数字该怎么读。
| 脚本 | gzip | 未压缩 | 怎么读 |
|---|---|---|---|
| Plausible script.js | 1,283 B | 2,841 B | 表里下载量最小，启动时做的事也少 |
| TapCub client.js | 2,852 B | 5,631 B | 只是核心，含单页应用路由跟踪和 Web Vitals，扩展按需加载 |
| Matomo matomo.js 5.14.2 | 22,178 B | 68,294 B | 完整跟踪 API 在一个文件里，从你自己的服务器发出 |
做的事更多（单页应用、性能指标、热力图、录屏）的脚本自然更大。要比就比功能相同的脚本，或者把一家厂商你需要的可选文件加起来比。自建 Matomo 时，记得在宝塔 / Nginx 里给 .js 打开 gzip。
比较脚本体积时容易被误导的地方
「我们的脚本只有 X KB」这类说法里的四个坑。
只算加载器
有的统计代码先下载一个小标签，再去拉真正的库。要把默认安装下载的每个文件都算上。
拿未压缩和 gzip 比
宣传页经常把压缩前后的数字混着写。每个脚本都要比同一列。
相信过时的数字
脚本每次发版都会变。没有日期、没有网址的体积数字没法核对。
把体积当成速度
一个启动时干很多活的小脚本，对响应速度的影响可能比一个大但闲着的脚本还大。在你的页面上看 Web Vitals。
核心很小，功能用到才加载
TapCub 的统计代码先加载统计核心，其它部分只在你的站点打开对应功能时才下载。
百度统计代码会拖慢网站吗？
百度统计的 hm.js 按站点 ID 生成，这次没有测到可靠的数字。统计代码一般是异步加载，不挡首屏渲染，但仍然占带宽和主线程时间。用上面的工具测你网站上那一份，再对比装和不装时的 Web Vitals。
统计代码会影响网站速度和 SEO 吗？
异步加载的统计脚本不会挡住首屏渲染，但下载和执行仍有开销，脚本越大、启动时做的事越多，低端手机上越明显。Google 把 Core Web Vitals 作为页面体验的一部分，所以要看的是你页面的 LCP、INP、CLS 有没有变差。
TapCub 的统计脚本有多大？
2026-11-10 实测核心 client.js 为 2,852 字节 gzip（未压缩 5,631 字节）。用户识别、全埋点、来源归因、会话回放这些扩展只在打开对应功能时才下载，大小见第二张表。
为什么这里的 Brotli 有时比 gzip 还大？
我们记录的是服务器实际发来的字节。有的 CDN 用较快的 Brotli 等级现场压缩，结果可能比提前压好的 gzip 文件稍大。
用浏览器开发者工具测不就行了？
可以：网络面板里的「已传输」大小和我们的「Chrome 收到」是一个意思。它还包含响应头，所以比表里只算响应体的数字略大。
脚本越小越好吗？
前提是它能做你要的事。会话录屏、热力图、产品分析都需要更多代码。先定功能，再比较能覆盖这些功能的脚本。