这是一个非常经典的前端技术细节问题，也是早期前端性能优化的极致体现。
选择 1x1 GIF 而不是 PNG 或 JPG，核心原因只有一个字：小。
虽然现在的网络带宽已经很大了，但在海量的数据上报请求（如亿级 PV 的网站）中，每一个字节的节省都能带来巨大的流量成本下降。
以下是详细的技术对比分析：
1. 体积对比（决定性因素）
这是最主要的原因。对于一个 1x1 像素的透明图片，不同格式的最小合法文件大小（包含文件头信息）差异很明显：
-
GIF : 最小约为 35 bytes（有些优化版本甚至只需 35-43 字节）。
-
PNG : 最小约为 67 bytes。
-
JPG : 最小通常在 几百 bytes 以上（因为 JPG 包含复杂的色彩表和压缩算法头信息，且不支持透明）。
-
BMP: 即使是最小也比 GIF 大。
结论 ：GIF 比 PNG 小了近 50% 。如果你的应用每天发送 1 亿次上报，使用 GIF 相比 PNG 可以节省大约 3GB 的用户流量和服务器宽带。
2. 透明度支持
监控上报通常要求"无感"，虽然我们通常不把这个图片插入到 DOM 中（只在 JS 内存里 new Image()），但万一代码逻辑需要将其渲染出来，或者为了防止意外显示：
-
GIF & PNG: 支持透明（Transparent）。生成的 1x1 图片可以是完全透明的，对页面视觉无影响。
-
JPG : 不支持透明。它必须有颜色（比如白色或黑色），如果意外显示在页面上，会是一个噪点。
3. 兼容性与处理机制
虽然现在所有浏览器都支持 PNG，但在十几年前（IE6 时代），GIF 的兼容性是绝对王着。此外：
-
解码速度：GIF 格式非常简单，浏览器解码 1x1 的 GIF 几乎不消耗 CPU 资源。
-
请求特性：图片请求（GET）天然跨域，不需要配置 CORS，也不会阻塞页面加载（相比于同步的 XHR）。
总结
尽管在 HTTP/2 时代头部压缩让这点体积差异变得不那么敏感，但 1x1 GIF 已经成为了业界的标准惯例（Best Practice）。
所以，当你看到监控代码里写着 img.src = '.../log.gif' 时，这不仅仅是一个图片，更是前端工程师对性能极致追求的历史遗留见证。