基于WEB 的图片加载优化技术研究

2021-07-30李兰兰宋永鹏

电子设计工程 2021年14期

李兰兰，宋永鹏

（1.山东省气象服务中心，山东济南 250031；2.山东省气象信息中心，山东济南 250031）

HTTP Archive 统计显示，图片内容已经占到了互联网内容总量的62%，也就是说超过一半的流量和时间都用来下载图片。从性能优化的角度看，图片也是优化的重点和热点之一，Google PageSpeed 优化规则把图片优化作为重要的优化手段。传统的图片加载方式是通过Url 或者Src 属性加载图片地址，向服务器提出Http 请求[1]后下载图片至浏览器，图片站点的开发过程中，加载的图片过多会增加向服务器请求的次数而导致请求时间过长，对服务器和本地网络资源是极大的浪费；图片体积过大会使浏览器从上到下逐步显示图片直到图片完整呈现，这种从空白区域到完全加载的过程显得比较突兀会使用户体验较差[2]。基于Javascript 的懒加载和预加载是目前流行的图片优化技术，能够从页面前端的角度优化加载速度[3]；Base64 转码和图像压缩在后端和系统架构方面为图片站点的优化提供技术支持。该文的硬件测试环境是4G 内存的DELL 一体机，软件测试环境为Win7 操作系统、山东省气象部门图片资料云平台和Google Chrome。

1 Base64转码

Base64 是网络中常见的用于传输8 Bit 字节代码的编码方式，Base64 编码可用于在Http 环境下传递较长的标识信息，具有不可读性，即编码的数据无法直接查看，通过Html 的Img 图片标签的Src 属性和CSS 背景图片的Url 属性传递[4]。页面中的每一个图片需要先向服务器递交一个Http 请求，再进行图片的下载与显示，图片过多会导致Http 请求时间过长，而Base64 转码技术将图片在服务器中的保存地址通过编码表转换成一串字符，随着页面的Html 代码下载到本地，避免了向服务器进行Http 请求的时间消耗和网络资源的浪费。

1.1 Base64转码的两种运用

Base64 转码技术在图片站点中的应用有（图1所示，包含传统图片加载方式）两种方式：1）对用户上传的图片进行转码，将转码后图片的编码存储于服务器的数据库或文件中，用户访问图片时，前端浏览器会下载内联有Base64 编码字符串的Html 以显示图片；2）前端用户将图片上传至服务器后，后端应用将图片进行格式化存储，并将图片在服务器中的相对地址保存于数据库或文件中，前端用户对图片有Http 请求的时候，应用将图片的存储相对地址转换成Base64 编码字符串随Html 进行下载并加载至浏览器[5]。二者区别在于图片在服务器中的存储方式和前端的显示方式，前者保存、加载的是图片的编码，后者保存图片本身及其相对地址，加载的同样仅是相对地址的转码数据流。

图1 传统图片加载和Base64转码实现方式

上述程序实现Base64 转码的核心功能，代码将名为Source 的图片变量赋值给另一变量fp，目标变量经过函数Base64_encode 的转码后生成Base64 格式的数据流，之后将该数据流分配至图片标签img的Src 属性，通过img 标签加载至用户前端并显示，此时浏览器加载的字符串是图片储存相对地址的转码流或是图片本身的转码流，而不是图片存储于服务器中的相对地址[6]。

1.2 Base64转码的优势

由于测试环境平台已经上线运行，数据库中已储存了大量用户上传图片的相对地址，所以该文采取第二种Base64 转码方式并和传统图片加载方式进行性能对比。将数据库中存储的图片在服务器中的相对地址转码后，将编码返回前端由Url 或Src 加载并显示。利用Google Chrome 的开发者工具，对两种加载方式下的同一页面图片加载时间进行对比分析，如表1 所示。原始图片大小在200 kB 左右时，传统方式加载和Base64 转码方式加载的时间分别为281 ms 和4 ms，浏览器加载速度相差70 倍，图片大小在500 kB 时，Base64 转码方式的加载速度较传统方式提升20 余倍，图片大小在5 MB 左右时，提升16倍，性能提升的同时也大大提高了用户体验度。

1.3 Base64转码的不足

随着图片大小的增大，它的Base64 编码字符串长度增长更明显，4 kB 大小的图片转码后的数据流足足有5 000 个字符，2 M 以上的图片转码后的数据流更是长达200 行以上，当页面中的一个Html 元素的CSS 样式超过200 行，整个CSS 的体积会变得异常庞大，继而影响页面的渲染[7]。经测试，在表1 的页面中加载的图片超过200 kB 时，接近40%的概率出现页面崩溃，90%以上的概率出现一张或数张图片空白的情况。综上，Base64 转码技术的应用局限在能够严格控制图片大小在200 kB 以下的站点中[8]。

表1 Base64对比传统加载方式的性能优势

2 基于PHP GD库的图像压缩

一张1 920*1 080 像素的图片，在每个像素4 字节大小的情况下，图片大小将超过8 M，对存储和传输会造成极大的浪费。图像数据能够被压缩的理论基础是图像数据的冗余性，并且允许一定程度的失真。假设该图片第一行像素的亮度值是[100 100…100（1 920个）]，那么第一行的大小就是4字节*1 920，将第一行重复数据压缩成[100,1 920]表示1 920 个100亮度值的像素，那么第一行的大小就变成4字节*2，上述基于图像空间冗余性的压缩是目前的主流图像压缩原理[9]。主流的Web 开发语言都有优秀的图片压缩类库，例如Java 的Thumb nailator、C#的Drawing和PHP 的GD（Graphic Device 图像处理扩展），出于对高压缩比的追求，它们支持的多是有失真即允许一定程度的有损压缩[10]。由于测试平台由PHP 开发，笔者基于GD 类库进行程序的改编对压缩前后的图片进行采样对比。

2.1 基于GD库的图像压缩流程

利用GD 库压缩图片的流程如图2 所示，依据不同的图片格式调用格式相应的图像加载函数，亦或是根据图片的Ur（lUniform resource locator）图像加载函数（文中方式），之后创建新画布以载入原始图片的图像资源，在新画布中完成对图像资源的压缩操作，通过压缩比的调整对图像资源的大小和清晰度，进而生成压缩后图片[11]。

图2 压缩流程

上述程序实现基于GD 库图像压缩Jpg 格式图片的基本功能，代码读取代表图像的变量Source，调整压缩比，即改变Quality 的数值，调用图像压缩函数Imagejpeg 生成变量名为destination 所代表的压缩后图片，Gif 和Png 格式的图片压缩有各自相似的处理函数。值得注意的是第一行代码ini_set(′memory_limit′,′256 M′)，扩大了PHP默认的内存限制至256 M字节，经多次测试，当压缩的图片大小在10 M 以上时，过小的内存限制会有一定几率导致应用程序的崩溃[12]。

2.2 图像压缩的优势

经过对不同大小的图片进行不同压缩比的压缩，对比压缩前后图片，得出如下结论（见表2）：在压缩比为50 的条件下压缩后得到的图片能较好地兼顾清晰度和大小的要求，并且随着图片大小的增大，原始图片与压缩图片的大小比例递增。其余的压缩比数值的压缩较难实现二者的兼顾，25 压缩比的压缩虽然满足较小图片的要求，但是清晰度失真较为严重反而影响图片内容的辨识；同理，75 压缩比生成的图片虽然保留了大部分原始图片的像素但是失去了压缩的意义：图片大小无明显变化。

表2 50压缩比条件下压缩前后图片大小

对一张测试平台中1.2 MB 大小的图片进行压缩前后采样对比发现，压缩后图片大小约400 kB，较原始图片大小缩小了3 倍多，在色彩和清晰度方面有轻微的失真不会致使读者对图片表达的原始信息产生误解，而3 倍的大小差距体现在浏览器的加载性能上将会对用户体验造成巨大的影响。

将表1 中对比Base64 转码和传统加载方式应用到的图片压缩后重新上传入库，利用Google Chrome开发者工具测试页面加载时间，结果如表3 所示，原始图片大小在200 kB 左右时，传统方式加载和图片压缩方式加载的时间分别是281 ms和4 ms，浏览器加载速度相差70倍，图片大小在500 kB 时，Base64转码方式的加载速度较传统方式提升20余倍，图片大小在5M左右时，提升2.44倍，图片大小越大时，对比Base64转码方式，图像压缩方式的加载时间优势越小。

表3 图像压缩技术的性能优势

2.3 图像压缩的不足和解决方案

根据表3 所示对比内容，显而易见，图像压缩技术的不足之处在于因压缩导致像素丢失造成的失真，这种程度的失真作为大图显示时会造成肉眼可见的差异，可是作为列表图片或者缩略图时，这种差异是能够忽略不计的[13]。综上，解决方案是用户上传原始图片时，后台同时生成压缩图片一并储存至服务器，在进行列表图或缩略图加载时使用压缩图片，进行大图显示时加载原始图片。由此在页面加载大量列表图时，不会由于过多大体积图片的Http请求而造成页面卡顿，而且在加载单一大图时，单一的Http 请求又能够缓解大体积图片的下载压力[14]。

3 懒加载和HTTP2协议

懒加载就是延时加载，用户有浏览需求时手动进行加载图片操作，例如淘宝京东此类购物网站，众多商品图片需要集中在一个页面显示，1 MB 大小的图片如果同时有1 000 人访问，达到的1 000 并发量就会产生1G 的带宽压力，基于前端的懒加载是解决此类问题的较流行的优化技术[15]，类似山东省气象部门图片资料云平台这种屏幕可以完全显示当前页所需图片的站点，能通过分页功能展示搜索结果集中的其他图片，没有需要懒加载的内容，在加载页面的同时就能够加载全部图片，因此懒加载技术适用于页面高度超过屏幕且页面下方仍有待加载的图片的站点。

HTTP2 协议能够解决浏览器连接请求的限制问题。目前主流的浏览器，如IE 各版本和笔者测试用的Google Chrome，最大Http 连接数限制在6 个，浏览器的一次Http 请求能够同时加载6 张图片，如果页面待加载图片过多则会进行多次的连接请求从而拖累整个页面的加载速度[16]。而HTTP2 协议一个站点只有一个连接，每个请求是一个流数据，被分为多个二进制帧，不同流中的帧可以交错地发送，实现多路复用，从而解决连接数限制问题，通过上述论述能够看出，HTTP2 协议适用于页面包含海量图片的站点。