【ITニュース解説】I measured how many pages fit in 1 GB of proxy traffic

Webサイトから情報を自動で収集するスクレイピングを行う際や、インターネットへのアクセスを中継するプロキシサービスを利用する際、「一体どれくらいのデータ通信量が必要になるのか」という疑問は多くの人が抱くことだろう。プロキシサービスの料金プランは通常、転送されたデータ量、つまりギガバイト（GB）単位で設定されていることが多い。しかし、実際にスクレイピングを行う側からすると、「何ページ分の情報を取得したら何GBになるのか」というページ単位での感覚が重要になる。このギャップを埋め、「状況による」といった漠然とした答えではなく、より具体的な目安を提供するために、ある測定が行われた。

この測定では、34種類の公開されているウェブページを対象に、どのような方法でページを取得するかによって、どれくらいのデータ量が必要になるかを詳細に調べた。対象ページは、ドキュメント、ニュース記事、ブログ投稿、フォーラムのスレッド、ECサイトの商品カテゴリや個別の商品ページ、さらにはJavaScriptで動作するアプリケーションなど、多岐にわたる。ウェブサイトのルールを示すrobots.txtで許可されているページのみを扱い、ログインが必要なページは含めなかった。

測定方法は大きく分けて三つのパターンが用いられた。一つ目は、標準的なHTTPクライアントツール（Requestsライブラリ）を使って、ページのHTMLデータのみをシンプルに取得する方法だ。これは、ウェブページの骨格となるテキスト情報を取得するイメージである。二つ目は、Playwrightというブラウザを自動操作するツールを使って、実際にウェブブラウザでページを閲覧するのと同じように、HTMLだけでなく、ページに含まれる画像、動画、フォント、JavaScriptファイル、CSSファイルなど、すべてのリソースを完全に読み込む方法だ。そして三つ目は、Playwrightを使用するが、画像、動画、フォントといったメディアファイルを意図的にブロックして読み込まないようにする方法である。これにより、ブラウザのフルロードから一部の重いリソースを除外した場合のデータ量を測定できる。

これらの測定は、各ページにつき3回ずつ、常に新しいプロセスを立ち上げ、キャッシュを空にした状態で実行された。これにより、合計306回のデータ取得が行われ、すべてが正常にページを読み込めた（HTTP 200ステータス）ことを確認している。データ量の計測には、「scrapescope」という自作のローカルプロキシツールが使われた。このツールは、ウェブアクセスを仲介する際に、TLS（暗号化通信のための技術）のオーバーヘッド、HTTPヘッダー情報、そしてクライアントからサーバーへのアップロードデータを含め、通信トンネル全体でやり取りされるすべてのバイト数を正確にカウントできる特徴を持つ。測定は2026年10月5日にフィンランドのヘルシンキから直接インターネットに接続して行われた。

測定結果の中央値を見ると、取得方法によって必要なデータ量が大きく異なることが明らかになった。HTTPクライアントでHTMLのみを取得した場合、1ページあたりに必要なデータ量は約22.7キロバイト（KB）で、1ギガバイトあたり約44,083ページを取得できる計算になる。一方、Playwrightでページを完全に読み込んだ場合、1ページあたり約1.10メガバイト（MB）と、データ量が大幅に増加し、1ギガバイトあたり約906ページしか取得できない。Playwrightで画像、メディア、フォントをブロックした場合でも、1ページあたり約454.6 KBとなり、1ギガバイトあたり約2,199ページという結果だった。この結果から、ブラウザでページを完全に読み込む方法は、HTMLのみを取得する場合と比較して、約49倍ものデータ量を消費することがわかる。

測定で特に注目すべき点が三つ挙げられている。一つ目は、ページのフルロード時におけるデータ量の内訳だ。多くの人は画像が最もデータ量を消費すると考えがちだが、実際にはスクリプト（JavaScriptなど）がデータ量の約49%を占め、画像、メディア、フォントを合計しても約35%にとどまった。画像などをブロックしてもデータ削減効果が28%と、予想よりも少なかったのは驚きだ。これは、リソースの読み込みに失敗した際に、ページが異なる挙動を見せる場合があるためと考えられる。例えば、特定のスクリプトが画像を代替表示したり、レイアウトを調整したりして、結果的に他のリソースの読み込みが増える可能性も示唆している。

二つ目は、サードパーティへのトラフィックの割合の大きさである。フルロード時のデータ量の約49.9%が、ページのコンテンツを提供する元のサーバーではなく、広告配信サービス、解析ツール、ソーシャルメディアのウィジェットなどを提供する「サードパーティ」のサーバーとの通信に費やされていた。特にGoogle Tag Managerは、測定対象の34ページ中17ページで使われており、1回の読み込みで約308 KBを消費し、これはフルロード時の全データ量の約12%を占めていた。これらのデータは、スクレイピングの目的からすると不要なものが多く、無駄な通信量として課金されてしまう可能性が高いことを示している。

三つ目は、データ圧縮の重要性である。測定対象のHTMLレスポンスはすべて圧縮されており、Brotli、gzip、zstdといった圧縮技術が使われていた。これにより、実際のHTMLドキュメントのサイズが展開後で83.5 KBあったとしても、ネットワーク上を流れるデータ量は平均で22.7 KBにまで削減されていた。このことは、クライアント側がサーバーにデータ圧縮を要求しない場合、より大きな未圧縮のデータ量を支払うことになる可能性を示唆しており、通信効率化の観点から圧縮技術が非常に重要であることがわかる。

また、データ量の計算では通常ダウンロード量に注目しがちだが、クライアントからサーバーへのアップロードトラフィックも考慮する必要がある。この測定では、HTMLのみの取得で全トラフィックの6.3%がアップロードに、ブラウザロードでは約3%がアップロードに費やされていた。この割合は小さいものの、プロバイダーによっては双方向のトラフィックを課金対象とする場合があるため、これもコストに影響する可能性がある。

これらの測定結果に基づき、自身のスクレイピング作業に必要なデータ量を概算するための計算式も提供されている。「1日あたりの総GB数 = 1日あたりのページ数 × 1ページあたりのバイト数 × 1ページあたりの試行回数 ÷ 1,000,000,000」という式で算出できる。例えば、ブラウザのフルロードで1日あたり50,000ページを取得する（1ページあたり1.10 MB、1ページあたり1.2回の試行を含む）場合、1日あたり約66 GBのデータ量が必要となる。同じ作業をHTTPクライアントで行う場合は、約1.4 GBで済む計算だ。この差は非常に大きく、スクレイピング戦略がデータコストに与える影響の大きさを物語っている。

もちろん、この測定結果は特定の条件（1つの地域、1日、34ページ、直接接続）に基づいているため、あくまで出発点として捉えるべきだ。プロキシの出口の場所、ウェブサイトによるブロック、リトライ処理などは含まれていない。また、ウェブサイトの内容は常に変化するため、今日の測定結果が明日も同じとは限らない。最も確実なのは、実際に自身のスクレイピング作業を「scrapescope」のようなツールを通して実行し、具体的なデータ量を確認することである。この測定と分析は、プロキシサービスを利用するシステムエンジニアやスクレイパーが、より賢明な判断を下すための貴重な情報を提供するものと言える。