← ブログに戻る
RUENZHESARPTDEFRJAKOITTRIDVIFAHI

Playwright、Puppeteer、requestsが1000ページで消費するトラフィック量：プロキシ用の計算

Playwright、Puppeteer、requestsが1000ページを解析する際に実際にどれだけのトラフィックを消費するか、データを失うことなくプロキシトラフィックのGB消費をどのように削減できるかを検討します。

📅2026年9月18日

あなたがGB単位でプロキシトラフィックに支払っている場合、ヘッドレスブラウザと通常のHTTPクライアントの違いは、同じ1000ページのデータセットで15〜20倍のコストがかかる可能性があります。この記事では、Playwright、Puppeteer、Pythonライブラリrequestsのトラフィック消費の実際の測定値、テスト用のコード、データを失うことなくデータ量を削減するための実用的な方法を紹介します。

なぜトラフィック消費が解析にとって重要なのか

ほとんどのプロキシプロバイダーは、リジデントプールやモバイルプールを含め、トラフィックをGB単位で課金します。これは、あなたがウェブサイトを解析するために使用するツールがプロジェクトの予算に直接影響を与えることを意味します。ヘッドレスブラウザはページ全体を読み込みます：HTML、CSS、JavaScript、画像、フォント、分析スクリプト、広告バナー、トラッカー。requestsのようなHTTPクライアントは、明示的に要求したものだけをダウンロードします — 通常は純粋なHTMLドキュメントです。

この違いは特にスケールで顕著です。WildberriesやOzonの商品のカードを解析したり、競合の価格を収集したり、Googleの検索結果を監視したりする場合、1000ページのボリュームは1つのスクリプトの典型的な日次ノルマです。月に数十万ページを扱う場合、トラフィックの節約は特にリジデントプロキシを使用する場合において、顕著なコスト項目になります。

追加の複雑さは、現代のウェブサイトがボットからの保護を強化していることです：JavaScriptのレンダリング、マウスの動き、キャンバスフィンガープリンティングを確認します。これにより、開発者は単純なHTTPリクエストからPlaywrightやPuppeteerのような完全なブラウザに移行せざるを得なくなり、トラフィックが大幅に増加します。正確な数字を理解することで、プロキシの予算を事前に計算し、特定のタスクに適したツールを選択するのに役立ちます。

トラフィック測定の方法

公平な比較のために、私は同じ1000のURLリストを使用しました — 中程度の複雑さの商品のカードで、画像、分析スクリプト、いくつかのサードパーティウィジェットが含まれています（eコマースサイトの典型的な構造）。トラフィックの測定は、システムネットワークモニターと各ツールに組み込まれたリクエストのロギング機能を使用して行いました。

実験の重要な条件：

  • ブラウザのキャッシュは無効にされており — 各ページは「ゼロから」読み込まれ、異なるIPのプロキシのローテーションを通じて作業する場合と同様です
  • すべてのブラウザテストでヘッドレスモードが有効になっています — これはほとんどのプロダクションスクリプトの動作方法です
  • 基本シナリオではリソースのブロックは行わず — 最適化なしで「クリーン」な消費を示すために
  • すべての3つのツールで同じネットワークと同じページセットを使用

このアプローチは、あなた自身のケースに適用できる比較可能な数字を提供します — あなたのプロジェクトのページ数に掛け算し、プロキシの料金のボリュームで割ることができます。

requests: 最小トラフィック消費

Pythonのrequestsライブラリは、HTTPレスポンスのボディのみをダウンロードします — 明示的に要求したものです。JavaScriptはなく、画像もなく、CDNへの追加リクエストもありません。私のテストでは、eコマース商品の1つのHTMLページの平均サイズは約180〜250KBの未圧縮HTMLでした。 

import requests

proxies = {
    "http": "http://user:pass@proxy_host:port",
    "https": "http://user:pass@proxy_host:port",
}

headers = {
    "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36"
}

total_bytes = 0
urls = load_urls_from_file("urls.txt")  # 1000のリンクのリスト

for url in urls:
    response = requests.get(url, headers=headers, proxies=proxies, timeout=15)
    total_bytes += len(response.content)

print(f"合計ダウンロード: {total_bytes / 1024 / 1024:.2f} MB")

1000ページでの最終的な消費は 190-230 MB であり、つまり0.25 GB未満です。これは最も経済的なオプションですが、重要な制限があります：サイトがJavaScriptを介してコンテンツをレンダリングする場合（React、Vue、動的な価格の読み込み）、requestsは必要なデータのない空のページの骨組みを取得します。静的HTMLやSSRを持つサイトには、トラフィックと結果の比率において理想的な選択です。

Puppeteer: ヘッドレスChromeのトラフィック

Puppeteerは実際のChromiumエンジンを制御するため、ページ全体を読み込みます：HTML、CSS、フォント、画像、トラッキングスクリプト、広告iframe。ヘッドレスモードでも、ブラウザは通常のユーザーがChromeで行うすべてのネットワークリクエストを実行します。 

const puppeteer = require('puppeteer');

(async () => {
  const browser = await puppeteer.launch({
    headless: 'new',
    args: ['--proxy-server=http://proxy_host:port']
  });

  const page = await browser.newPage();
  await page.authenticate({ username: 'user', password: 'pass' });

  let totalBytes = 0;
  page.on('response', async (response) => {
    try {
      const buffer = await response.buffer();
      totalBytes += buffer.length;
    } catch (e) {}
  });

  const urls = require('./urls.json'); // 1000のリンク

  for (const url of urls) {
    await page.goto(url, { waitUntil: 'networkidle2', timeout: 30000 });
  }

  console.log(`合計トラフィック: ${(totalBytes / 1024 / 1024).toFixed(2)} MB`);
  await browser.close();
})();

私のテストでは、Puppeteerを通じて1ページの平均サイズは2.8〜4.5MBで、画像やサードパーティのスクリプトの数によって異なります。1000ページでの結果は 3.1-4.2 GB であり、requestsの15〜18倍です。トラフィックの大部分は画像（通常はページの重さの40〜55%）と、分析、広告、チャットウィジェットのサードパーティスクリプト（20〜30%）によって占められます。

Playwright: 異なるブラウザでのトラフィック

Playwrightは似たような方法で動作しますが、3つのエンジン（Chromium、Firefox、WebKit）をサポートしています。トラフィック消費はそれぞれ異なります：WebKitはヘッドレスモードで伝統的にメディアコンテンツの処理が異なるため少し経済的であり、Firefoxはリクエスト間のリソースキャッシュの違いから時々より多くのデータを読み込むことがあります。 

from playwright.sync_api import sync_playwright

total_bytes = 0

def handle_response(response):
    global total_bytes
    try:
        body = response.body()
        total_bytes += len(body)
    except Exception:
        pass

with sync_playwright() as p:
    browser = p.chromium.launch(
        headless=True,
        proxy={"server": "http://proxy_host:port", "username": "user", "password": "pass"}
    )
    page = browser.new_page()
    page.on("response", handle_response)

    urls = load_urls_from_file("urls.txt")
    for url in urls:
        page.goto(url, wait_until="networkidle", timeout=30000)

    print(f"合計トラフィック: {total_bytes / 1024 / 1024:.2f} MB")
    browser.close()

Chromiumを通じてPlaywrightでの結果はPuppeteerに近く、1000ページで 2.9-4.3 GB であり、これは両方のツールが同じエンジンを使用しているため理にかなっています。WebKitではトラフィックが10〜15%低く、約 2.6-3.7 GB であり、Firefoxでは少し高く、 3.3-4.6 GB です。違いは、フォントの処理、画像のデコード、各ブラウザエンジンのネットワークスタックの動作の違いによって説明されます。

比較表: 1000ページあたりのGB

以下は、テストされたすべてのオプションの要約表で、実用的な範囲に丸められています。数字は、画像と標準的なサードパーティスクリプトのセットを持つ平均的なeコマースページに対して有効です — ニュースサイトやビデオのあるランディングページでは消費が増加します。

ツール 1000ページあたりのトラフィック JSレンダリング ボット検出の回避
requests (Python) 0.19-0.23 GB いいえ 弱い
Playwright (WebKit) 2.6-3.7 GB はい 中程度
Puppeteer (Chromium) 3.1-4.2 GB はい 中程度
Playwright (Chromium) 2.9-4.3 GB はい 良好
Playwright (Firefox) 3.3-4.6 GB はい 中程度

重要な結論：サイトが必要なデータを取得するためにJavaScriptのレンダリングを必要としない場合、requestsはどのブラウザソリューションと比較しても15〜20倍のトラフィックを節約します。しかし、コンテンツが動的に読み込まれる場合や、サイトがブラウザの動作を積極的に確認する場合は、ブラウザレンダリングのトラフィックに対して支払わなければなりません。

トラフィック消費を5〜10倍削減する方法

完全なブラウザが必要な場合でも、必要なデータを失うことなくトラフィック消費を大幅に削減できます。以下は、私が同じ1000ページのセットで確認した実用的なテクニックです。

1. 画像、フォント、メディアのブロック。 画像は通常、ページの重さの半分以上を占め、テキストデータを解析するためには必要ありません。 

await page.route('**/*', (route) => {
  const type = route.request().resourceType();
  if (['image', 'font', 'media'].includes(type)) {
    route.abort();
  } else {
    route.continue();
  }
});

このテクニックはPlaywrightとPuppeteerの両方で同様に機能し、HTMLとテキストデータを失うことなくトラフィックを40〜60%削減します。

2. サードパーティドメインのブロック。 広告ネットワーク、分析、チャットウィジェットは、自分自身のスクリプトや画像を読み込みますが、あなたには必要ありません。ドメインでリクエストをフィルタリングし、主要なリソースとそのCDNだけを残すことができます。

3. "networkidle"の代わりに"domcontentloaded"を使用。 ネットワークの完全な読み込みを待つことは、ブラウザにすべてのバックグラウンドリクエストを待たせます。データがDOMに早く表示される場合は、より早いイベントに切り替えることで解析を加速し、余分な読み込みを削減できます。

4. リクエスト間の静的リソースのキャッシュ。 サイトがすべてのページで同じCSS/JSファイルを使用している場合、ブラウザのキャッシュを有効にすることで（私たちのテスト条件とは異なり）、同じドメインの多数のURLを順次巡回する際にかなりのボリュームを節約できます。

5. ハイブリッドアプローチ。 多くのチームは最初にrequestsを試し、データが不足している場合にのみ特定のページに切り替えます。これにより、低い基本トラフィック消費と、必要な場合にレンダリングする能力を組み合わせることができます。

適切なリソースのブロックを行うことで、PuppeteerとPlaywrightのトラフィック消費は1000ページあたり3〜4GBから0.6〜1.2GBに削減され、requestsと比較して差がかなり小さくなり、同時にJSレンダリングとボット対策の機能を維持できます。

トラフィック量に応じたプロキシの選び方

トラフィックの計算は、プロキシの種類の選択に直接影響します。静的サイトでrequestsを介した軽いHTTPリクエストには、データセンターのプロキシが適しています — それらは高速で、トラフィックが安価であり、サイトが行動信号をチェックしない場合には十分です。

PlaywrightやPuppeteerを介してボット対策システムを回避するために完全なレンダリングが必要な場合 — 例えば、マーケットプレイスでの価格収集や検索エンジンの結果の監視の場合 — リジデントプロキシを使用するのが賢明です。これらはIPの評判によってブロックされることが少なく、各リクエストが数メガバイトの重さを持ち、ブロックによるデータの再取得が高コストになる場合には重要です。

特にサイトがIPとユーザーエージェントの一致を厳しく確認するシナリオ（銀行サービス、モバイル認証を伴うアプリ）では、モバイルプロキシを検討する価値があります — トラフィックコストが高くなるにもかかわらず、IPアドレスの信頼性を最大限に高め、禁止による再リクエストの数を最小限に抑えます。

実用的な指針： "1ページの重さ × ページ数 × エラーや禁止による再試行の係数"の式でトラフィック量を計算し、最終的なGBをプロバイダーの料金と比較してください。上記のリソースの最適化は、通常、より安価なプロキシタイプの選択よりも多くの節約を提供します — しかし、正しいツールと正しいプロキシの組み合わせが最大の効果をもたらします。

結論

requestsはトラフィックに関して最も経済的なツールであり、1000ページあたり約0.2GBですが、動的コンテンツのあるサイトには適していません。PuppeteerとPlaywrightは完全なレンダリングと優れた保護回避を提供しますが、トラフィック消費は同じ1000ページで3〜4.5GBに増加します。画像、フォント、サードパーティドメインのブロックにより、このギャップは3〜5倍に縮小され、必要なデータを保持します。

大規模な解析を開始する前に、選択したツールを考慮して期待されるトラフィック量を計算し、それをプロキシの予算に組み込んでください。タスクがJavaScriptのレンダリングとボット対策システムへの耐性を必要とする場合は、リジデントプロキシを介して小規模なページセットでテストを開始することで、完全なデータ量での実際のGB消費を正確に評価できます。