有一些第三方站点，例如一些博客聚合站等，会提供统计像素（Tracking Pixel），形式为一个小体积的图片，将其插入到网页上之后，就可以统计网站的浏览量了。
最近笔者碰到统计量大幅下跌的问题，查阅资料，结果发现了现代浏览器的几个比较有趣的特性，会影响到此类统计像素的实际效果。比如说，你知道prefetch的意思是『先别加载』吗？
大幅下跌的访问量1. 前言
笔者很少在一天发两篇博文，但今天有些特殊。
具体来说是，在Umami后台统计今日访客UV有190+的情况下，引言中图片显示的UV只有53。通常来讲，考虑到统计方式不同，浏览器具体行为不同，访问量差个十几二十的很正常，但现在差了一百多，显然是出问题了。
回顾一下统计像素的统计原理：浏览器加载图片的时候，后台就能拿到请求的IP，User-Agent等信息，这样就可以计算一个哈希值，来匿名地（同时也是粗略地）标定一个用户了。不难看出，这一切的前提，就是浏览器发出了这个请求。如果浏览器根本不发出请求，统计像素根本无法统计，数量对不上的问题自然就出现了。
2. 一些常见的问题
虽然说这种基于img的统计像素已经比较少见，大多数都已经专为基于js的统计代码，以便更详细地检测各类统计信息。但在一些更注重隐私的场合（例如无法/关闭了执行js代码功能的浏览器环境），以及第三方统计站的情况下，统计像素依然存在。所以，还是尽量让他准确一些为好。
当然，说是说『几个问题』，但下面只列出来两个新碰到的问题，有些『无三不上几』之嫌。除了拟定标题的时候有些大意了之外，主要还是一些老生常谈的问题，比如『display:none可能导致不加载』，已经算是共识了；还有一些比如『加上decoding="async"让解码不阻塞渲染』之类的小技巧，因为不算是问题，所以也就简单提一嘴罢了。
2.1 不要 lazy
某博客聚合站给出的统计像素如下所示：
<img src="..." loading="lazy">这个属性会告诉浏览器，延迟加载此请求。对不同元素，具体行为有些差异，但对图片来说，默认就是『快要进入视窗范围内才加载』。
巧合的是，这个站点的统计像素实际上并非『像素』（即传统的1x1 GIF），而是一幅小图片，所以很多站长会把他放在页脚。问题来了，页脚是需要滚动很远才能到达的，添加loading="lazy"可能会让浏览器延迟很久才加载，甚至对于某些点开看看就走了的访客来说，根本就不会加载。
此外，雪上加霜的是，新一些的浏览器支持另外一个属性fetchpriority="low"，意思是降低资源优先级。本意上，你可能想要让统计像素加载过程不阻塞主页面渲染，因此稍后再加载，但如果同一个元素上还有loading="lazy"，这二者结合起来，可能会给浏览器错误信息，会误认为作者明确表示这东西完全不重要。从而加载更慢。特别地，如果访客用手机访问、弱网环境下访问、节电模式访问、省流量模式访问，再配合某些『把统计像素放在屏幕八百里开外』的CSS，上述组合可能导致统计像素根本不加载，使得统计完全失效。
2.2 小心prefetch
另外一个站点给出了一个『无图统计』的代码：
<link rel="prefetch" as="image" href="...">说是，只要放入<head>内，就可以利用现代浏览器预取机制，实现无图片统计。
然而，这种做法可能会导致统计效果更差。根据资料来看，现代浏览器倾向于把prefetch请求的优先级降低（甚至有说法称，会直接降到最低），只有在页面空闲（比如，有可能是，用户不操作）的时候，才会加载这部分内容。如果页面目前正忙，不好意思，同样不会加载。
另外，目前的主流的浏览器对『执行prefetch』的实现不完全一致，比如说，他可以决定：
- 网络空闲才执行
- WiFi才执行，开流量不执行
- 在前台才执行，后台不执行
- 电池模式，不执行
- 隐私模式，不执行
- 小站点，首次访问站点，信誉低，不执行
尤其是Chrome，近几年好像还在优化非关键资源的优先级分配，还有就是，部分浏览器，如Safari，不支持prefetch，对于这种依赖Prefetch的统计像素来说，更是雪上加霜。
所以可以认为，prefetch不适合『访问计数』的场景，请尽量避免使用。
3. 写在最后
简单记录一下这两个发现，应该能帮助各位站长排除故障。
去除上面那些属性之后，如果实在是不行，就把标签提上来一点，比如放在<body>开头处之类的地方，看看效果有没有改善吧。
（完）