GunLabs 官网展示几款产品时，我用了同一种构图：电脑在后面，平板叠在右边，手机放在最前面。
这样排版很直观。用户不用读一段长说明，就能看出产品在不同设备上是什么样子。
但从浏览器的角度看，每一组展示都是三张图片。官网有四组，就是十二张。GPlay、GFocus、GBalance、GMemor 各自的落地页，也有类似的展示。
这次优化的起点很简单：如果这些设备始终一起出现、一起移动，能不能让用户只下载一张图？
先看浏览器实际下载了什么
我没有直接把三张原图拼起来就宣布完成。先打开已发布的页面，记录图片请求、响应字节数和展示截图。
官网四组设备图合计下载约 486.5 KiB。单个产品站的体积不同：有的界面内容简单，有的截图里有大量缩略图和文字，所以不能拿一个产品的结果代表所有产品。
还要检查一个容易忽略的配置：这些站点使用 Next.js 静态导出，图片配置里有 unoptimized: true。不能因为组件叫 Image，就假定部署后会自动生成适合手机的图片尺寸。
我要解决的是用户实际下载的文件，而不是组件名字。
三个选择
第一种是继续保留三张图，只压缩它们。改动最少，也能保留每个设备独立移动的能力，但浏览器仍然需要三个文件。
第二种是合成一张很大的图，让所有屏幕都使用它。请求少了，手机却可能下载大量用不上的像素；而且原来的手机和桌面布局并不完全一样。
第三种是按构图合成，再按展示尺寸提供多个分辨率。
我选了第三种。这里的设备没有独立交互，动画也是整组滚动出现、整组悬停缩放。把它们合在一起，没有失去这块展示真正需要的行为。
如果以后要让手机和电脑分别动起来，就应重新考虑独立图片。合成适合这次的固定叠放展示，不是所有图片区域的通用答案。
一组展示，三种构图
手机、平板宽度和桌面的相对位置不同，我保留了三种构图。每种再提供 480、1120、1440px 三个宽度的 WebP。
页面通过原生 picture 选择构图，通过 srcset 和 sizes 选择分辨率。比如 GPlay 的展示，可以把核心结构理解成：
<picture>
<source media="(min-width: 1024px)" srcset="desktop-480.webp 480w, desktop-1120.webp 1120w, desktop-1440.webp 1440w" />
<source media="(min-width: 640px)" srcset="tablet-480.webp 480w, tablet-1120.webp 1120w, tablet-1440.webp 1440w" />
<img src="mobile-480.webp" srcset="mobile-480.webp 480w, mobile-1120.webp 1120w, mobile-1440.webp 1440w"
sizes="(min-width: 808px) 760px, (min-width: 640px) calc(100vw - 48px), calc(100vw - 40px)"
width="480" height="384" loading="lazy" decoding="async"
alt="GPlay 在电脑、平板和手机上的媒体库界面" />
</picture>这里的文件名是示意，线上使用的是带产品名和构图名的路径。实际组件会给各个 source 配置与站点展示宽度一致的 sizes。
高像素密度的手机仍可能选择 1120px 图片，这很正常。目标不是让所有手机都下载最小文件，而是在清晰度和体积之间找到合适的尺寸。
原图不能跟着优化一起消失
合成图有一个明显代价：以后只改手机截图，也需要重新生成整组图片。
所以我保留了十二张设备 PNG 源图，继续交给 Git 管理。页面加载的是派生 WebP；要调整产品界面、设备位置或遮挡关系，就从源图重新生成。
仓库已经有 Sharp 资产脚本，我扩展了这个入口，没有再加一个图片处理工具。官网在应用目录运行：
npm run optimize:assets其他产品站从仓库根目录调用同一份脚本，例如：
npm --prefix landing-gunlabs run optimize:assets -- gplay不同站点的展示宽度不同，所以共用源图和生成逻辑，各自保留自己的输出。五站合计生成了 72 张候选图，但浏览器不会把这 72 张都下载下来。
我还连续生成两次，比对所有输出哈希，并检查源图哈希没有变化。脚本能稳定复现，才方便以后继续维护。
下载量少了多少
我用 Chrome 的三个视口做了优化前后的比较：390px@3x、768px@2x、1440px@2x。每次使用新浏览器上下文，滚动到截图区域，让图片实际加载。
| 站点 | 展示图片请求变化 | 三个视口的下载量减少范围 |
|---|---|---|
| GunLabs 官网 | 12 → 4 | 43%–59% |
| GPlay | 3 → 1 | 53.2%–66.2% |
| GFocus | 3 → 1 | 43.0%–58.9% |
| GBalance | 3 → 1 | 35.8%–53.6% |
| GMemor | 3 → 1 | 33.6%–54.4% |
官网在手机视口的截图下载量，从约 486.5 KiB 降到 199.2 KiB。平板视口降到 277.4 KiB，桌面降到 198.0 KiB。
这是截图区域的响应字节量比较，不是整个页面加载时间的加速比例。 我没有做真实移动网络测速，也没有用真机 Safari 完成这轮回归，因此不会把它写成“官网快了 66%”。
除了看体积，我也对照了设备位置、透明边缘和文字清晰度，检查页面错误和横向溢出。官网还补了断点附近的候选选择，以及原有悬停和滚动动画的检查。
最后要验证的是线上文件
五个站点于 10 月 12 日发布后，我重新跑了线上浏览器检查。72 张候选 WebP 都与仓库里的文件逐字节一致，实际请求数量和下载量也与本地结果一致。
对我来说，这次优化最有用的收获是：固定一起展示的视觉元素，可以一起处理；需要继续编辑的源文件，要独立保留。
我把这套流程写进了维护文档。下一次更新截图，可以直接换源图、重新生成、检查三个视口，不用再从“为什么要合成”重新讨论一遍。