本文是三部系列研究Data URIs的在移动方面性能的最后一篇。你可以看看我以前的帖子：
在手机上，Data URI比比链接图片慢6倍 不要责怪Data-URI因为它是基于Base64的。
大约一个月前，我做了一些研究，以了解为什么我所看到使用Data URI的表现不佳。我的结果发布后，从更广泛的网络性能界更深入的问题是：
“好吧，你怎么看Data-URI技术，仅仅是减少页面上的HTTP请求数吗？”
问题有很大的意义 - CSS中使用Data-URI作为一种替代的当今最典型的图片引用，已经成为I今天在网页设计的习惯，虽然它不是他们唯一的用途：例如，数据URI可以放置其他如JavaScript资源。
为了提供一个对这个问题的回答，我进一步的研究了Data-URI 。在这篇文章中，我将提供更多的场景上，为什么数据URI的性能是一个重要问题，有关实验的一些额外的细节，当然，Data-URI或CSS切片更多的在移动上面性能的比较。
CSS Sprites 回顾
对于那些不熟悉的术语， CSS Sprites是由戴夫·谢伊，在2004年到Web带来的图片管理技术。 CSS切片提供了一个巧妙的办法，在一个页面只使用一个HTTP请求并包括多个图像。
为什么要花费这么多时间的Data-URI性能？这不是一个很小的方面吗？
一点也不！事实证明，使用Data-URI与另一种技术的性能差异可以很容易地造成100ms的差异，
我的研究小组发现，跟我们看到在桌面环境中不同，他在手机的性能性能表现不佳。
进一步分析发现，一个显着的性能差异造成的原因发生在：使用JavaScript实例化Data-URI的实体时，而不是里面的脚本元素的文本节点。
这是非常意外的现象 - 团队中的每个人都知道有没有base64编码应该使用极少量的额外开销。于是我开始调查问题是否具体到JavaScript ，或者如果有更一般的性能问题，围绕使用Data-URI所消耗的网络资源。
Data-URI的性能提升最重要一方面是减少了HTTP的请求。Data-URI经常使用在小图标方面。但据我所知，目前没有在一个页面中使用Data-URI资源的大小或数量的指导上限。
在一个更广泛的背景下看，我们知道，谷歌Chrome团队，苹果Safari团队， Firefox团队， WebKit的开发人员，微软的Internet Explorer都做一个可怕的工作，建设速度更快的浏览器供我们使用 - 作为Web开发人员从来没有这么好过。因此，至关重要的是，开发人员都知道的性能配置不同的技术，使他们能够正确地应用它们。
虽然浏览器提供一个抽象的环境，减少了开发人员的实施细节，但开发仍有很多事情，他们需要了解浏览器的行为, 尤其是我们的目标是设计移动友好的网站，在不到一秒的时间内将内容呈现！
实验方法
要比较Data-URI和CSS Sprites，我感兴趣的是他们在有无缓存方面的差异。
这个实验，我的目标是尽可能接近真实的场景。为此，我选择了一个实际CSS 切片，在互联网上最大的电子商务商店：亚马逊使用。这个CSS Sprites是约25KB的大小，并包含39个不同的图像。
我创建了两个HTML放入iframe中加载。第一iframe包含CSS来指定Sprites每个单独的子画面作为背景图像的位置和偏移量。第二iframe包含内嵌base64编码的URI相同的图像数据。我已经提供了链接到HTML中使用的框架，放在这篇文章的底部，在资源部分在测试中使用的Sprites。使用gzip压缩。
我们会测量开始于iframe被实例化（ SRC =属性分配时）和结束的iframe加载事件被触发时的间隔。定时的精度到毫秒的日期对象，这已经足够测试性能。
这个实验测试Data-URI和Sprites的未缓存时的情况，一种四个Test Case。每个Test Case在一个独立的iframe 。数据URI和CSS雪碧条件被随机分配，但缓存的测试条件始终未缓存的情况发生后，立即利用已经完成的工作。这样做是使用一个单独的iframe的父窗口之间的缓存和未缓存的条件保持不变。下面的缓存控制头使用的上的iframe HTML内容的所有条件和CSS精灵的所有资源，包括：
我们一共收集分析了2.8亿个样本。
结果与结论
Data-URI与CSS Sprites测试结果
有趣的是，要在数据未缓存的条件下几乎所有的所有浏览器的中CSS Sprites都比Data-URI快几百毫秒左右 。这是CSS Sprites的事实，尽管它需要一个额外的连接，包括TCP重启动招致所有相关的连接开销！
从结果我们可以看到，在Android 4.2和iOS 6缓存条件下，CSS Sprites在Android 4.2原生浏览器中提升了大约2倍的性能为，在iOS中差70ms～220ms内。 Android上的Chrome浏览器和火狐好一点，约50 〜 60毫秒的性能差异。
铭记，这是只有25KB的Sprites，你可以看到显着的性能差异，两者之间的条件。一般情况下，性能将是线性变化的，如果移动数据URI的大型图像或脚本，对性能的影响是显着的。
基于这项研究，我建议限制使用小Data-URI，15 - 20KB的数据，不超过3 - 5个实例，在移动端这似乎是一个很好的经验法则！
在手机上，Data URI比比链接图片慢6倍 不要责怪Data-URI因为它是基于Base64的。
大约一个月前，我做了一些研究，以了解为什么我所看到使用Data URI的表现不佳。我的结果发布后，从更广泛的网络性能界更深入的问题是：
“好吧，你怎么看Data-URI技术，仅仅是减少页面上的HTTP请求数吗？”
问题有很大的意义 - CSS中使用Data-URI作为一种替代的当今最典型的图片引用，已经成为I今天在网页设计的习惯，虽然它不是他们唯一的用途：例如，数据URI可以放置其他如JavaScript资源。
为了提供一个对这个问题的回答，我进一步的研究了Data-URI 。在这篇文章中，我将提供更多的场景上，为什么数据URI的性能是一个重要问题，有关实验的一些额外的细节，当然，Data-URI或CSS切片更多的在移动上面性能的比较。
CSS Sprites 回顾
对于那些不熟悉的术语， CSS Sprites是由戴夫·谢伊，在2004年到Web带来的图片管理技术。 CSS切片提供了一个巧妙的办法，在一个页面只使用一个HTTP请求并包括多个图像。
为什么要花费这么多时间的Data-URI性能？这不是一个很小的方面吗？
一点也不！事实证明，使用Data-URI与另一种技术的性能差异可以很容易地造成100ms的差异，
我的研究小组发现，跟我们看到在桌面环境中不同，他在手机的性能性能表现不佳。
进一步分析发现，一个显着的性能差异造成的原因发生在：使用JavaScript实例化Data-URI的实体时，而不是里面的脚本元素的文本节点。
这是非常意外的现象 - 团队中的每个人都知道有没有base64编码应该使用极少量的额外开销。于是我开始调查问题是否具体到JavaScript ，或者如果有更一般的性能问题，围绕使用Data-URI所消耗的网络资源。
Data-URI的性能提升最重要一方面是减少了HTTP的请求。Data-URI经常使用在小图标方面。但据我所知，目前没有在一个页面中使用Data-URI资源的大小或数量的指导上限。
在一个更广泛的背景下看，我们知道，谷歌Chrome团队，苹果Safari团队， Firefox团队， WebKit的开发人员，微软的Internet Explorer都做一个可怕的工作，建设速度更快的浏览器供我们使用 - 作为Web开发人员从来没有这么好过。因此，至关重要的是，开发人员都知道的性能配置不同的技术，使他们能够正确地应用它们。
虽然浏览器提供一个抽象的环境，减少了开发人员的实施细节，但开发仍有很多事情，他们需要了解浏览器的行为, 尤其是我们的目标是设计移动友好的网站，在不到一秒的时间内将内容呈现！
实验方法
要比较Data-URI和CSS Sprites，我感兴趣的是他们在有无缓存方面的差异。
这个实验，我的目标是尽可能接近真实的场景。为此，我选择了一个实际CSS 切片，在互联网上最大的电子商务商店：亚马逊使用。这个CSS Sprites是约25KB的大小，并包含39个不同的图像。
我创建了两个HTML放入iframe中加载。第一iframe包含CSS来指定Sprites每个单独的子画面作为背景图像的位置和偏移量。第二iframe包含内嵌base64编码的URI相同的图像数据。我已经提供了链接到HTML中使用的框架，放在这篇文章的底部，在资源部分在测试中使用的Sprites。使用gzip压缩。
我们会测量开始于iframe被实例化（ SRC =属性分配时）和结束的iframe加载事件被触发时的间隔。定时的精度到毫秒的日期对象，这已经足够测试性能。
这个实验测试Data-URI和Sprites的未缓存时的情况，一种四个Test Case。每个Test Case在一个独立的iframe 。数据URI和CSS雪碧条件被随机分配，但缓存的测试条件始终未缓存的情况发生后，立即利用已经完成的工作。这样做是使用一个单独的iframe的父窗口之间的缓存和未缓存的条件保持不变。下面的缓存控制头使用的上的iframe HTML内容的所有条件和CSS精灵的所有资源，包括：
我们一共收集分析了2.8亿个样本。
结果与结论
Data-URI与CSS Sprites测试结果
有趣的是，要在数据未缓存的条件下几乎所有的所有浏览器的中CSS Sprites都比Data-URI快几百毫秒左右 。这是CSS Sprites的事实，尽管它需要一个额外的连接，包括TCP重启动招致所有相关的连接开销！
从结果我们可以看到，在Android 4.2和iOS 6缓存条件下，CSS Sprites在Android 4.2原生浏览器中提升了大约2倍的性能为，在iOS中差70ms～220ms内。 Android上的Chrome浏览器和火狐好一点，约50 〜 60毫秒的性能差异。
铭记，这是只有25KB的Sprites，你可以看到显着的性能差异，两者之间的条件。一般情况下，性能将是线性变化的，如果移动数据URI的大型图像或脚本，对性能的影响是显着的。
基于这项研究，我建议限制使用小Data-URI，15 - 20KB的数据，不超过3 - 5个实例，在移动端这似乎是一个很好的经验法则！
回复 (0)
微信扫码 立即评论
