为什么要提供 1x1 像素的 GIF(网络错误)数据? [英] Why serve 1x1 pixel GIF (web bugs) data at all?

查看:26
本文介绍了为什么要提供 1x1 像素的 GIF(网络错误)数据?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

许多分析和跟踪工具都要求使用 1x1 GIF 图像(网络错误,对用户不可见)用于跨域事件存储/处理.

Many analytic and tracking tools are requesting 1x1 GIF image (web bug, invisible for the user) for cross-domain event storing/processing.

为什么要提供这个 GIF 图像?简单地返回一些错误代码(例如 503 Service Temporary Unavailable)不是更有效率吗?em> 还是空文件?

Why to serve this GIF image at all? Wouldn't it be more efficient to simply return some error code such as 503 Service Temporary Unavailable or empty file?

更新: 更清楚地说,我问的是为什么在请求标头中已经发送了所有所需信息的情况下提供 GIF 图像数据.GIF 图像本身不会返回任何有用的信息.

Update: To be more clear, I'm asking why to serve GIF image data when all information required has been already sent in request headers. The GIF image itself does not return any useful information.

推荐答案

Doug 的回答非常全面;我想我会添加一个额外的注释(应 OP 的要求,在我的评论之外)

Doug's answer is pretty comprehensive; I thought I'd add in an additional note (at the OP's request, off of my comment)

Doug 的回答解释了为什么 1x1 像素信标用于它们的用途;我想我会概述一种潜在的替代方法,即使用 HTTP 状态代码 204,无内容作为响应,而不是发送图像正文.

Doug's answer explains why 1x1 pixel beacons are used for the purpose they are used for; I thought I'd outline a potential alternative approach, which is to use HTTP Status Code 204, No Content, for a response, and not send an image body.

204 无内容

服务器已完成请求但不需要返回实体主体,并且可能想要返回更新的元信息.响应可能包括新的或更新的元信息形式实体标题,如果存在应该与请求的变体.

The server has fulfilled the request but does not need to return an entity-body, and might want to return updated metainformation. The response MAY include new or updated metainformation in the form of entity-headers, which if present SHOULD be associated with the requested variant.

基本上,服务器收到请求,并决定不发送正文(在这种情况下,不发送图像).但是它会回复一个代码来通知代理这是一个有意识的决定;基本上,它只是一种更短的肯定回应方式.

Basically, the server receives the request, and decides to not send a body (in this case, to not send an image). But it replies with a code to inform the agent that this was a conscious decision; basically, its just a shorter way to respond affirmatively.

来自 Google 的 Page Speed 文档:

一种流行的页面记录方式异步方式的视图是在目标页面的底部(或作为onload 事件处理程序),通知当用户加载时记录服务器页.最常见的做法这是构造一个请求服务器的信标",并编码所有感兴趣的数据作为参数信标资源的 URL.到保持 HTTP 响应非常小,一个透明的 1x1 像素图像很好信标请求的候选者.一个稍微更优化的信标将使用HTTP 204 响应(无内容")略小于 1x1动图.

One popular way of recording page views in an asynchronous fashion is to include a JavaScript snippet at the bottom of the target page (or as an onload event handler), that notifies a logging server when a user loads the page. The most common way of doing this is to construct a request to the server for a "beacon", and encode all the data of interest as parameters in the URL for the beacon resource. To keep the HTTP response very small, a transparent 1x1-pixel image is a good candidate for a beacon request. A slightly more optimal beacon would use an HTTP 204 response ("no content") which is marginally smaller than a 1x1 GIF.

我从来没有尝试过,但理论上它应该具有相同的目的,而无需传输 gif 本身,在 Google Analytics 的情况下为您节省 35 个字节.(从总体上看,除非您使用 Google Analytics,否则每天要处理数万亿次点击,否则 35 字节真的算不了什么.)

I've never tried it, but in theory it should serve the same purpose without requiring the gif itself to be transmitted, saving you 35 bytes, in the case of Google Analytics. (In the scheme of things, unless you're Google Analytics serving many trillions of hits per day, 35 bytes is really nothing.)

您可以使用以下代码进行测试:

You can test it with this code:

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

这篇关于为什么要提供 1x1 像素的 GIF(网络错误)数据?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆