你的浏览器压缩和解压数据有多快？四组固定数据集——纯文本、结构化 JSON、半随机二进制数据和一张合成照片——各自用 gzip 或 JPEG 先压缩后解压，所有访问者的工作量都相同。总用时越短越好。
无损数据压缩是计算领域默默无闻的主力之一：每一次下载的更新、每一个通过 HTTPS 传输的网页、每一个用户双击打开的文件，都依赖于一种能足够快地发现并去除数据冗余、让人几乎察觉不到的算法。gzip 和 ZIP 使用的 DEFLATE 算法发布于上世纪 90 年代初，至今仍是互联网上使用最广泛的压缩格式，恰恰因为它在压缩率与速度之间取得了务实的平衡，而不是不惜一切代价追求最佳压缩率。
这个基准测试直接检验这一平衡：三组固定数据集——一段生成的伪英文文本、一个结构化的 JSON 记录数组，以及一个内部重复很少的半随机二进制缓冲区——使用浏览器自带的原生 gzip 实现连续多次压缩和解压。第四组数据是以同样的确定性方式生成的、类似照片的合成图片，它改为通过浏览器的 JPEG 编码器和解码器处理：这是一种基于 DCT 的有损编解码器，针对照片细节而非 gzip 的字节级冗余设计，因此会用到浏览器的另一部分。所有数据集都由带种子的伪随机源生成，因此每位访问者的输入完全相同。
得分是八个步骤合计的实际用时（毫秒），用 performance.now() 测量：越低越好。上方的表格会随着每一步的完成逐步填入其用时，因此某台设备在一种编解码器上很快、在另一种上很慢的情况会清楚地显示出来，而不会被隐藏在一个合计数字里。