Feature Photo by Patrick Tomasso on Unsplash
最早的时候我们继承了Krato的页面浏览量计算方式。Krato在wp_head()中写了一个函数，每次PHP构建页面时会触发函数更新数据库中存储的浏览量数据。它非常地简单，也非常地好用。但是在雪猫社迁移到Blocksy主题后，由于Blocksy的高自由度使它在服务端渲染中需要进行更多的运算，服务器的响应时间比Krato时代慢了不少。（未来会不会是静态前端资源+REST API的呢？）
为了挽救响应时间，雪先生加了静态页面缓存和一层CDN。虽然解决了响应时间的问题，但静态页面缓存意味着服务器不会再一次构建页面，也就完美破坏了原来基于页面构建的浏览量计算方式。并且，这种模式无法识别机器人以及重复刷新，也无法识别我们的缓存插件的预载（每天自动浏览量+1），Krato原先的算法甚至不会识别页面是否在preview状态，于是经常发生作者在还没有发布的时候往往就已经刷出了十几二十次的浏览量（这个问题在移植至Blocksy的时候顺带解决了）。这些都造成了其统计的浏览量的“虚高”。不过毕竟它只是个特别简单的实现方式，其实也不好对它更多的要求。
当然Krato这个浏览量统计还是比我们给微信小程序接入装的那个插件靠谱。那个插件每次接到显示文章详情的请求就更新浏览量的方式虽然和Krato是一致的，但是Wordpress REST API在“列出文章列表”的时候就会返回文章详情，这也就意味着你每次刷新目录都会导致这一页的所有文章的浏览量同时增加。
于是，我们把目光转向了很早就引入了的Google Analytics，也就是大家喜闻乐见的常常404卡住加载的ga.js。GA的好处自然不用多说，完善的统计功能以及数据分析，数据还可以通过API调用，还免费。于是我整了点React，在页面加载后把GA的数据hydrate()上去，对，用的是服务端渲染的同一个手段。具体如何调用GAAPI可以参考一下这篇文章《Hit count：用 Google Analytics + Vercel Serverless 为文章添加浏览量统计》，很棒的。
在优点不言而喻的同时，GA的缺点也蛮大的。由于谷歌并没有在国内展开服务，有时ga.js会无法加载上，导致浏览量漏记。不过在国内找到一家合理的页面统计服务商或者自建一个之前可能都会用GA来做统计了。
同时，GA为了做到简单部署，使用的是客户端脚本的方式。然而众所周知客户端脚本是很容易被欺骗的，API也有可能因为无法混淆的客户端脚本而被暴露（这也是REST API模式的弊端之一）。不过，在实际研究GA的脚本前也不好说这样的影响会有多大，可能虽然客户端脚本有这种理论风险，但是在页面统计这种实际应用中无关紧要，暂且就先作为一个疑问放在这里。
然而更加严格的GA桑无情地揭露了许多文章根本没人看的事实，这或许也是站长们在使用GA前要考虑的一点。
Comments NOTHING