如果只用 HTTP 客户端抓取 HTML，1 GB 大约能装下 44,000 个页面；如果在浏览器里加载同样的页面，大约只有 900 个。抓取方式让答案相差约 49 倍，网站类型带来的差别要小得多。
2026 年 10 月 5 日，我们通过本地计量代理加载了 34 个公开页面，三种模式各加载三次。字节数按线路上的双向流量统计，因此包含 TLS 握手、HTTP 头、所有上行数据，以及对代理 CONNECT 交换的估算，而不只是页面重量。
| 页面的抓取方式 | 每页中位数 | 第 90 百分位 | 每 GB 页面数（中位数页面） | 每 GB 页面数（第 90 百分位页面） |
|---|---|---|---|---|
| HTTP 客户端，仅 HTML（Requests 2.34.2） | 22.7 KB | 59.2 KB | 44,083 | 16,880 |
| Playwright 1.63.0，完整加载 | 1.10 MB | 2.45 MB | 906 | 408 |
| Playwright，屏蔽图片、媒体和字体 | 454.6 KB | 2.28 MB | 2,199 | 437 |
1 GB 为 10^9 字节。每个页面的取值是它三次加载的中位数，第 90 百分位是 34 个页面中第四重的那个。如果你的目标页面很重，请按这一列来规划：屏蔽图片几乎没有改变它（从 2.45 MB 到 2.28 MB），因为最重的页面重在脚本。
估算你自己的 GB
GB per day = pages per day × bytes per page × attempts per page ÷ 1,000,000,000举个例子：每天用完整浏览器加载 50,000 个页面，按 1.10 MB 的中位数、每页 1.2 次尝试计算，就是 50,000 × 1,103,256 × 1.2 ÷ 10^9 = 66.2 GB/天。同样的任务改用 HTTP 客户端、按 22.7 KB 的中位数计算，是 1.4 GB/天。这里的 1.2 是示例用的假设（每五个页面重试一次），不是本次测得的数值。
要按尝试次数而不是页面数来算，因为每次重试都会把页面重新下载一遍；代理重试：丢失一个响应，创建两个任务说明了什么情况下重试才是安全的。另外，这些中位数描述的是我们的 34 个页面，不是你的页面。本文使用的免费计量工具 Scrapescope 可以在没有代理账号的情况下测量你自己的页面。
按页面类型看每 GB 页面数
每页字节数的中位数，括号内是每 GB 页面数：
| 页面类型 | 仅 HTML | 完整加载 | 屏蔽图片、媒体和字体 |
|---|---|---|---|
| 文档与参考（7 个页面） | 37.2 KB (26,912) | 589.6 KB (1,696) | 433.5 KB (2,306) |
| 新闻文章（5） | 51.7 KB (19,355) | 1.32 MB (758) | 2.24 MB (445) |
| 博客文章（5） | 24.9 KB (40,202) | 601.1 KB (1,663) | 444.3 KB (2,250) |
| 论坛帖子（3） | 20.8 KB (48,167) | 2.45 MB (408) | 2.26 MB (441) |
| 商店分类页（5） | 20.0 KB (50,042) | 1.33 MB (751) | 388.6 KB (2,573) |
| 商店商品页（5） | 21.3 KB (46,983) | 1.16 MB (858) | 347.9 KB (2,874) |
| JavaScript 应用（4） | 11.1 KB (90,009) | 1.39 MB (717) | 751.0 KB (1,331) |
各组的页面数很少，请把它们当作示例来读。商店页面来自爬虫练习沙盒和一个演示商店，因为我们排除了条款禁止自动化访问的零售商；真实的零售页面可能更重。对 JavaScript 应用来说，11 KB 只是 HTML 文档本身。HTTP 客户端只抓取这一个文档，不会加载脚本要加载的任何内容；我们测量的是字节数，而不是你需要的数据是否在这份 HTML 里。
什么对字节数影响最大
按在这组数据中的影响从大到小排列：
- 浏览器还是 HTTP 客户端。 对同一个页面，完整的浏览器加载传输的字节数中位数是 HTML 抓取的 31 倍，范围从一个 Python 文档页面的 2.1 倍到一个 JavaScript 渲染演示页面的 195 倍。
- 脚本比图片更重。 脚本占全部完整加载字节的 49%；图片、媒体和字体合计占 35%。三个论坛帖子在两种浏览器模式下都保持在 2.2 MB 到 2.6 MB 之间。
- 其他站点的主机。 完整加载字节的一半（49.9%）流向了页面自身站点之外的主机。中位数页面有 38% 流向那里，另有 7 个页面完全没有。最大的单个主机是
www.googletagmanager.com：它出现在 34 个页面中的 17 个上，每次加载约 308 KB，占全部完整加载字节的 12%。有一篇新闻文章连接了 32 个主机。 - 屏蔽图片、媒体和字体。 节省量的中位数是 28%。有 10 个页面超过 50%，最高 84%；有 6 个页面低于 10%。这 6 个页面中有三个在开启屏蔽后传输的字节反而更多。一篇新闻文章在三次屏蔽加载中有两次从
www.gstatic.com拉取了 1.14 MB，而这个主机在任何一次完整加载中都不在它最大的三个主机之列。在另一篇文章上，一个嵌入的 YouTube 视频在屏蔽时传输了 1.9 MB 到 2.0 MB，不屏蔽时是 1.2 MB。屏蔽会改变页面的行为，所以在依赖它之前请再测一次对比运行；Playwright 的网络指南记载了这里使用的 route 调用，Playwright 代理配置则说明代理这一侧。
压缩没有参与排序，因为每次运行都开启了压缩：34 个 HTML 响应全部是压缩后返回的（17 个 Brotli，14 个 gzip，3 个 Zstandard）。HTML 文档解压后的中位数是 83.5 KB，而整个抓取在线路上的中位数是 22.7 KB。不请求压缩的客户端下载的大小会更接近解压后的大小；参见哪些客户端不使用压缩。
上行占比与隧道开销
| 模式 | 上行字节占全部字节的比例 | 每页上行字节中位数 |
|---|---|---|
| HTTP 客户端，仅 HTML | 6.3% | 1.9 KB |
| Playwright，完整加载 | 2.7% | 28.9 KB |
| Playwright，开启屏蔽 | 2.9% | 17.3 KB |
上行流量总体占比很小，但在小页面上占比很大：在单次 HTML 抓取中最高达到 21%，因为无论响应多小，TLS 握手和请求本身的开销都一样。请确认你的服务商是否对两个方向都计费。
估算的 CONNECT 交换给一次 HTML 抓取增加的字节数中位数是 109 字节，给一次完整的浏览器页面加载增加 2.6 KB，每条隧道一次交换。浏览器没有自行在后台抓取任何内容：在全部 204 次浏览器运行中，scrapescope 的后台流量、空闲预连接和未归属三个分类都是 0 字节。这是 Playwright 自带的 Chromium 在默认启动设置下的结果；其他浏览器构建没有测试。
每 1,000 个页面的成本
中位数页面，括号内是第 90 百分位页面：
| 每 GB 价格 | 仅 HTML | 完整加载 | 屏蔽图片、媒体和字体 |
|---|---|---|---|
| $1.00 | $0.02 ($0.06) | $1.10 ($2.45) | $0.45 ($2.28) |
| $3.50 | $0.08 ($0.21) | $3.86 ($8.57) | $1.59 ($7.99) |
| $5.00 | $0.11 ($0.30) | $5.52 ($12.24) | $2.27 ($11.42) |
| $10.00 | $0.23 ($0.59) | $11.03 ($24.48) | $4.55 ($22.83) |
$3.50 是 ipvolt 公布的价格：价格部分显示 "From $3.50/GB"，常见问题中写的是 "Traffic starts from $3.50/GB at launch." 另外三个是取整的参考点，不是任何人的价目表；市场价格请看无限量住宅代理套餐每 GB 的成本。每个数字都是字节数 ÷ 10^9 × 价格。它估算的是传输量，不是账单。
与 2025 年 Web Almanac 的对比
2025 年 Web Almanac 的 Page Weight 章节写道："The median home page in 2025 was 2.86 MB on desktop and 2.56 MB on mobile." 它的内页图表在 2025 年 7 月的数值是桌面端 1,963 KB、移动端 1,769 KB，HTML 响应的中位数是桌面端 35 KB、移动端 33 KB。
该章节把页面重量定义为 "the total volume of bytes transferred to a user’s device"，并说明它的 JavaScript 数据是 "bytes for compressed JavaScript files"，所以这些是传输大小，不是未压缩大小。在 HTML 数字旁边，它没有重复这一说明。
我们的完整加载中位数是 1.10 MB，低于 Almanac 的内页中位数。这组页面偏向文档和沙盒页面，而且大多是内页。HTML 的数字很接近：这里是线路上的 22.7 KB，那里是 33 KB 到 35 KB。两者统计的对象不同。Almanac 统计的是页面各个响应的重量；本次测试统计的是双向经过隧道的每一个字节。
方法与局限
- 时间和地点。 2026 年 10 月 5 日 08:37 至 09:04 UTC，从位于芬兰赫尔辛基的一台服务器直连发出。没有使用付费代理。
- 工具。 以直连估算模式运行的 scrapescope 0.1.0 作为本地计量代理，Python 3.14.4，Requests 2.34.2（urllib3 2.8.0），以及 Playwright 1.63.0 及其自带的 Chromium headless shell 153.0.8010.12。
- 每次加载。 新进程、新浏览器、空缓存，没有 cookie，也没有同意任何弹窗。浏览器使用 1280×900 的视口，等待 load 事件，然后最多再等 10 秒让网络空闲。它不滚动也不点击，所以滚动时才加载的内容没有计入。HTTP 客户端发送一次 GET 并跟随重定向。
- 页面。 34 个 robots.txt 允许访问的 URL，不需要登录，也没有付费墙。有一个论坛候选页面在测量前被剔除，因为其网站条款禁止自动化访问。全部 306 次加载都返回 HTTP 200。
- 波动。 同一页面最重和最轻的加载之间的差距，中位数在仅 HTML 模式下是 0.05%，完整加载是 0.2%，开启屏蔽是 0.3%。最大的是 54%，出现在上文提到的那篇新闻文章上。
- 局限。 直连只能复现传输层，不能复现代理的出口位置、拦截和重试；scrapescope 的 README 把估算模式称为受保护网站的 "a lower bound"。CONNECT 字节是估算值。按资源类型划分的占比由工具根据各主机的总量分摊得出，不是逐个请求测得的。只有一个地点、一天，而且页面会变化。
下载：URL 列表、包含全部 306 次运行的原始 CSV、计算得出的汇总，以及附带 README 的测量脚本。
ipvolt 正在为开发者和智能体构建代理基础设施。加入候补名单，开放访问时只发一封邮件。