Skip to main content

OSS 图片交付与压缩优化

完全理解。既然你使用的是阿里云 OSS，并且图片 URL 已经支持 x-oss-process 参数，那么最佳的优化方案就是直接修改后端返回的图片 URL 字符串，无需重新上传图片，也无需改动前端架构。

针对这 3 类图片（以及该页面隐含的其他同类图片），这里给你一套纯中文、可直接落地的操作指南：

1. 核心修改规则（直接在 URL 上加参数）​

将原有的 ?x-oss-process=image/format,webp 升级为包含尺寸缩放 + 格式转换 + 质量压缩的组合链。

规则模板： 原图?x-oss-process=image/resize,w_目标宽度/format,目标格式/quality,Q_质量值

图片现状显示尺寸最佳交付尺寸 (兼顾Retina)推荐参数预估压缩率
图1 (已转WebP，96x96)36x3672x72resize,w_72/format,webp/quality,Q_80节省 ~80%
图2/图3 (PNG原图，128x128)48x4896x96resize,w_96/format,avif/quality,Q_80
(若不支持AVIF，用 format,webp)		节省 ~85%

2. 具体修改对照（直接替换你的 src）​

修改图1（bitunix.com）：

<!-- 旧地址 -->
src=".../abf784e....gif?x-oss-process=image/format,webp"

<!-- 新地址（缩小尺寸+降低质量） -->
src=".../abf784e....gif?x-oss-process=image/resize,w_72/format,webp/quality,Q_80"

修改图2 & 图3（阿里云 OSS）：

<!-- 旧地址 (PNG原图) -->
src="-1.aliyuncs.com/p2p/images/20230608/c289ecc2-....png"

<!-- 新地址（转AVIF+缩放到96px+质量80） -->
src="-1.aliyuncs.com/p2p/images/20230608/c289ecc2-....png?x-oss-process=image/resize,w_96/format,avif/quality,Q_80"

3. 前端兜底方案（自动适配不同屏幕）​

如果不想后端改代码，前端 HTML 可以用 srcset 来适配普通屏和高清屏（前提是你生成两个尺寸的 URL）：

<img 
  class="list_coin_logo" 
  src="https://...png?x-oss-process=image/resize,w_48/format,avif/quality,Q_80" 
  srcset="
    https://...png?x-oss-process=image/resize,w_48/format,avif/quality,Q_80 1x, 
    https://...png?x-oss-process=image/resize,w_96/format,avif/quality,Q_80 2x
  " 
  alt="coin-icon" 
  style="width:48px; height:48px; border-radius:5px;" 
/>

注：如果只存一份图片，直接用第一条“推荐参数”里的 w_96 就够用，代码改动最小。

4. 关于 LCP 加载速度的附加建议​

  • 抢占优先级：在最大的那张图片（约 111 KiB 那两张里的较大者）的 <img> 标签上加上：
    fetchpriority="high"
  • 去掉阻塞渲染的 onerror：你的代码里有 onerror=... 内联代码，如果图片加载失败，这个脚本会立即执行。建议改为 CSS 背景色占位，防止内联脚本拖慢 LCP 计算。

5. 最终收益测算（以图2为例）​

  • 原图：128x128 PNG = 24.7 KiB
  • 处理后：96x96 AVIF (Q=80) ≈ 4 ~ 5 KiB
  • 单张节省：约 20 KiB 页面中这类图标数量较多，累计完全能达到报告中预估的 144 KiB 总节省。

执行建议：直接全局搜索代码中的 .png?x-oss-process=image/format,webp 和裸的 .png，统一替换成上述带有 resize 和 quality 的组合参数，此优化不需要发版即可生效（如果你能直接修改数据库/配置中心的图片链接的话）。