なぜ1x1ピクセルのGIF(ウェブバグ)データを提供するのですか?質問する

なぜ1x1ピクセルのGIF(ウェブバグ)データを提供するのですか?質問する

多くの分析および追跡ツールは、クロスドメイン イベントの保存/処理に 1x1 GIF 画像 (Web バグ、ユーザーには見えない) を要求します。

そもそもなぜこの GIF 画像を提供するのでしょうか?そうではないでしょうかもっと効率的単に次のようなエラーコードを返すだけです503 サービスは一時的に利用できませんまたは空のファイルですか?

アップデート:もっと明確に言えば、必要な情報がすべて揃っているのに、なぜGIF画像データを提供するのかと尋ねているのです。すでに送信されていますリクエスト ヘッダー内。GIF 画像自体は有用な情報を返しません。

ベストアンサー1

ダグの回答は非常に包括的です。私は(OPのリクエストに応じて、私のコメントとは別に)追加のメモを追加しようと思いました。

Doug の回答では、1x1 ピクセルのビーコンが目的のために使用される理由が説明されています。私は、応答に HTTP ステータス コード 204 (コンテンツなし) を使用し、画像本体を送信しないという代替アプローチの可能性について概説したいと思います。

204 コンテンツなし

サーバーはリクエストを満たしましたが、エンティティ本体を返す必要はなく、更新されたメタ情報を返す必要がある場合があります。レスポンスには、エンティティ ヘッダーの形式で新しいメタ情報または更新されたメタ情報が含まれる場合があり、存在する場合は、要求されたバリアントに関連付けられる必要があります。

基本的に、サーバーはリクエストを受信し、本文を送信しないことを決定します (この場合は、画像を送信しません)。ただし、これは意識的な決定であったことをエージェントに通知するコードで応答します。基本的に、これは肯定的に応答するためのより短い方法にすぎません。

からGoogle のページスピードに関するドキュメント:

ページ ビューを非同期で記録する一般的な方法の 1 つは、ターゲット ページの下部 (または onload イベント ハンドラー) に JavaScript スニペットを追加して、ユーザーがページをロードしたときにログ サーバーに通知することです。これを行う最も一般的な方法は、サーバーに「ビーコン」の要求を作成し、ビーコン リソースの URL のパラメーターとしてすべてのデータをエンコードすることです。HTTP 応答を非常に小さく保つには、透明な 1x1 ピクセルの画像がビーコン要求の候補として適しています。少しだけ最適なビーコンは、1x1 GIF よりわずかに小さい HTTP 204 応答 (「コンテンツなし」) を使用します。

試したことはないのですが、理論上は、gif 自体を送信する必要がなく、同じ目的を達成できるはずです。Google Analytics の場合、35 バイト節約できます。(物事の仕組み上、1 日に何兆ものヒットを処理する Google Analytics でない限り、35 バイトは実際には大したことではありません。)

次のコードでテストできます:

var i = new Image(); 
i.src = "http://httpstat.us/204";

おすすめ記事