手机实际下载的是哪一张图片？

页面上图片占的空间小，并不意味着下载文件也小。如果所有访客都收到同一张大图，手机仍可能下载布局用不到的像素。压缩和响应式选择分别解决其中一部分问题。

网站图片流程介绍准备工作，图片交付指南解释性能诊断。这次从准备文件追踪到浏览器真正选择的资源，直接观察一张照片，而不把评分当作结果。

我们先在外部图片编辑器中等比例制作副本，再进行压缩，Bitinz 没有调整尺寸。2026-10-29，各副本用本地引擎均衡档处理；记录的尺寸、字节数和校验值对应浏览器实验所用的候选文件。

本地页面通过 srcset 提供候选图片，并用匹配的 sizes 规则描述布局。浏览器记录包含视口宽度、像素密度和所选资源，只测图片文件，不代表整页加载或模拟移动网络速度。证据方法见内容编写说明。

先比较这些文件，再看来源中的浏览器选图记录。浏览器只能在页面实际提供的候选项中选择。

Bitinz · 1 KB = 1000 字节。

每行都使用全新浏览器环境并关闭缓存。最宽的高密度场景选择了最大的候选图，因为候选列表在这个位置有较大空档。值得另外测试一个中间尺寸：浏览器只能选择列表里确实存在的文件。

原始照片细节

压缩后照片细节

在小屏幕和高像素密度显示器上查看照片。如果最小候选图已经明显发糊，就不一定适合；同样，一张大候选图即使节省比例很高，也不代表有必要下载。

选图记录是指定环境的一次观察。缓存和浏览器自己的决策会影响后续访问；复现时请用全新浏览器环境，检查实际请求，而不是只凭显示尺寸推测。

先用图片压缩工具处理准备好的副本，再让网站或内容管理系统提供合适版本。如果生成的页面始终指向同一大文件，压缩本身不会改变这个选择。

让 sizes 与 CSS 布局保持一致。浏览器结合这个提示、候选尺寸和屏幕密度做选择，不能靠文件名猜出作者的意图。布局变动后，再查一次实际请求的资源。

对于反复执行的发布流程，开发者 API可以压缩准备好的文件。缩小尺寸仍是独立的准备步骤。画质指南介绍了替换图片前怎样比较细节。

1. 01测量图片展示区域，确定设计需要的等比例宽度。
2. 02保留可编辑原图，准备并压缩这些副本。
3. 03提供候选图片，让 sizes 规则与布局相符。
4. 04在不同屏幕上检查所选资源和实际观感。