图片通常是页面上最重的东西，这让它成为你能掌控的最大提速杠杆。把它们的尺寸和文件体积弄对，页面就像瞬间加载；弄错了，无论你的代码多干净，都过不了 Core Web Vitals。下面是目标值，以及达标的工作流。
尺寸目标
让图片的像素尺寸与它实际出现的位置匹配。大致指南：
- 通栏主视觉： 1600–2000 px 宽覆盖大多数桌面布局。再宽很少有帮助，却要花很多字节。
- 正文内配图： 你的内容栏宽度，常见 800–1200 px。
- 缩略图／卡片图： 300–500 px。
- 头像／图标： 按显示尺寸 48–200 px。
把一张 4000px 的图塞进 800px 的位置，意味着浏览器下载并解码了它永远显示不出来的 25 倍像素。这是纯粹的浪费——而且解码大图还会卡住主线程。
体积目标
尺寸设定上限，压缩决定实际体积。目标：
- 主视觉图： 小于 200 KB（最好 100–150 KB）。
- 正文内配图： 80–150 KB。
- 缩略图： 10–30 KB。
- 每页图片总量： 尽量让整页控制在 约 1 MB 以内。
如果单张图超过约 300 KB，就当成一个需要排查的 bug。
为什么这会左右 Core Web Vitals
Google 的 Largest Contentful Paint（LCP，最大内容绘制）衡量屏幕上最大元素多久渲染出来——而在大多数页面上，那个最大元素就是图片（通常是主视觉）。一张又重又大的主视觉直接拉高 LCP。良好的 LCP 是小于 2.5 秒；一张臃肿的主视觉在移动网络下光靠自己就能冲破这个线。
还有两个与图片相关的收益：
- 设置 width 和 height 属性，让浏览器预留空间——这保护你的 Cumulative Layout Shift（CLS，累积布局偏移）分数。
- 优先加载主视觉（不要对 LCP 图片做懒加载），对首屏以下的一切做懒加载。
两步工作流
第一步——缩到真实显示宽度。 用图片尺寸调整工具把每张图缩到它出现的尺寸。锁定宽高比，高质量缩小。单这一步往往就能砍掉 80–90% 的体积。
第二步——压缩。 把缩放后的文件喂给图片压缩工具：照片用质量 75–85（视觉无损），PNG 用 256 色量化。它绝不会输出比原图更大的文件，支持批量，还有可选的宽度上限，所以你实际上可以一遍搞定两步。对现代浏览器，把照片转成 WebP 还能再挤出 25–35%。
用测量代替猜测
图片优化好之后，确认页面真的变快了。IMG.DIY 的页面体检工具通过 Google PageSpeed Insights 审计一个线上 URL，并报告页面的图片体积，让你揪出任何仍然过重的文件。一点提醒：页面体检需要联网——与图片工具不同，它调用 Google 的 PageSpeed API，所以无法离线运行。部署后用它来检查你真实的 LCP 和图片预算。
默认保护隐私
缩放、压缩、转换工具都用 Canvas 和 WebAssembly 完全在你的浏览器里运行——什么都不上传，首次访问之后它们就被缓存，可以离线使用。你可以在没有网络的情况下备好整站的图片，等页面上线后再联网跑一次页面体检。
快速回顾：把尺寸调对，压到体积目标，为 LCP 优先加载主视觉，再用页面体检验证。