发现问题

最近测试低代码平台的时候发现一个严重问题-发现渲染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无头浏览器去模拟用户操作进行存量数据的替换。

明天去看看新世界