这款工具把图片重新编码一遍，用更省体积的格式和参数存下来。它调用的是浏览器自带的图片编码能力，所有处理都在你的设备上完成，图片一个字节都不会传到服务器。这既是隐私上的好处，也意味着处理速度只取决于你的电脑，不受网速影响。
对做网站的人来说，图片几乎总是页面里最重的资源。一张没处理过的手机照片动辄三五兆，而同样的画面转成 WebP、压到合适的画质，往往只要两三百 KB，肉眼几乎看不出差别。这个差距直接决定了移动端首屏的加载时间。
同等观感下，WebP 的体积通常比 JPEG 小 25% 到 35%，比 PNG 小得更多。现在所有主流浏览器都支持它，包括 Safari 从 14 版开始。除非有特殊的兼容性要求，网页上的图片优先选 WebP 基本不会错。
如果图片要发给客户、上传到不确定是否支持 WebP 的第三方平台，或者要在很老的设备上打开，JPEG 仍然是最稳的选择。它的短板是不支持透明通道。
PNG 是无损格式，适合 logo、图标、界面截图这类有大片纯色和锐利边缘的图。但要注意一点：用浏览器重新编码 PNG，体积很可能不降反增。因为专业的 PNG 优化工具会做调色板量化和更激进的压缩，而浏览器的编码器不做这些。这款工具会如实显示体积变大了多少——遇到这种情况，保留原图就好。
画质参数只对 WebP 和 JPEG 这类有损格式生效，取值从 0.3 到 1.0。
实际经验是这样的：0.9 以上，体积下降有限而画质提升几乎看不出，性价比低；0.75 到 0.85 是大多数照片的甜点区，体积能砍掉一大半，放大看才可能发现差别；0.6 以下开始出现明显的块状伪影，只适合缩略图或者对画质不敏感的场景。
不同类型的图对压缩的耐受度差别很大。风景照、人像这类色彩过渡平滑的图，压到 0.75 依然好看；而带文字的截图、线条图、纯色大块的插画，有损压缩会让边缘发糊出现色晕，这类图要么调高画质，要么干脆用 PNG。
很多人压图只调画质，忽略了尺寸，这其实是本末倒置。一张 4000 像素宽的照片放进宽度只有 800 像素的正文容器里，多出来的三千多像素纯粹是浪费——浏览器下载完还要再缩放一次，既费流量又费 CPU。
体积和像素数大致成正比，把宽度从 4000 缩到 1200，像素数少了将近九成，这个降幅是任何画质参数都做不到的。所以正确的顺序是：先把尺寸限制到实际需要的大小，再调画质。
几个常用的参考值：正文配图 1200 像素宽足够应付主流的高分屏；文章封面和社交分享图 1600 像素；全屏背景图 1920 像素；商品列表的缩略图 400 到 600 像素就够。如果页面用了 srcset 提供多套尺寸，就按各档的实际宽度分别生成。
用之前应该知道的限制：
图片是 Core Web Vitals 里最容易出问题的一环，而其中 LCP 这一项，在绝大多数内容页面上，被判定为最大内容元素的就是首屏那张图。图片下载得慢，LCP 就慢，这是直接换算关系。
但压缩只是第一步，配套的几件事同样重要：首屏图不要加 lazy 属性，那会推迟它的加载；给图片写死 width 和 height 属性，避免加载完成后页面跳动造成 CLS；正文以下的图才用懒加载；有条件的话用 picture 元素配合 srcset，让不同屏幕拿不同尺寸。
还有一点容易被忽略：压缩不能替代 alt 文本。搜索引擎理解图片内容主要靠 alt、周边文字和文件名，体积再小的图，没有 alt 也进不了图片搜索的结果。文件名同理，把 IMG_20260725.jpg 改成描述性的名字，是几乎零成本的一次优化。
不会。全部用浏览器的canvas在本地重新编码，页面加载完断网也能正常压缩，适合处理未发布的素材和含隐私的照片。
浏览器的PNG编码器不做调色板量化等优化，专业工具能压到的体积它做不到。工具会如实显示体积变化，遇到变大的情况保留原图就好。
不会。重新编码会丢掉全部元数据，包括拍摄参数和GPS位置。发布到网上通常正合适，但要归档原片请留好原文件。
主流浏览器目前只支持解码AVIF，不支持在网页里编码，所以纯前端工具给不了。需要AVIF要用命令行工具或图片CDN。
动图进来后只保留第一帧变成静态图。这款工具不做动图重新编码，需要压动图请用专门的工具。
0.75到0.85适合大多数照片。带文字的截图和线条图对有损压缩敏感，要么调高到0.9以上，要么改用PNG。
先限制尺寸。体积和像素数大致成正比，把4000像素宽缩到1200，像素数少了近九成，这个降幅任何画质参数都做不到。
首屏图通常就是LCP判定的最大内容元素，图片下载慢直接拖慢LCP。但压缩替代不了alt文本和描述性文件名，那两项决定图片能不能进图片搜索。