图片资源转换为base64格式后，可以直接加载到页面中作为首屏，也可以加载到css文件中，以减少请求，加快首屏渲染速度。
但是图片的base64化会带来臃肿的html或css文件，会不会影响页面的渲染性能，浏览器支持什么？
怎么算？
利用Navigation Timing记录的关键时间点来统计页面完成所花费的时间，并通过Chrome开发工具跟踪详细信息
以上定义来自chrome官方文档，其他环境下可能会有所不同。 从测试结果来看，在android+微信环境下，以下构建时间依然为0。 这可能是由于渲染机制的差异，所以这里不进行深入测试。 osx+chrome以外环境的数据仅供参考。
场景一、嵌入到css文件中
1.原来导入图片链接作为背景图片
将一张大小为50kb的jpg格式的图片应用到9x15=135个DOM作为背景图，模拟Sprite图片的模式，多个节点引用同一张图片作为背景，（示例）如图。
测试环境：Mac OS X EI Capitan 10.xx + Chrome 48.xx
其他辅助测试机：iPhone 6 plus iOS 9.xx； 魅族Note安卓4
实际使用中，其他版本和型号的Android手机还有待测试。
缓存关闭时，构建：150ms | 完成：200ms（总时间受网络状况等因素影响，数据用于对比
当缓存启用时，构建：7ms | 完整：59ms（包含以下稳定状态下多次测试的平均值，截图为最接近平均值的状态，默认数据来自Mac+Chrome[48.XX版本]）
2.导入base64格式的图片作为背景图片
将之前的50kb jpg图像转换为base64格式并添加到css文件中。
缓存关闭时，构建：80ms | 完成：280ms
启用缓存后，构建：160ms | 完成：210ms
3.调节图片音量
调整内部图像的（压缩质量）体积。 Base64化后背景图html，对应的css文件大小也会发生相应的变化。
4.调整参考文献数量
对于50kb的图像，在base64ization之后，调整使用该图像作为背景图像的DOM引用的数量。
分析总结：
在OSX+Chrome环境下，将50kb的图片base64成样式后，构建过程延长了约20倍。 使用Timeline工具可以看到，计算风格阻塞了整个过程。
1. 与直接导入图片地址相比，将base64格式图片导入到css文件中会消耗大量的样式渲染性能。 如果大量使用，会造成耗电、发热的问题，所以要谨慎使用。
2. Rendering消耗的时间几乎与css文件的大小和引用的数量成正比（其他极限情况未测试）。 在网络条件优质、RTT（往返流）为50~70ms的4G环境下，通常连接网络的情况会更糟糕。 对于首屏优化来说，正确使用还是值得的。
3.图像转换为base64编码后，文档大小比原文件大，但经过gzip后，两者几乎没有区别。
场景二、嵌入到js文件中
1.直接以原生形式加载多张图片
共9张图片，大小10~70kb。 总大小约300kb
关闭缓存：构建：300ms | 完成：310ms
打开缓存：构建：110ms | 完成：120ms
2. 转换为base64格式并合并请求
将里面的图片转换成base64，放到js文件中，加载进去。
关闭缓存：构建：0ms | 完成：400ms
启用缓存：构建：0ms | 完成：80ms
3、比较不同网速下同步请求和组合请求的加载效率
使用上述1和2测试demo在3G和4G网速条件下的测试结果如下：
在网络环境较差的情况下，组合请求显着降低整体加载时间；
网络环境较好的WIFI和4G下差别不大。
分析总结：
Base64后的js资源达到381kb，单线程加载需要花费大量时间。 从统计结果来看，渲染性能差异没有场景1那么显着。
但通过缓存背景图html，页面渲染完成得更快。
从Timeline上看细节，解析这个近400kb的js文件对整个渲染过程带来了一定的压力，但总的解析时间40ms是完全可以接受的。
1.直接引用图片链接和从html中引用base64图片在渲染性能上几乎没有区别。 在网络条件较差的情况下，合并请求可以大大提高加载效率；
2.直接引用html，无法缓存。 将base64后的图片资源放在js文件中进行管理，方便缓存。
3、缺点之一是图片资源base64需要扩展和完善才能支持。
建议
1、图片资源base64编码成css文件会带来一定的性能消耗，请谨慎使用。
2、将图片资源编码成js文件，管理和预加载H5应用的图片资源，合理的合并请求可以极大提升页面体验。
发表评论