压缩 JPG 用于网页
压缩 JPG 的预设方案
图片通常是网页上体积最大的元素，也是 Lighthouse 分数不理想最常见的原因。这个预设使用质量 78，并将最长边限制在 1920px——这是全宽首图在体积与画质之间取得最佳平衡的设置。
- 文件永不离开你的设备
- 免费，无需注册
- 无水印
- 加载后可离线使用
如何压缩 JPG
- 1
添加照片
将 JPG 文件拖到放置区域，点击浏览，或直接从剪贴板粘贴图片。一次最多支持 20 个文件。
- 2
选择质量或目标大小
使用质量滑块快速获得结果，或切换到目标大小模式并输入你需要的确切文件大小。
- 3
下载
单独保存每张图片，或将所有压缩后的照片打包为 ZIP 一次性下载。
图片通常是拖慢页面的元凶
在一个普通的内容页面上，图片往往占据了传输字节数的大部分，而其中最大的一张，往往正是 Largest Contentful Paint（最大内容绘制）所测量的那个元素——这也是 Core Web Vitals 直接衡量的指标。一张首图晚半秒到达，LCP 就会推迟半秒，而 LCP 超过 2.5 秒是页面不再被判定为"良好"的门槛。
最常见的错误是直接把相机或设计工具导出的原始文件用于网页。一张 4000px、5 MB 的 JPEG 显示在一个 1200px 的容器里，传输的数据量大约是布局实际能展示内容的二十倍。浏览器到达后会自行缩小显示，访问者却要在图片被绘制之前，先为那些注定被丢弃的细节付出等待时间。
质量 78、1920px，以及还需要搭配什么
质量 78 刚好处于 JPEG 伪影开始在照片内容上变得可察觉的临界点之下，而 1920 像素能覆盖绝大多数屏幕的全宽显示需求。两者结合通常能把一张首图压缩到 300 KB 以内。质量再往上调，换来的体积增加与画质提升不成比例；尺寸再往上调，在高密度显示屏上反而会显得发软。
不过压缩只是优化的一部分，剩下的属于标记层面的工作。设置明确的 width 和 height 属性，让浏览器能预留空间、避免布局偏移；给首屏以下的所有图片加上 loading="lazy"；让作为 LCP 元素的那一张图片保持即时加载。在完成这一步之后，通过 picture 元素为 JPEG 额外提供一种现代格式，通常是下一个最大的优化点。
- 全宽首图
- 1920px 是合适的上限。这个预设正是针对这种情况设计的。
- 文章配图与卡片图片
- 很少需要超过 800–1200px。把上限调低，节省效果会在整个页面上累积。
- 缩略图与头像
- 400px 已经绰绰有余。这类图片经常被以实际渲染尺寸十倍的规格提供。
常见问题
我的照片会被上传到服务器吗？
不会。压缩完全在你的浏览器内通过 Web Worker 中的 Canvas API 完成。照片不会经过网络传输，这也是断网后工具依然能正常工作的原因。
我的 JPG 能缩小多少？
在质量 80 的设置下，照片通常能缩小 60%–80%，在正常观看尺寸下看不出差异。已经被高度压缩过的图片缩小幅度会小一些，工具会告诉你具体节省了多少。
压缩 JPG 会改变图片的尺寸吗？
除非你主动要求，否则不会。默认情况下只改变编码质量。开启"调整大小"会额外限制最长边的像素数，这通常是让照片显著变小最快的方法。
有文件大小或批量数量的限制吗？
单个文件最大 50 MB，每批最多 20 张图片。这个限制的存在是因为所有内容都保存在你的设备内存中——不存在需要排队等待的服务器队列。
GPS 位置等 EXIF 信息会被保留吗？
不会。通过 canvas 重新编码会丢弃全部 EXIF 元数据，包括相机型号和 GPS 坐标。这通常正是你在公开分享照片前所需要的效果。
网页上应该用 WebP 代替 JPG 吗？
在同等画质下，WebP 通常比 JPEG 小 25%–35%，并且所有现代浏览器都已支持，因此它是新项目更好的默认选择。JPEG 仍然是更保险的通用后备方案，也是文件需要被任意软件打开时的正确选择。通过 picture 元素同时提供两种格式，可以在不牺牲兼容性的前提下获得体积上的节省。