前端图片合并方案调研

简介: 通过产品线数据分析,发现70%左右的图片为小于300K的图片,50%左右为小于100K的图片,因此调研前端图片合并方案是否有利于提高图片批量上传速度。之前做过的前端ZIP方案也是类似的思路。

介绍

通过产品线数据分析,发现70%左右的图片为小于300K的图片,50%左右为小于100K的图片,因此调研前端图片合并方案是否有利于提高图片批量上传速度。之前做过的前端ZIP方案也是类似的思路。


工具

  • 使用Network Link Conditioner模拟各种网络环境;
  • 使用sprites/index.html测试前端合并的效率;
  • 使用zip/index.html中的NOZIP方案测试无合并的效率;


前端合并方案

  • 采用Canvas将小图片拼接到单列上得到合并后的图片;
  • 将合并后的图片发送到服务器端;


测试维度

  • 网络环境: 10K 100K 300K 500K无网络延时以及50K带100ms网络延时;
  • 图片大小: 100K
  • 并发数:1 - 5
  • 图片数量:50


数据

*说明:未计算服务器端将合并后图片拆解所需时间;

speed = 256 K/S delay = 5ms(ADSL)

T               1     2     3     4      5

Sprites(ms)     148563 146993 146910 147149 147957

Normal(ms)     203878 184155 187438 183793 183533

%               28     20     22     20     19

speed = 10 M/S delay = 1ms(WIFI Good Connectivity)

T               1     2     3     4      5

Sprites(ms)     2356   1495   1264   1202   1208

Normal(ms)     3322   1891   1524   1290   1221

%               29     20     17     7      1

speed = 500 K/S delay = 0

T               1     2     3     4      5

Sprites(ms)     8904   8622   8471   8434   8444

Normal(ms)     11326 10770 10183 10980  10181

%               21     20     17     23     17

speed = 300 K/S delay = 0

T               1     2     3     4      5

Sprites(ms)     14377 14352 13951 13927  13924

Normal(ms)     17636 16961 16972 16975  17001

%               18     15     17     18     18

speed = 100 K/S delay = 0

T               1     2     3     4      5

Sprites(ms)     41549 42185 41973  -       -

Normal(ms)     51796 53401 51758  -       -

%               20     21     19     -       -

speed = 10 K/S delay = 0

T               1     2     3     4      5

Sprites(ms)     414722 -       -       -       -

Normal(ms)     538864 -       -       -       -

%               23     -       -       -       -

speed = 50 K/S delay = 100ms

T               1     2     3     4      5

Sprites(ms)     90348 88913 88996 90615  -

Normal(ms)     139343 125771 110348 109680 -

%               35     29     20     17     -

分析

  • 并发(2-5个请求)与不并发(1个请求)在高速和低速网络环境下效率表现有差异。在低速下,由于单个请求的速度已占满带宽,并发时每个请求的速度均会被平分,从而并发与不并发无明显差异。而高速下单个请求的速度并不能占满带宽,并发时每个请求的速度不会平方,从而导致并发对网络使用效率更高,拥有更高的传输速度;
  • 合并方案在上传效率上总体优于不合并方案,优势在单请求时达到最大(速度最大能提升35%),随着请求数增多,优势也在收窄。原因在于,并发对于不合并方案而言拥有比合并方案更大的收益:并行连接以及连接重用,减少网络延时成本。而对于合并方案不存在连接重用,而并发本身在低速下无法提速,从而导致优势收窄;
  • 合并方案对于不合并方案的优势在高延时网络下最大。因为合并方案相比不合并方案最大的优势是节省请求,因此当网络延时增大时,每个请求的时间会变长,而这对于合并方案的影响非常有限,但对于不合并方案则会成倍增加。

与ZIP方案相比

  • 图片合并效率比ZIP效率快10倍左右,因此图片合并更适合图片上传;
  • ZIP方案效率更低,但可以适用于所有文件类型;

结论

  • CANVAS合并方案批量上传效率整体优于无合并方案,上传速度提升平均20%;
  • 合并方案适合用于网络延时较大的网络环境,降低网络连接成本;
  • CANVAS合并需考虑后端成本,如果可接受建议使用;


相关文章
|
2月前
|
前端开发
后端返回图片二进制流,前端转base64
本文介绍了如何将后端返回的图片二进制流转换为Base64格式,以便在前端使用。通过在axios请求中设置`responseType`为`arraybuffer`,然后使用`btoa`和`Uint8Array`进行转换。
172 5
|
14天前
|
存储 前端开发 JavaScript
🚀前端轻松实现网页内容转换:一键复制、保存图片及生成 Markdown
在现代前端开发中,提升用户的交互体验至关重要。本文将详细介绍如何使用 HTML2Canvas 和 Turndown 两个强大的 JavaScript 库,实现将网页选中文本转化为图片并保存或复制到剪贴板,或将内容转换为 Markdown 格式。文章包含核心代码实现、技术细节和功能拓展方向,为开发者提供了一个轻量级的解决方案,提升用户体验。
111 68
|
19天前
|
JavaScript 前端开发 Python
django接收前端vue传输的formData图片数据
django接收前端vue传输的formData图片数据
19 4
|
18天前
|
前端开发 小程序 Java
java基础:map遍历使用;java使用 Patten 和Matches 进行正则匹配;后端传到前端展示图片三种情况,并保存到手机
这篇文章介绍了Java中Map的遍历方法、使用Pattern和matches进行正则表达式匹配,以及后端向前端传输图片并保存到手机的三种情况。
15 1
|
22天前
|
前端开发 JavaScript 编译器
不走弯路,纯前端如何把图片导出成视频!
【10月更文挑战第3天】不走弯路,纯前端如何把图片导出成视频!
37 3
|
22天前
|
JavaScript 前端开发 编译器
吐血整理:纯前端如何实现批量dom转图片,并下载成压缩包
【10月更文挑战第2天】吐血整理:纯前端如何实现批量dom转图片,并下载成压缩包
36 2
|
13天前
|
缓存 前端开发 UED
前端 8 种图片加载优化方案梳理
本文首发于微信公众号“前端徐徐”,详细探讨了现代网页设计中图片加载速度优化的重要性及方法。内容涵盖图片格式选择(如JPEG、PNG、WebP等)、图片压缩技术、响应式图片、延迟加载、CDN使用、缓存控制、图像裁剪与缩放、Base64编码等前端图片优化策略,旨在帮助开发者提升网页性能和用户体验。
77 0
|
2月前
|
前端开发
前端之图片操作
前端之图片操作
|
2月前
|
前端开发 Windows
【前端web入门第一天】02 HTML图片标签 超链接标签 音频标签 视频标签
本文档详细介绍了HTML中的图片、超链接、音频和视频标签的使用方法。首先讲解了`<img>`标签的基本用法及其属性,包括如何使用相对路径和绝对路径。接着介绍了`<a>`标签,用于创建超链接,并展示了如何设置目标页面打开方式。最后,文档还涵盖了如何在网页中嵌入音频和视频文件,包括简化写法及常用属性。
45 13
|
2月前
|
Web App开发 前端开发 JavaScript
Web前端项目的跨平台桌面客户端打包方案之——CEF框架
Chromium Embedded Framework (CEF) 是一个基于 Google Chromium 项目的开源 Web 浏览器控件,旨在为第三方应用提供嵌入式浏览器支持。CEF 隔离了底层 Chromium 和 Blink 的复杂性,提供了稳定的产品级 API。它支持 Windows、Linux 和 Mac 平台,不仅限于 C/C++ 接口,还支持多种语言。CEF 功能强大,性能优异,广泛应用于桌面端开发,如 QQ、微信、网易云音乐等。CEF 开源且采用 BSD 授权,商业友好,装机量已超 1 亿。此外,GitHub 项目 CefDetector 可帮助检测电脑中使用 CEF
216 3