CSS Sprites vs. Data URIs:在移动端，谁更快？

CSS spriting 是由 CSS Zen Garden的创始人，Mobify的用户体验副总裁 Dave Shea在2004年引入到网页中的图像管理技术。CSS spriting提供了一个巧妙的办法，在加载一个包含多个图片的页面上只需使用一个HTTP请求而不需要JavaScript代码。

为什么要在Data URI性能上花费如此多的时间? 难道它不是一个次要的细节吗?

CSS Sprites vs. Data URIs:Which is Faster on Mobile?

绝非如此！事实证明，使用data URI与别的技术之间的性能差异，可以轻易的小于100ms 交互性预算 ，这被Jakob Nielson，用户体验领袖之一，描述为用户感觉立即发生的一次交互间隔。

我第一次遇到data URI性能局限问题，是在一个现实的生活环境。当测试一个系统对web资源的管理时，比如管理在本地存储(localStorage)中的JavaScript，我的团队发现手机上获得的性能，与我们在桌面环境中所看到的并不匹配。

进一步的分析揭示出这样的一个事实，我们将JavaScript实体实例化为data URIs，而不是位于脚本元素之中的文本节点，将会导致显著的性能差异。

这是很不被期望的行为——团队的每个人都知道，base64编码为什么会创建少许的额外开销，这并没有什么基本原因。所以我开始研究是否这个问题可以归因于JavaScript，或者对于用data URIs访问web资源来说，是否具有更多通用性能问题。

data URIs的性能对于任何web设计师，或者应用最佳实践减少HTTP请求的web应用程序开发人员来说，是非常重要的。Data URIs最常用于保存在网站上的小图片，但我不知道什么事先准则，可以给设计师提供页面中data URIs所使用的资源的大小或者数量的上限。

在更大的背景下看一下它，我们知道Google Chrome 团队,Apple Safari 团队, Firefox 团队, WebKit 开发者 以及Microsoft Internet Explorer都在做一个很棒的工作,构建快速的浏览器供我们使用——而且作为一个web开发人员来说从来也没有做得这么好。因此开发者知道不同技术的性能概要是必要的，这样他们就可以正确的应用它们。

当浏览器提供了一个抽象的环境，使开发人员从实现细节解脱出来时，关于浏览器的行为，仍然有许多开发者需要知道的事情——特别当目标是要设计一个在一秒钟内渲染折叠线以上内容的、移动友好的网站时！

实验方法

为了回答data URIs相比CSS spriting到底如何的问题，我对两个问题很感兴趣，一个是第一次加载时间（未缓存条件下），另一个是当资源被浏览器缓存时，可能存在的持续的性能差异。

我做这个实验的目的是获得尽可能接近真实世界的场景。为了这个目的，我选择了互联网上最大的电子商务商店：Amazon.com 所使用的一个实际的 sprite。这个sprite大约25KB大小小，包含39个单独的图像。

为了进行测试，我创建了两个 iframe：第一个 iframe 加载的页面指定了 sprite 图片文件的地址、设定了用作 sprite 背景的相对位置的布局属性（每个 sprite 的偏移量）；第二个 iframe 则使用相同图片的 base64 编码的 Data URI 代替。在测试的最后可以看到以上两个文件的连接地址。 HTML 内容使用 gzip 压缩。

性能测试在 iframe 初始化之前开始（当 src 属性被赋值的时候），在 iframe 的 load 事件响应后结束。虽然手机里的 iOS 系统并没有提供 navigation timing API，计时的精确度只限于 Date 对象的微秒级别，但对于这次测试来说还是卓卓有余的。

这次实验测试分别对缓存和非缓存进行测试，因此，总共 4 个实验条件。每个条件在一个独立的 iframe 中进行执行。 Data URI 和 CSS sprite 条件是随机生成的，但是缓存条件的测试总是在非缓存条件测试后进行的，主要是利用刚浏览的缓存优势。这是通过一个隔离的 iframe 共享父窗口常量同步缓存和非缓存数据来实现的。所采用的缓存控制参数（HTTP 头）如下：

Cache-Control: public, max-age=2592000 

本次分析共收集了 280 万个样本。

结论

非常有趣的是，在所有浏览器的非缓存的模式下， CSS sprite 方式比 data URI 方式快了数百微秒。但事实上 CSS Sprite 比 Data URI 方式多发送了一次连接请求，包括 TCP 慢启动招致所有相关的连接开销。

我们可以从结果中看到，缓存条件下 Android 4.2 和 iOS 6 的 CSS sprite 模式都有大概 2 倍的速度提升，只是 iOS 条件下减少了 220ms 而 Android 减少了 70ms （原生浏览器）。相对来说，Chrome 和 Firefox 的情况平衡得好点，缓存和非缓存情况下只有 50% 到 60ms 左右的性能差异。

记住这只是对 25kB sprite ，你可以看到两种条件下显著的性能差异。一般来说，性能是一系列 sprite 图片的尺寸，除了每一个单独的图片的固定代价之外的函数。如果你将大量图片或脚本移动到 data URIs 中，对性能的影响是显著的。

基于这个研究，我建议将 data URIs 用于非常小的资源，并且不在 CSS 和 内联 HTML 中好多次使用它们。15-20kB 是最大的 data URI 尺寸，对移动设备缩略图来说，不超过 3 - 5 个实例看起来是很好的准则!