炸弹倒计时

有过秒杀经历的朋友也许都深有体会，有时就慢那么1s，甚至零点几秒，就导致秒杀失败，前功尽弃，大家称之为“手慢无”，然而全归结于手慢吗？也许你的手很快，但依然抢不到。

这几天正好遇到这个问题，PC上秒杀倒计时慢1秒左右。

当时分析了下我们倒计时的实现方式，客户端倒计时的时间段是由服务端返回的，而服务端是计算的 开抢时间戳与服务器当前时间戳 的时间差。但是当在服务端计算好这个时间差后，还要执行一段服务端代码处理其它任务，再返回请求，并经过数据传输返回客户端、DOM装载、Javascript执行这一系列过程，等到执行倒计时那一段代码的时候，实际当前时间跟开标时间的时间差已经变小了，这就是导致误差的原因。

由此可判断，倒计时的误差跟网络环境有关，网络越慢，误差越大；跟浏览器性能有关，对于Trident内核的IE9及以下低级浏览器，误差会大一些；还跟服务端程序有关，计算好那个时间段后，是立即返回请求，还是要继续处理50ms任务再返回请求，误差会不一样，最好是计算好时间差后就立即返回请求。

对于网络环境，是不好控制的，即使使用cdn，还是会有差异。

然而，对于不同的浏览器，误差到底有多大呢？今天在同一网络环境下对各个浏览器做了个测试，每个浏览器之间的比较取3次数据。发现Firefox最快，Safari跟Chrome基本一样，比Firefox稍微慢一点点，大概0.1s左右，IE789最慢，比Firefox慢1到2秒。需要测试截屏数据的朋友可把邮箱发给我，或加我微信Hoogle8818.

建议参与秒杀的朋友们不要再用IE9及以下浏览器了，最好用最新版的Firefox，或者Safari和Chrome也行。同时建议秒杀类网站也给用户一个友好的提醒，建议他们使用Firefox、Chrome、Safari浏览器，IE9及以下浏览器就不要用了，不然不仅体验差，手快也可能无，害死人。

实现方式上也可以做一些改变，上面讲到的是计算好时间差，随着当前页document请求传输到客户端，当前页document一般会比较大，还要经过DOM装载、Javascript执行。如果document那个请求中只返回开抢时间，服务端再专门提供一个服务currentTime，返回服务器当前时间戳，客户端所有的倒计时，在执行js代码的时候，专门请求一下服务currentTime，再自己计算时间差，这样就避免了document文件传输耗时多、DOM装载、基础Javascript下载及执行带来的问题。

但是请求currentTime要时间，依然会有误差，但这个误差相对来说会小很多，基本可以认为是一个ajax请求的误差，一般是几十毫秒，如果再保守的加个5-10ms，误差应该就会非常非常小了。

文中有误请您提出，以免误人自误，同时欢迎提出其他建议，可发到个人微信Hoogle8818。

前端风暴（专注思考互联网、前端、产品、用户、生活）