发现问题

最近测试低代码平台的时候发现一个严重问题-发现渲染sdk在渲染部分作品的时候体验太差，图片加载特别慢。

分析问题

编辑器上传图片没有加图片大小的限制，导致用户有可能上传了一张体积很大的大图，导致sdk渲染的时候因为图片体积很大-> 图片加载慢 -> 空白 -> 体验太差。

解决问题

可以从两个点出发去解决

• 加载问题
• 大小问题

加载优化

• cdn 目前的图片资源是存到一个静态资源服务器上，因为服务器带宽受限，所以可以放到cdn上，从而物理加速，这个优化措施非常好，但是调研了一下，还是决定放弃该方案(预算有限)。
• 预加载 让图片资源提前加载到内存，对当前场景来说收益不高而且不能解决根本问题。因为有可能图片体积非常大，用户在交互的时候，资源还没有加载完。(二期优化规划中)

图片大小问题

图片大小问题的最大收益优化措施其实就是图片压缩。不太愿意在上传的时候做图片大小限制-我好不容易找出一张合适的图，我还要去对图片进行压缩或者裁剪。

• 目前主要的图片格式：

  图片格式	优点及缺点
  png	支持透明、无损压缩，无损压缩虽然能保证质量但是在减少大小方面没有有损压缩那么好
  jpg	不支持透明，支持有损压缩
  webp	支持透明、无损压缩、有损压缩，但是兼容性不太好

• 目前的图片压缩工具

  图片格式	原图大小	MozJpeg(会丢失透明通道问题)	tinypng	oxiPng
  png	433kb	31.5kb	106.5kb	323kb
  jpg	181kb	125kb	175.kb	941kb
  webp	462kb	162kb	224.0 KB	1.91mb

综合以上数据可知如果有透明通道tinypng最佳，无透明通道MozJpeg最佳；

技术方案

新增数据

会对图片上传接口做图片压缩逻辑

存量数据

定时脚本每天跑压缩逻辑

其实当前场景也可以不跑这个定时脚本，直接用Puppeteer无头浏览器去模拟用户操作进行存量数据的替换。

写在末尾

明天去看看新世界