面向Web开发者的批量图片压缩 | Bulk Image Compressor
图片是大多数网站上最重的资源。在平均页面上，它们占总重量的40%到60%。如果你是一名Web开发者，而你没有压缩图片，那么无论你的代码有多干净，你都在交付臃肿的页面。
问题不在于是否要压缩，而在于压缩应该发生在工作流的哪个环节，以及哪种工具适合哪种情况。
图片压缩在开发工作流中的位置
在开发过程中，你可以在三个主要环节压缩图片：
提交前。 在图片进入版本控制之前，你就在本地优化它们。这能让你的仓库保持精简，并且意味着每个环境（预发布、生产、其他开发者的机器）都会自动获得优化后的版本。
构建时。 Vite或webpack等构建工具作为资源管线的一部分处理压缩。源图片在仓库中保持完整质量，构建过程生成优化版本用于部署。
CDN层。 Cloudflare、Imgix或Cloudinary等服务根据请求设备和浏览器实时转换和压缩图片。
每种方法都有权衡，你也可以组合使用它们。
在线工具 vs 构建插件
对于快速的一次性任务，比如压缩一批博客截图或优化一组图标，在线工具是最快的选择。打开批量图片压缩器，拖入文件，调整质量，下载。不到一分钟就完成了。
构建插件会自动处理持续优化。以下是实际应用中的样子。
Vite
Vite用户可以使用vite-plugin-imagemin或类似插件：
// vite.config.js
import imagemin from 'vite-plugin-imagemin';
export default {
plugins: [
imagemin({
mozjpeg: { quality: 80 },
webp: { quality: 80 },
pngquant: { quality: [0.7, 0.8] },
}),
],
};这在vite build期间压缩图片。源文件保持不变。输出目录获得优化后的版本。
webpack
使用webpack时，image-minimizer-webpack-plugin完成同样的工作：
const ImageMinimizerPlugin = require('image-minimizer-webpack-plugin');
module.exports = {
optimization: {
minimizer: [
new ImageMinimizerPlugin({
minimizer: {
implementation: ImageMinimizerPlugin.sharpMinify,
options: {
encodeOptions: {
jpeg: { quality: 80 },
webp: { quality: 80 },
},
},
},
}),
],
},
};何时使用哪种
使用在线工具当：
- 你要往项目中添加少量图片，想立即优化它们
- 你处理来自客户或设计师的未优化文件
- 你的项目没有构建步骤（静态HTML、简单网站）
- 你想在提交前直观地检查压缩结果
使用构建插件当：
- 你的项目已经有构建流水线
- 多个开发者贡献图片，你想要一致的优化效果
- 你需要格式转换（例如自动生成WebP版本）
- 你希望源图片在仓库中保持完整质量，以便将来可能重新处理
CI/CD图片优化
构建插件在本地构建期间运行，但你也可以将图片优化添加到你的CI/CD流水线中。这样可以捕获那些漏掉的未优化图片，不管是谁提交的。
一个简单的方法是在CI流水线中运行一个检查图片文件大小的脚本：
# 如果任何图片大于500KB，则构建失败
find public/images -type f \( -name "*.jpg" -o -name "*.png" -o -name "*.webp" \) -size +500k | tee oversized.txt
if [ -s oversized.txt ]; then
echo "发现过大的图片。部署前请先压缩。"
exit 1
fi对于CI中的自动压缩，像sharp-cli或imagemin-cli这样的工具可以在构建步骤中处理图片。这保证了没有未压缩的内容进入生产环境。
懒加载和响应式图片
仅靠压缩是不够的。图片的加载方式同样重要。
懒加载将屏幕外的图片推迟到用户滚动到它们时才加载。为每个首屏以下的图片添加loading="lazy"。不要懒加载你的首屏大图或在初始页面加载时可见的任何内容，因为这会损害你的Largest Contentful Paint分数。
响应式图片根据屏幕宽度提供不同尺寸。手机不需要为桌面显示器设计的2400px图片。使用srcset和sizes属性让浏览器选择正确的版本：
<img
src="product-800.webp"
srcset="product-400.webp 400w, product-800.webp 800w, product-1600.webp 1600w"
sizes="(max-width: 640px) 400px, (max-width: 1024px) 800px, 1600px"
alt="产品照片"
width="1600"
height="1067"
loading="lazy"
>将这些尺寸变体作为构建过程的一部分或在上传前使用批量工具生成。
CDN分发
CDN（内容分发网络）从地理上靠近访客的服务器提供图片。这减少了延迟，但一些CDN更进一步，提供实时图片优化。
Cloudflare Image Resizing可以根据访客的浏览器自动调整大小并将图片转换为WebP或AVIF。你不需要自己生成变体。
Imgix和Cloudinary是专门的图片CDN。你上传一个高质量源文件，它们通过URL参数生成你要求的任何尺寸、格式和质量。这很强大，但会为每张图片增加费用。
对于大多数项目，在上传前压缩图片并通过标准CDN（Cloudflare、Fastly、AWS CloudFront）分发就足够了。当你拥有成千上万用户上传的图片并需要动态调整大小时，专门的图片CDN才有意义。至于为什么压缩对Web如此重要的背景知识，我们的指南为什么网站图片需要压缩涵盖了基础知识。
开发者常犯的错误
提交未优化的图片。 仓库中的5MB JPEG会永远留在git历史中，即使你后来替换了它。在提交前压缩。
对照片使用PNG。 PNG适用于图形、截图和需要透明度的图片。保存为PNG的照片通常比同一张图片的JPEG或WebP版本大3到5倍。根据内容类型使用正确的格式。查看我们的格式对比指南了解详情。
忽略宽度和高度属性。 没有明确尺寸，浏览器在图片加载前不知道要为图片预留多少空间。这会导致布局偏移，损害你的CLS分数并让用户烦恼。
过度压缩。 将质量推到30%或40%以获得微小文件会产生可见的伪影。对于网页图片，75%到82%的质量在大小和外观之间取得了正确的平衡。
忽略图片尺寸。 将4000px的照片压缩到80%质量是好的，但如果它在你的页面上以600px宽显示，你仍然在发送比所需多得多的像素。先调整到你的显示尺寸，然后再压缩。
不使用WebP。 浏览器对WebP的支持现在已经普及。如果你仍然只提供JPEG和PNG，你放弃了25%到35%的文件大小节省。
实用方法
对于大多数Web项目，以下是有效的做法：
- 使用像批量图片压缩器这样的在线工具或本地脚本，在提交前调整大小和压缩图片。
- 添加一个构建插件作为安全网，以捕获任何漏网之鱼。
- 在HTML中使用懒加载和响应式图片。
- 通过CDN分发。
你不需要在第一天就做到全部四点。从第一步开始。仅这一步就能在你的页面加载时间上产生明显的变化。
Ready to compress your images?
Bulk compress JPEG, PNG, WebP, and AVIF images right in your browser. No uploads, no sign-ups.
Try Bulk Image Compressor