按GB计费代理：如何计算和节省流量消耗
当你为每传输一个吉字节（GB）付费时，流量就不再是抽象概念，而是真金白银。一个不小心拖入大图和视频的脚本，一夜之间就能吃掉你一个月的预算。好消息是，流量消耗是可以管理的，而且只要弄明白其中的机制，管理起来并不难。
本指南将教你如何在任务开始前估算流量，测量实际消耗，并通过简单方法将其成倍缩减。我们只关注按量付费套餐下的流量经济性，适用于任何类型的代理。
引言：为什么需要提前估算流量
在按GB计费时，每个请求都有成本。问题在于，在账单到来或余额清零之前，这笔成本是看不见的。大多数新手都是事后才计算消耗，但正确的做法恰恰相反：在启动前就估算预算并留出余量。
你能得到什么
读完本指南后，你将能够按组件体积拆解任意网页，用Python或Node编写简单的流量计数器，应用可将消耗降低70%–95%的节省技巧，并合理计算项目预算。你还会明白，什么时候按量付费更划算，什么时候该选择不限量套餐。
本指南适合谁
- 适合通过代理进行数据抓取和采集的人。
- 适合批量发送请求的自动化工程师。
- 适合需要对接外部数据源的营销人员和分析师。
- 适合所有希望在结果相同的情况下花更少钱的人。
你需要提前了解什么
对HTTP请求有基本了解会是加分项，但不是必须。我们会用通俗的语言解释关键术语。实践部分需要你有一点运行Python或Node.js脚本的基础经验，但我们会提供带注释的现成代码。
需要花费多少时间
阅读并理解理论大约需要30分钟。配置流量计数器需要15–20分钟。将节省技巧应用到自己的项目所需时间取决于项目复杂度，但基本方法你在一小时内就能用起来。
准备工作：工具和访问权限
在开始计算和节省流量之前，先准备好一套工具。全部免费，支持Windows、macOS和Linux。
必需工具
- Python 3.10或更高版本 —— 用于编写流量统计脚本。
- Node.js 18或更高版本 —— 适合熟悉JavaScript的用户的替代方案。
- Python的requests库 —— 通过 pip install requests 安装。
- Playwright库 —— 用于操作无头浏览器，通过 pip install playwright 和 playwright install 安装。
- 带开发者工具的浏览器 —— 任何现代浏览器都可以，需要内置的Network面板来手动分析页面。
- 代理服务商个人后台的访问权限 —— 在那里查看实际流量统计。
系统要求
近十年内发布的任何电脑都够用。4GB内存即可，但对于无头浏览器，8GB体验更佳。磁盘空间需要约2GB，用来存放Playwright的浏览器引擎。
需要安装和配置什么
- 从官方网站下载并安装Python，安装时勾选“添加到PATH”。
- 打开终端，运行 python --version 检查安装是否成功。
- 运行 pip install requests 安装requests库。
- 如果计划使用浏览器，运行 pip install playwright 安装Playwright，然后执行 playwright install chromium。
- 确保手头有代理连接参数：地址、端口、用户名和密码。
提示：为流量实验创建一个单独文件夹。这样你不会搞乱文件，出现问题也能轻松回滚。
⚠️ 注意：绝不要把代理的用户名和密码直接写在你要发送给他人的代码中。请使用环境变量或单独的配置文件，避免泄露给他人。
✅ 检查：如果 python --version 和 pip --version 都能正常输出版本号，说明准备成功。
基础概念：用大白话讲清楚
在数字节之前，先理清术语。不堆行话，用大白话讲。
什么是流量
流量就是通过你的连接所传输的数据量。它包含你发送给服务器的内容，以及服务器返回给你的内容。按GB计费时，两个方向都会计算，但入站流量（服务器响应）通常比出站流量大好几倍。
一个请求由什么构成
当你打开一个网页时，浏览器会发送请求并收到响应。响应由头部（关于大小、类型、编码等元信息）和正文（实际内容：HTML、图片、脚本）组成。正文的重量几乎总是远大于头部。
关键术语
- GET请求 —— 普通的获取内容请求，同时返回头部和正文。
- HEAD请求 —— 只请求头部，不返回正文。当你不需要正文时可以节省流量。
- Content-Length —— 用于告知响应正文大小的头部，单位为字节。
- Accept-Encoding —— 用来请求服务器压缩响应的头部。
- gzip和brotli —— 压缩算法，可将文本数据体积缩小数倍。
- 重定向 —— 从某个地址跳转到另一个地址。每次重定向都会产生额外的请求和流量。
- 无头浏览器 —— 没有图形界面、由代码控制的浏览器。它会像普通浏览器一样加载所有内容，包括重型资源。
节省流量的核心原则
不加载与任务无关的内容。听起来很简单，但正是违反这条规则才让你花掉冤枉钱。如果你只需要商品卡片上的文字，那么商品照片、视频评测、广告横幅和分析追踪器都不需要。
页面体积由什么构成：真实拆解
本部分旨在通过具体示例说明：页面体积的绝大部分通常是你不需要的。我们以典型的电商页面为例。
各组成部分及其占比
现代页面的平均体积在2到5MB之间。重量大致分布如下：
- 图片 —— 占总体积的50%–70%。商品照片、横幅、高清图标。
- JavaScript脚本 —— 占15%–25%。界面逻辑、小部件、聊天组件、计数器。
- 字体 —— 占5%–10%。自定义字体以独立文件加载。
- 统计与追踪器 —— 占5%–15%。像素标签、统计系统、广告脚本。
- 视频和媒体 —— 从0到巨大的量级。自动播放的视频会迅速烧掉预算。
- HTML文档 —— 仅占1%–5%。而你通常需要的数据恰恰就在这里。
实际结论
如果你只需要HTML中的文本数据，那么你可以去掉页面90%–95%的体积。一个5MB的页面可以变成100–200KB的有用HTML。这不是夸张，而是典型情况。
如何手动拆解页面
- 在浏览器中打开页面。
- 按F12打开开发者工具。
- 切换到Network标签页。
- 按F5刷新页面。
- 在面板底部你会看到加载数据的总大小和请求数量。
- 按Size列排序请求，找出体积最大的资源。
- 注意Type列：img表示图片，script表示脚本，font表示字体。
提示：Network面板中有按资源类型筛选的功能。点击Img按钮，即可看到所有图片的总大小。这个数字通常会让你震惊。
✅ 检查：你应该会看到HTML文档的体积比图片和脚本的总和小几十倍。这印证了节省流量的主要空间在于去掉媒体资源。
第1步：测量任务的实际流量消耗
本阶段目标：学会精确计算脚本消耗了多少流量，从而有意识地控制消耗。
用Python统计流量
requests库可以让我们获取每个响应的大小。我们将正文长度与头部大小相加。
- 在你的工作目录中创建 traffic_counter.py 文件。
- 写入库导入代码：import requests。
- 以字典形式配置代理，键为http和https。
- 在请求循环前初始化变量 total_bytes 为0。
- 每次请求后，将 response.content 的长度累加到该变量。
- 为了提高准确性，可把头部字符串表示的长度也计入。
- 最后将 total_bytes 除以 1048576，换算成MB。
逻辑很简单：len(response.content) 返回响应正文的字节数。头部则按键和值的长度总和计算。对于大多数任务，响应正文是流量的主要部分，因此仅用content来统计也能达到约95%的准确率。
重要：如果服务器返回的是压缩响应，response.content 返回的是解压后的数据。由于压缩，实际网络流量可能会更小。要测量实际传输的字节数，请查看响应中的 Content-Length 头部，它表示正文在网络传输时的大小。
精确统计传输字节数
- 请求后读取 response.headers.get('Content-Length')。
- 如果该值存在，就把它作为正文的真实字节大小。
- 如果头部不存在（例如流式传输），则以content的长度为准，但要记住这是解压后的大小。
用Node.js统计流量
在Node中，可以使用内置的https模块或axios库。原理相同：累加接收到的数据大小。
- 创建 traffic_counter.js 文件。
- 引入请求库。
- 初始化变量 totalBytes 为0。
- 对每个响应，读取content-length头部或计算数据缓冲区的长度。
- 将该值累加到 totalBytes。
- 最后输出 totalBytes 除以 1048576 的结果，得到MB数。
提示：除了总结果，请分别记录每个请求的体积。这样你能立即看出哪个URL消耗最多，并针对性优化。
与个人后台统计进行比对
你自己的计数器和代理服务商的统计之间可能会有小幅出入。这是正常的。原因包括：
- 服务商统计的是整个连接的全部流量，包括数据包开销和安全通道的建立。
- 你的计数器只统计响应的有效负载。
- 请求头部、DNS解析和连接重建都会产生少量额外开销。
- 用你的脚本发起100个请求，记下计数器的结果。
- 在运行前后分别查看代理服务商的个人后台。
- 记录后台统计的差值。
- 与你的计数器对比。10%–20%的偏差是正常的，属于连接开销。
⚠️ 注意：预算时一定要计入连接开销。实际消耗几乎总是比客户端统计的有效负载高出10%–20%。
✅ 检查：如果计数器显示的数字与后台差值在计入开销后接近，说明统计设置正确，你可以信任自己的测量结果。
第2步：基础流量节省技巧
本阶段目标：应用无需复杂代码即可降低消耗的简单技术。我们先从最容易上手的开始。
技巧1：通过Accept-Encoding启用压缩
文本数据（HTML、JSON、脚本）有着很好的压缩性。让服务器返回压缩响应，可以帮你把流量减少3–5倍。
- 在请求头部中添加 Accept-Encoding，值为 gzip, br, deflate。
- Python的requests库会自动添加该头部并自行解压响应。
- 确保你没有手动禁用这个选项。
- 检查响应的 Content-Encoding 头部：如果是gzip或br，说明压缩生效。
这里br指的是brotli——一种比gzip压缩率更高的现代算法。大多数服务器都支持它。要在Python中使用brotli，请运行 pip install brotli 安装对应包。
提示：从流量角度看，压缩是免费的；从CPU负载看，也几乎可以忽略。请始终保持开启。当流量消耗较高时，这是首先要检查的事项。
技巧2：用HEAD替代GET
当你只需要头部时——比如检查页面是否存在、了解它的大小或修改日期——请使用HEAD请求。它只返回头部，不返回正文。
- 把 requests.get 换成 requests.head。
- 在 response.headers 中读取所需头部。
- 正文不会被传输，这类检查可以节省高达99%的流量。
HEAD的典型场景：检查链接状态、在下载前确定文件大小、检查最后修改时间以用于缓存。
技巧3：避免多余的重定向
每次重定向都是一次完整的请求-响应循环。如果网站总是从http跳转到https，或从一个地址跳到另一个地址，你就是在为多余的绕路付费。
- 直接使用最终地址：使用https，去掉多余斜杠。
- 如果知道地址会重定向到www版本，就直接访问www版本。
- 在库中可通过将 allow_redirects 设为 False 来关闭自动跟随重定向，以便手动控制。
- 一次性收集重定向映射，之后直接访问最终地址。
技巧4：在简单请求中禁止加载图片和媒体
当你使用requests库而不是浏览器时，你不会自动加载图片。requests只会拉取你指定的URL。相对于浏览器，这是一个巨大的优势。
如果你只需要HTML，requests.get 会返回不含图片的HTML，因为图片是浏览器根据HTML中的链接额外发起的请求。除非你明确要求，否则库不会这样做。
提示：对于文本数据采集任务，优先使用简单的HTTP库而非浏览器。由于不加载媒体、字体和追踪器，流量会自动节省数倍。
✅ 检查：对比通过requests和浏览器加载同一页面的体积。通常请求库比浏览器少10–30倍。
第3步：使用无头浏览器并屏蔽资源
本阶段目标：学会在浏览器中屏蔽重型资源类型。当你确实需要浏览器时，这是流量节省最大的单项收益。
什么时候必须用浏览器
有时离不开浏览器：页面打开后数据由脚本动态加载，或存在针对简单请求的防护，或内容是动态生成的。这种情况下，浏览器会加载一切，流量飙升。解决办法是拦截并屏蔽不需要的资源类型。
在Playwright中屏蔽资源
Playwright允许拦截浏览器的每个请求，并决定是放行还是取消。我们将取消图片、字体、媒体和样式。
- 创建 browser_saver.py 文件。
- 从 playwright.sync_api 导入 sync_playwright。
- 以headless模式启动浏览器。
- 通过 proxy 参数创建带代理设置的上下文。
- 使用 page.route 为所有URL设置路由处理器。
- 在处理器中通过 request.resource_type 判断资源类型。
- 如果类型在屏蔽列表中，调用 route.abort。
- 否则调用 route.continue_。
在典型的文本采集任务中，需要屏蔽的类型有：image、media、font、stylesheet。有时也可以屏蔽部分脚本，但要谨慎——没有它们，内容可能无法加载。
处理器逻辑示例
处理器接收请求对象。你获取 request.resource_type，并与屏蔽列表进行比较。如果资源是图片或字体，就取消它，浏览器不会为其消耗流量。如果是文档或需要的脚本，则放行。
重要：屏蔽image、media和font几乎不会破坏文本数据采集，却能节省绝大部分流量。请从这些开始，只有在确认页面仍能返回所需数据后，再考虑添加脚本和样式的屏蔽。
在Node的Puppeteer中屏蔽资源
- 通过 page.setRequestInterception 启用请求拦截，设为true。
- 订阅 request 事件。
- 在处理器中检查 request.resourceType。
- 对图片、字体和媒体调用 request.abort。
- 对其余请求调用 request.continue。
⚠️ 注意：屏蔽样式有时会影响依赖元素可见性的动态内容。如果屏蔽样式后数据丢失，请将stylesheet重新加入白名单。
提示：添加一个计数器，统计被屏蔽和放行的请求数量。你会从数字中看到，80%–90%的请求被拦截，这就是直接省下的钱。
浏览器中的额外节省
- 如果浏览器引擎支持，在上下文设置层面禁用图片加载。
- 不要打开多余的标签页，每个标签页都会加载各自的资源。
- 获取数据后立即关闭页面，不要一直保持打开。
- 对一系列页面复用同一个浏览器上下文，而不是反复重启。
✅ 检查：在同一页面上分别运行开启和关闭屏蔽的浏览器，用你的计数器比较流量。节省应达到70%–90%。如果更少，请检查路由处理器是否真正生效。
第4步：缓存和请求去重
本阶段目标：不再为相同内容请求两次。对未变化的数据进行重复请求，等同于扔掉钱。
为什么会重复请求
在大型任务中，同一资源会被多次请求：所有页面共用的脚本、重复链接、脚本崩溃后从头重新运行。每一次重复，都是你再次付费的流量。
简单的响应缓存
- 准备一个字典或本地数据库，键为URL，值为响应。
- 请求前检查URL是否已存在于缓存。
- 如果存在，直接从缓存取数据，不发起网络请求。
- 如果不存在，发起请求并将响应存入缓存。
- 为使缓存跨运行生效，可将响应保存到文件或本地数据库。
这种缓存在你调试脚本并连续多次运行时效果尤其明显。第二次及后续运行会从磁盘读取数据，不消耗任何网络流量。
URL列表去重
- 开始前将所有URL收集到一个列表中。
- 将列表转换为集合以去除重复。
- 规范化地址：去掉多余参数，统一带斜杠的格式。
- 仅处理唯一地址。
提示：重复地址常常被URL末尾的不同参数所掩盖，而这些参数并不改变内容。在比较前去掉追踪和排序参数，去重后的URL数量会明显减少。
条件请求实现节省
如果你定期检查相同的页面，可以使用条件请求。只有当数据变化时，服务器才会返回完整响应。
- 在第一次请求时，保存响应中的 ETag 和 Last-Modified 头部。
- 再次请求时，在 If-None-Match 和 If-Modified-Since 头部中传回它们。
- 如果数据未变化，服务器会返回不含正文的短响应，状态码为304。
- 你省下了整个正文的体积，只需为一个极小的头部付费。
✅ 检查：引入缓存后，对相同数据再次运行脚本时，流量应接近零。如果流量仍然很大，请确认缓存检查发生在网络请求之前，而不是之后。
第5步：流量预算计算
本阶段目标：学会预测消耗并预留余量，以免任务中途余额用尽。
基本公式
基本公式很简单：总流量 = 页面数量 × 单页平均体积。但细节决定成败，下面我们来处理细节。
- 确定经过所有优化后，单页的平均体积。
- 乘以计划处理的页面数量。
- 加上连接开销——大约15%。
- 再加上用于重试和错误的余量——再20%。
- 得到的数字就是你的实际流量预算。
如何测量平均体积
- 在50–100个页面的样本上运行你的优化脚本。
- 用你的计数器统计总流量。
- 除以页面数量，得到单页平均体积。
- 在公式中使用这个测量值，而不是理论假设。
计算示例
假设屏蔽媒体后，单页平均体积为150KB。你需要处理100,000个页面。计算：150KB × 100,000 = 15,000,000KB，约14.3GB。再加上15%开销和20%余量，总共约19.5GB。选择套餐时就应该以这个体积为参考。
再看看不优化的情况：如果每页3MB，同样的100,000个页面就是300GB。相差15倍——这就是账单数字的差距。
提示：在大规模运行前，务必在小样本上做一次试运行。测量出的平均体积比任何假设都真实，能避免账单上出现意外。
⚠️ 注意：别忘了预留余量。真实任务总会有意外：一些页面会更重，一些请求需要重试。没有余量的预算总会在最不恰当的时候耗尽。
节省技巧汇总表
以下是主要技巧的汇总：每个技巧能节省多少，以及你需要付出什么代价。
- gzip和brotli压缩 —— 文本数据可节省60%–80% —— 代价是解压时消耗少量CPU资源。
- 用HTTP库替代浏览器 —— 节省90%–95% —— 代价是可能无法获取由脚本动态加载的数据。
- 在浏览器中屏蔽图片和媒体 —— 节省50%–70% —— 代价是需配置请求拦截，风险极小。
- 屏蔽字体 —— 节省5%–10% —— 几乎零成本，数据并不依赖字体。
- 屏蔽脚本和样式 —— 节省15%–25% —— 代价是有内容无法加载的风险，需要验证。
- 用HEAD替代GET —— 对检查性请求可节省高达99% —— 代价是无法获得响应正文。
- 消除重定向 —— 对存在重定向的网站可节省10%–30% —— 代价是一次性收集地址映射所需的时间。
- 响应缓存 —— 对重复请求可节省高达100% —— 代价是占用磁盘空间存放缓存。
- URL去重 —— 存在重复时节省10%–40% —— 代价是一次性规范化列表。
- 带ETag的条件请求 —— 数据未变化时可节省高达99% —— 代价是存储版本标记。
✅ 检查：按公式计算预算，并与套餐余额对比。如果余量足够，就可以开始。如果不够，请回到节省技巧，降低页面平均体积。
第6步：什么时候不限量套餐更划算，什么时候按量付费更划算
本阶段目标：根据具体任务理性选择套餐，而不是因计费模式选择不当而多花钱。
什么时候按GB付费更划算
- 任务是临时的或低频的，用量不大。
- 你已优化好流量并清楚知道消耗量。
- 通过屏蔽媒体，页面平均体积很低。
- 高峰负载很少出现，大部分时间流量都很低。
- 你重视透明度：只为实际使用量付费。
什么时候固定价格的不限量套餐更划算
- 任务持续进行，用量大且稳定。
- 你不得不用浏览器加载重量级页面。
- 任务本身需要图片、视频或其他重型媒体。
- 消耗不可预测，可能突然大幅增长。
- 你更看重心理上的安心：固定付费，没有超支风险。
如何计算切换临界点
- 取按量套餐的每GB价格。
- 取不限量套餐在同一时间段的价格。
- 用不限量套餐价格除以每GB价格，得到两个套餐成本相等的GB用量。
- 如果你预测的消耗量高于这个数值，选择不限量套餐。
- 如果更低，选择按量付费。
例如，不限量套餐的价格约等于按量套餐50GB的费用。那么，当你用量超过50GB时，不限量套餐更便宜；低于50GB时，按量付费更划算。你在第5步测得的预算会直接给出答案。
提示：先优化流量，再选择套餐。好的优化往往让你从不限量套餐区间切换到更划算的按量区间，从而省下一大笔钱。
组合策略
有时最佳方案是两种方式并用：轻量文本任务走按量付费，重型浏览器任务走不限量。按任务类型进行区分，通常比一个套餐包打天下更省钱。
✅ 检查：针对你的实际预测，分别计算两种方案的费用。你应该得到正确选择后能省下多少的具体数字。如果差别微乎其微，就选更容易管理的那一个。
结果检查：核对清单
逐项核对以下清单，确保你已正确设置流量统计和节省方案。
- 基于Python或Node的流量计数器可以正常运行并输出无误。
- 计数器的数值与个人后台统计在计入开销后一致。
- 请求中已启用压缩，响应中可见 Content-Encoding gzip或br。
- 对检查性任务使用HEAD替代GET。
- 你直接访问最终地址，没有多余重定向。
- 在可能的情况下，文本任务使用HTTP库而非浏览器。
- 浏览器中已配置屏蔽图片、媒体和字体。
- 已设置响应缓存，重复运行几乎不消耗流量。
- URL列表已去重。
- 已按公式计算预算，并包含15%和20%的余量。
- 已选择与消耗预测匹配的套餐。
如何测试
- 在100个页面的样本上运行优化后的脚本。
- 记录个人后台在运行前后的流量数据。
- 除以页面数量，并与计算得到的平均体积对比。
- 如果一致，说明系统运行正常，可以扩大规模。
✅ 检查：如果100页的试运行在预测预算内，你就可以开始全面运行。将结果乘以规模系数，并确认余额充足。
常见错误及其解决方法
下面分析在流量统计和节省过程中常见的几种问题。
错误1：计数器显示的数字少于后台
原因：你只统计了响应正文，而服务商统计了整个网络交换，包括开销。解决方法：预留15%–20%的修正量，并将其视为正常现象，而非故障。
错误2：压缩未生效
原因：未安装brotli相关包，或手动禁用了Accept-Encoding。解决方法：安装brotli包，检查请求头部，并确认响应中包含Content-Encoding。
错误3：屏蔽资源后数据丢失
原因：你屏蔽了用于加载内容的脚本或样式。解决方法：将script和stylesheet重新加入白名单，只屏蔽image、media和font。
错误4：启用缓存后流量没有下降
原因：缓存检查发生在网络请求之后，而不是之前。解决方法：先检查缓存，只有当没有数据时才发起网络请求。
错误5：即便有处理器，浏览器仍然消耗流量
原因：路由处理器被绑定到了错误的URL模式，或是在加载开始之后才绑定。解决方法：在打开页面之前设置拦截，并使用通配符 * 覆盖所有URL。
错误6：实际消耗比预测高出数倍
原因：平均体积来自理论估算，而非试运行的实际测量。解决方法：在大规模运行前，务必在真实样本上测量平均体积。
错误7：任务进行到一半预算就耗尽了
原因：没有为重复请求和连接开销预留余量。解决方法：在预测基础上额外增加35%的余量，并在运行过程中持续关注余额。
错误8：同一地址被反复请求
原因：URL列表中因地址末尾的不同追踪标记而产生重复。解决方法：规范化地址，去掉追踪参数，并将列表转换为集合去重。
更多优化技巧和可能性
当基础节省工作完成后，还可以进一步压榨空间。
大响应的流式处理
如果响应很大，而你只需要其中一部分，请以流式方式读取，并在获得所需内容后立即停止。这样你不会下载整个文件。当数据位于大型文档开头时，这一点非常有用。
限制响应大小
设置一个你愿意接受的最大响应体积。如果服务器返回更多，就中断加载。这可以防止意外出现的重型页面一次性吃掉过多流量。
批量处理与并发
并发请求本身并不节省流量，但能让你更快完成任务并更早发现消耗问题。保持合理的并发连接数，避免对流量失去控制。
实时日志与监控
- 维护一个实时流量计数器，并每隔几百个请求输出一次。
- 设置一个阈值，当达到该阈值时脚本自动停止。
- 这样你就永远不会在不知不觉中超出预算。
提示：按流量上限自动停止是最好的保障。脚本会在达到设定阈值时自行停止，即使逻辑出错也不会超支。
只请求API中需要的字段
如果数据可以通过API获取，请在这些API支持的情况下只请求所需字段。许多接口允许指定返回哪些字段，与完整返回相比，这会大幅减小响应体积。
常见问题：关于流量节省的FAQ
按GB付费时，出站流量是否计入？
通常入站和出站都会计算，但出站（你的请求）比入站（服务器响应）小好几倍。节省的重点始终在入站流量上。
客户端统计有多准确？
相对于实际网络流量，准确率约为85%–95%。差额来自连接开销。只要预留修正量，这对预算规划来说已经足够。
可以完全不用浏览器吗？
对于许多文本采集任务，可以。简单的HTTP库就能胜任，并能节省数倍流量。只有当内容是在页面加载后由脚本生成时，才需要浏览器。
压缩默认是开启的吗？
在大多数现代库中是开启的，但仍值得检查。brotli可能需要单独的包。请始终以响应中的 Content-Encoding 头部为准。
在浏览器中最应先屏蔽什么？
从图片、媒体和字体开始——这是最大且最安全的收益。只有在确认数据仍能加载后，再考虑屏蔽脚本和样式。
如何判断预算是否充足？
在试运行中测量页面平均体积，乘以页面数量，再加上35%的余量，并与套餐余额对比。如果在范围内，就够用。
在单次遍历中，缓存有帮助吗？
在无重复的单次遍历中，帮助有限；但在调试和重启时会大幅节省。而条件请求和去重即使单次遍历也有帮助。
对于大且持续的用量，什么更划算？
通常固定价格的不限量套餐更划算。计算切换临界点：用不限量价格除以每GB价格，再与消耗预测对比。
重定向数量会影响账单吗？
会。每次重定向都是一次额外的请求-响应。在存在多重重定向的网站上，消除多余跳转可以节省可观的流量。
如何避免意外超出预算？
设置实时计数器和达到流量阈值时自动停止。脚本会自行停止，即使出错也不可能超支。
结语
你已经从“不知道流量花在哪”的阶段，走到了完全掌控消耗的阶段。现在你能够按组件拆解页面体积，并明白其中大部分对你而言并不需要。你已经配置了流量计数器，并与后台统计进行核对。你会使用压缩、用HEAD替代GET、消除重定向，并倾向于用轻量HTTP库替代沉重浏览器。
当确实需要浏览器时，你会屏蔽图片、媒体和字体，将流量削减70%–90%。你缓存响应，不会为相同内容请求两次。最重要的是，你会用带余量的公式计算预算，并理性选择套餐，而不是凭感觉。
接下来该做什么
- 今天就将在基础技巧应用到当前项目中。
- 做一次试运行，测量真实的页面平均体积。
- 重新计算预算，必要时更换套餐。
- 设置按流量上限自动停止，作为安全屏障。
节省流量是一项在每个项目中都能带来回报的技能。只要花一次时间配置统计和优化，你就能在结果不变的情况下节省数倍费用。从小处着手，用数字衡量效果，你会惊讶于同样的工作竟然可以便宜这么多。
