プロキシ帯域幅コストを削減する方法: GB請求を60-90%削減
GBごとに支払うプロキシでは、請求はリクエストではなくバイト数で行われます。そして、そのバイトの大部分は解析しない画像やフォントです。これらを削除し、住宅用GB請求を半分以上削減する方法を紹介します。
GBごとに支払うプロキシでは、請求はリクエストではなくバイト数で行われます。そして、大部分のバイトは解析しない画像、フォント、スタイルシートです。高解像度の製品写真1枚で2.2 MB、1ページのフルブラウザレンダリングで2-5 MBです。実際に抽出するスリムなHTMLは150 KB未満であることが多いです。残りを削除すると、住宅用GB請求が60-90%削減されます。このガイドは実践的なプレイブックです: アセットをブロックし、変更されていないページをスキップし、圧縮し、HTMLではなくJSONにルートを設定します。
まず、何に請求されているかを知る
住宅用帯域幅は、送信されたデータの合計で測定されます: リクエストヘッダーとリクエストボディ、レスポンスヘッダーとレスポンスボディです。つまり、ページが引っ張るすべてのアセット—画像、フォント、トラッキングスクリプト—が請求書に載りますが、それらはパーサーに供給されません。最適化のターゲットはシンプルです: 抽出するバイトのみをダウンロードします。それ以外は無駄であり、あなたが支払っているものです。
ヘッドレスブラウザでアセットをブロックする
ブラウザを操作している場合、これが最大のレバーです。PlaywrightとPuppeteerはどちらもリクエストをインターセプトし、不要なリソースタイプを中止することができます。画像、メディア、フォント、スタイルシートをブロックすることで、ページの重量を大幅に削減できます—DOMはまだ構築されるので、セレクターやハイドレーションJSONは生き残ります:
// Playwright: abort the resource types you never parse
await page.route('**/*', (route) => {
const type = route.request().resourceType();
if (['image', 'media', 'font', 'stylesheet'].includes(type)) {
return route.abort();
}
return route.continue();
});
await page.goto(url, { waitUntil: 'domcontentloaded' });二つの注意点: あなたが求めているデータを運ぶXHR/fetchコールをブロックしないでください、そしてページがまだ必要なものをレンダリングすることを確認してください—過剰なブロックはサイトのロジックを壊す可能性があります。ブラウザとプレーンリクエストを比較している場合、レンダリングとHTTPリクエストのコストの10-50倍のギャップがこの決定を重要にします。
変更されていないページをスキップする
最も安いバイトはダウンロードしないものです。モニタリングジョブで再取得の無駄を削減するための二つの技術があります。HEADリクエストは、完全なGETをコミットする前にContent-LengthまたはLast-Modifiedを確認するためにヘッダーのみを引っ張ります。さらに良いのは、条件付きGETが前回のETagまたはタイムスタンプを送信し、サーバーが変更がない場合に空のボディで304 Not Modifiedを返すことです—ページ全体ではなく、いくつかのヘッダーバイトに対して支払います:
import requests
# conditional GET: 304 = near-zero bytes when unchanged
headers = {"If-None-Match": last_etag,
"If-Modified-Since": last_seen}
r = requests.get(url, headers=headers, proxies=proxies, timeout=20)
if r.status_code == 304:
pass # unchanged, no body downloaded, no GB spent
else:
process(r.content)
last_etag = r.headers.get("ETag")毎日同じページを再チェックするスクレイパーにとって、条件付きGETだけで帯域幅を劇的に削減できます。なぜなら、ほとんどのページは実行間で変わらないからです。
常に圧縮を受け入れる
テキストはよく圧縮されます—HTML、JSON、CSSはgzipまたはbrotliで70-90%縮小されます—そして、実際にワイヤを越える圧縮されたサイズで請求されます。Accept-Encodingヘッダーを送信し、サーバーに圧縮させます。Pythonのrequestsでは、これがデフォルトでオンになっていますが、明示的に要求しない限り、原始的なクライアントではそうではありません:
headers = {"Accept-Encoding": "gzip, deflate, br"}
r = requests.get(url, headers=headers, proxies=proxies, timeout=20)
# requests transparently decompresses; you're billed on the small sizeJSONにルートを設定し、HTMLではなく
最大の構造的勝利は、レンダリングされたページを完全にスキップすることです。多くのサイトは、同じデータをバイトの一部で運ぶJSONエンドポイントからハイドレートします—製品の価格と在庫を3 MBのレンダリングされたページの代わりに10 KBのAPIレスポンスとして。ブラウザのネットワークタブでXHRコールを見つけて、直接アクセスします。Shopifyストアは典型的な例です: products.jsonエンドポイントは、HTMLなしでカタログ全体を提供します。APIを読み取れる場合はそうしてください—レコードごとにキロバイトとメガバイトの違いです。
APIにバイトを数えさせる
サイトごとにブロックルールを手動で調整したくない場合、Scraper APIが必要なときだけレンダリングし、解析されたmarkdownまたはJSONを返すことでアセットを削除します—抽出されたコンテンツを受け取り、そこから来たメガバイトは受け取りません。そして、GBごとに支払う住宅用プロキシでは、節約は直接的です: ワイヤ上のバイトが少ないほど、請求書のドルが少なくなり、保持するデータから何も失われません。ギガバイトが実際に何を買うのかの全体像については、GBごとの価格設定の内訳をご覧ください。
GBごとに支払う住宅用プロキシでよりスリムにスクレイピングする
よくある質問
プロキシの帯域幅はどのように計算されますか？
送信されたデータの合計バイト数で: リクエストヘッダーとリクエストボディ、レスポンスヘッダーとレスポンスボディです。したがって、ページがロードするすべての画像、フォント、スクリプトが使用量にカウントされ、解析するHTMLだけではありません。これが、未使用のアセットをブロックし、変更されていないページをスキップすることがGBごとのプランで直接的に請求を削減する理由です。
画像をブロックするとスクレイピングが壊れますか？
慎重であれば壊れません。画像、メディア、フォント、スタイルシートをブロックしても、DOMとJavaScriptはそのままなので、セレクターやハイドレーションJSONはまだ機能します—視覚的なペイロードだけをスキップしています。リスクは過剰なブロックです: データを運ぶXHR/fetchコールを中止せず、ページが必要なものをまだ生成することを確認してから大規模に実行してください。
最大の帯域幅節約は何ですか？
JSONエンドポイントにルーティングし、完全なページをレンダリングする代わりに、存在する場合です。10 KBのAPIレスポンスが同じレコードの3 MBのレンダリングを置き換えることができます—99%の削減です。その後、ヘッドレスブラウザでアセットをブロックし、再クロールで条件付きGETを使用することが最大の勝利です。圧縮はほぼ無料で、常にオンにするべきです。
現実的にどれくらい節約できますか？
アセットをブロックすることで、レンダリングされたページの重量を半分以上削減することが一般的です。条件付きGETは、変更されないページの再クロール帯域幅をほぼゼロに削減できます。HTMLからJSONルートへの切り替えは、レコードごとに90%以上の削減が一般的です。これらを組み合わせると、住宅用GB請求を60-90%削減することがほとんどのプロジェクトで現実的な目標です。
これらのどれも抽出する内容を変えません—抽出するために支払うものを変えます。決して読まないアセットをブロックし、移動していないページをスキップし、圧縮を受け入れ、完全なレンダリングよりもJSONルートを優先します。GBごとのプロキシでは、これらの4つの習慣が請求を半分以上削減することが一般的です。数百万ページにわたってこれをスケールするアーキテクチャについては、大規模スクレイピングアーキテクチャのガイドをご覧ください。