前端图片优化实战：用sharp自动生成WebP响应式图片

之前帮朋友调一个博客站点，折腾了一整天，从Lighthouse跑分一路追到图片加载链路，最后发现罪魁祸首就是那几张上传时没处理过的原始大图。一张2400像素宽、800多KB的JPEG直接放在首屏，移动端加载慢得让人怀疑人生。后来我花了不少时间把手里的图片处理流程重新梳理了一遍，从格式转换到响应式尺寸一步到位，效果立竿见影。今天这篇就直接把这套可复用的方法记录下来。

这算是一份完整的HTML图片优化指南，核心解决三件事：把图片自动转成WebP格式、生成多套响应式尺寸、以及在HTML里正确调用。适合前端开发者、独立站点维护者、写博客的朋友，还有被页面加载速度折磨的运营同学。不需要你有很深的前端功底，只要会基本的Node.js和HTML标签，就能照着抄。

1. 为什么图片优化是网页性能的第一优先级

1.1 图片体积在网页中的占比与优化收益

在很多性能优化教程里，大家喜欢先讲请求数、缓存策略、代码拆分这些东西，但如果你真的拿DevTools去统计一个普通内容站点的资源占比，会发现图片几乎总是最重的那块。HTTP Archive对全网数百万网站做过长期统计，图片平均要占页面总字节数的50%以上，有的站点甚至能到70%以上。我自己维护的几个站点也一样，图片压缩掉之后，整站体积能缩到原来的三分之一。

图片优化之所以放在第一优先级，是因为它往往不需要动业务逻辑，不需要改代码架构，单纯把资源本身处理好，加载速度就能明显提升。相比你花一周时间去搞微前端、搞SSR，图片这块可能一个下午就能见效。对于一个个人站点或者内容型项目来说，投入产出比非常高。

还有个容易被忽略的点：图片优化直接影响用户体验指标。Lighthouse里的LCP（Largest Contentful Paint）很多时候就是被首屏大图卡住的，而CLS（Cumulative Layout Shift）也经常因为图片没有预留尺寸而爆表。这两项分数上去了，搜索引擎排名和广告点击率都会跟着受益。

1.2 WebP到底比JPEG和PNG强在哪

WebP是Google在2010年推出的一种图片格式，核心压缩思路和JPEG不太一样。JPEG用离散余弦变换加量化来丢弃高频信息，WebP则更多基于预测编码——先参考周围已经编码的像素块，只记录当前块和预测块的差异。这种做法的好处是在同等视觉质量下，需要存储的差异数据更少，所以体积能压得更小。

Google官方给的数据是WebP有损压缩比JPEG小25%到34%，我实际测试下来大多数场景也差不多是这个范围，有些细节丰富的照片甚至能省40%。但要说一下，这个提升幅度跟图片内容关系很大。如果是一张纯色渐变、边缘清晰的UI截图，WebP的优势非常明显；如果是颗粒感很强的高ISO照片，差距就没那么大。

WebP还有一个关键优势是支持透明通道。以前做透明图片只能用PNG，一张无损透明的PNG动不动就是几MB，而同样的内容转成WebP经常只要零头。压缩率更高，还支持透明，加上也支持动画（WebP动图比GIF小很多），这就让它成了网页图片的实用选择。当然AVIF在压缩率上比WebP更猛，Safari 16.4之后也支持了，但就当前环境来说WebP依然是覆盖范围和个人开发场景下比较顺手的选择。

1.3 响应式图片要解决的核心问题

很多人对响应式图片有个误解，觉得只要在CSS里写了max-width: 100%，图片就能自适应，就算是响应式了。实际上这是两个维度的事。CSS控制的是图片的展示尺寸，而响应式图片要解决的是：让不同屏幕、不同像素密度的设备，加载最合适的那个图片文件。

举两个具体例子。第一个场景：一个展示图片的页面，在手机端图片大概占屏幕宽度360像素，在桌面端占容器宽度800像素。如果不管设备如何，都加载一张原始尺寸1920像素的图，手机用户浪费了太多流量，还拖慢了加载。第二个场景：有些用户用了2倍屏的Retina屏幕，你在HTML里给了一张500像素宽的图，但在2倍屏上浏览器需要1000像素的实际像素数据才能显示清晰，这时图片就会发虚。

HTML原生的解决方案就是srcset加sizes属性。srcset声明图片的多个候选版本和各自的宽度，sizes告诉浏览器这张图在不同视口下大概会渲染多宽，浏览器根据这两个信息和当前设备的屏幕宽度、像素密度，自己决定加载哪个文件。这种机制不依赖任何JavaScript，纯HTML就能实现，而且浏览器原生支持，稳定可靠。

2. 工具选型：从cwebp到sharp的实践对比

2.1 常见的图片转换工具盘点

在做批量图片转换之前，第一步是要选一个合适的处理工具。我试过的方案有这么几类：

• cwebp命令行工具：Google官方出的WebP编码器，单张压缩效果很好，参数也丰富。但它只是个转换工具，如果要同时做多尺寸裁剪，还得配合ImageMagick或者其他工具链，脚本写起来比较零散。
• ImageMagick：老牌图像处理全家桶，magick convert什么都能干，但参数多到记不住，而且不同版本的性能差异比较大，处理超大图时内存占用很吓人。
• Pillow：Python生态里的经典库，功能齐全，文档也详细。不过它是纯Python实现的图像处理，性能和大图并发处理比不过原生库，一张张处理大量图片时速度会有点着急。
• sharp：Node.js生态的图片处理库，底层是libvips这个C++库。它的优势是性能极强，内存占用低，而且API是链式调用，一个流程里可以同时做缩放、转格式、调质量，非常对我的胃口。
• 在线工具如Squoosh.app：Google出的在线压缩工具，操作直观、效果直观，偶尔处理一两张图很方便。但没法自动化，如果是几十上百张图的批量场景，显然不可能一张张手动去转。

2.2 为什么用sharp作为自动化核心

如果只是偶尔优化一张图，用在线工具确实最省事。但一旦到了批量处理或者要接入构建流程的时候，就需要一个能通过代码调用的方案。我最终选择sharp，主要是因为几个实际考虑。

第一，性能差距确实明显。sharp基于libvips，用的是流式处理，对内存的控制比ImageMagick好很多。我在一台2核4G的小服务器上处理了200多张图片，全程内存占用没超过300MB，而之前用ImageMagick跑同样一批图，内存吃了快1GB，还偶尔卡死。第二，它的API对于“缩放加转格式”这种组合操作来说太方便了，链式调用一步到位，不用来回转换中间格式。第三，项目本来就用Node.js，引入sharp不会增加额外的运行时依赖，维护成本最低。

可能有人会问，既然最后是要在HTML里用响应式图片，为什么不直接用一些现成的图片CDN服务，比如Cloudinary、Imgix这些。这些服务确实强大，直接改URL参数就能实时生成各种尺寸和格式，还能自动做设备判断。如果你的项目用了这类服务，这篇文章的内容可以当背景知识看看。但对于个人网站、博客、内部系统这类场景，不引入外部依赖、自己控制整个流程会更可控，成本也低得多。

2.3 环境与依赖准备

开始写脚本之前，先把环境准备好。sharp是一个Node.js库，所以首先需要Node.js环境，建议用14以上版本，我在18和20上都测试过，没有问题。安装就一条命令：

bash复制npm init -y
npm install sharp

如果你的图片分布在多个子目录里，可能还需要一个读文件用的工具，Node自带的fs模块能实现，但用glob库会更方便，它会按通配符把匹配到的文件全部列出来：

bash复制npm install glob

这里提一个安装过程中可能遇到的坑。sharp在安装时会下载预编译的libvips二进制包，如果网络环境不稳定，可能会卡在postinstall阶段。macOS用户如果遇到node-gyp报错，大概率是没装Xcode Command Line Tools；Windows用户则可能需要Visual Studio Build Tools。不过从sharp 0.32之后的版本来看，官方对预编译包的处理已经比较成熟了，大部分情况下直接npm install就能顺利装好。

注意：如果你是在服务器上跑这个脚本，建议先跑一下node -e "require('sharp')"确认能正常加载。如果报错说找不到libvips相关依赖，可以根据服务器系统装上对应的基础库，比如libvips-dev之类。

3. 响应式图片的HTML核心实现

3.1 srcset和sizes的完整语法解析

先看一段完整的响应式图片HTML写法：

html复制<img
  srcset="photo-256.webp 256w,
          photo-512.webp 512w,
          photo-1024.webp 1024w,
          photo-2048.webp 2048w"
  sizes="(max-width: 640px) 100vw,
         (max-width: 1200px) 50vw,
         1024px"
  src="photo-fallback.jpg"
  alt="示例图片"
>

这里的srcset有几种描述符写法，最简单的是用x描述符表示设备像素比：

html复制<img
  srcset="photo-1x.jpg 1x,
          photo-2x.jpg 2x"
  src="photo-1x.jpg"
>

但这个写法有个局限：它假设图片在不同设备上以差不多的物理尺寸显示，所以只要根据像素比选就行。对于布局宽度会随屏幕变化的响应式页面，更实用的是w描述符。你在srcset里写出每个候选图片文件自身的宽度，然后配合sizes告诉浏览器“这张图在某某屏幕宽度下实际渲染多宽”，浏览器就能结合视口宽度和像素密度，算出应该选哪个文件。

拿上面那段代码举例：photo-256.webp 256w表示这个文件的实际图片宽度是256像素。sizes里的(max-width: 640px) 100vw意思是，当视口小于等于640像素时，图片大概占满整个屏幕宽度；(max-width: 1200px) 50vw表示视口在640到1200像素之间时，图片占一半屏幕宽；否则固定为1024像素。浏览器根据这些信息，再加上当前屏幕的DPR，自动决策加载哪个文件。

这段逻辑如果理解不透，最容易犯的一个错误就是：srcset里的w值乱写。我见过有人把压缩后文件尺寸和实际宽度对不上，结果浏览器算了半天，选了一个尺寸和渲染宽度不匹配的文件，导致图片被拉伸，画质一塌糊涂。w值必须是图片文件真实像素宽度，不是随便编的数字。

3.2 picture与source的格式降级方案

srcset和sizes解决的是分辨率适配的问题，但如果你想让浏览器优先使用WebP，不支持的浏览器自动降级到JPEG，就需要用到picture元素。

html复制<picture>
  <source srcset="photo.avif" type="image/avif">
  <source srcset="photo.webp" type="image/webp">
  <img src="photo.jpg" alt="示例图片">
</picture>

浏览器解析picture时会从上往下逐个匹配source的type属性，第一个能识别的格式就用哪个，如果都不认识，最后落到img标签里的src作为兜底。这种做法非常实用，因为你不需要动任何JS逻辑，浏览器自己就会处理。

有一个建议是，如果你当前不太想维护AVIF版本的图片，只保留WebP和JPEG两个版本也完全够用。但如果你决定加AVIF，印象里在支持的浏览器里压缩率又比WebP再低20%到30%，长期来看是个不错的优化方向。只是在生成图片时要多生成一套文件的成本，需要自己权衡。

3.3 配合加载性能的HTML属性组合

除了格式和尺寸，HTML里还有几个属性值得组合起来使用。

loading="lazy"是懒加载的标准属性。设置之后，浏览器会等图片即将进入视口时再发起请求。这个概念对长页面特别有用，比如文章页有十几张图，首屏只加载最上头几张，下面的图滚动到了才加载，省流量也省请求。但这里有个重要提示：不要给首屏关键图片加lazy。尤其是LCP图片，如果加了懒加载，浏览器可能会推迟加载，导致首屏体验变差。我见过一些站点为了省事全站图片都加lazy，结果首页LCP分数反而降了。

decoding="async"表示图片解码异步执行，不会阻塞主线程的渲染。这个属性对大多数页面影响不算特别大，但在图片特别多的页面上还是有一定帮助。

width和height属性很多人容易忽略，其实这里是防止CLS的关键。以前大家写<img>喜欢什么都不写，图片加载完成后页面上内容会往下跳一下，这就是CLS。正确做法是在HTML里写上图片的原始尺寸宽高：

html复制<img src="photo.webp" width="1024" height="768" alt="示例">

然后配合CSS：

css复制img {
  max-width: 100%;
  height: auto;
}

这样浏览器在图片加载之前就能知道图片占多大空间，提前预留好位置，页面就不会跳了。

还有一个属性是fetchpriority="high"，用来告诉浏览器这个图片是页面上比较关键的元素，应该优先加载。一般放在LCP图片上。

3.4 伪响应式的常见误区

这里想提醒一个很容易踩的坑：图片格式和尺寸都没有真正优化，只改了标签写法，看起来像响应式，其实是伪响应式。

什么意思呢？比如你手头只有一张原始的2000像素大图，你却写成了：

html复制<img
  srcset="photo.jpg 256w, photo.jpg 512w, photo.jpg 1024w"
  sizes="100vw"
>

srcset里三个候选都是同一个文件，只是w值不同。这种写法浏览器确实会去比较和选择，但不管选哪个，下载的都是同一张2000像素的大图，只是显示尺寸不同。这显然没有达到响应式图片的目的。

真正的响应式，必须为每个尺寸切出真实的图片文件。2000像素的原图，分别生成256、512、1024等不同宽度的版本，然后放到srcset里。这样小屏设备加载小文件，大屏设备加载大文件，流量和画质才能同时兼顾。这也是我接下来要讲的自动化脚本的核心价值——不用手动去处理每张图，用脚本一次性生成所有尺寸。

4. 实操：从零搭建自动化WebP图片流水线

4.1 项目目录结构与脚本设计思路

先明确一下我们要做什么。整个流水线的目标：把一个目录里的原始JPEG/PNG图片统一处理，输出多个尺寸的WebP文件，同时生成一份可以直接粘贴到HTML里的响应式图片标签。

我先说目录结构，规划好了后面处理逻辑会很干净：

code复制project/
├─ original-images/     # 原始图片，放这里然后跑脚本
│   ├─ hello.jpg
│   └─ world.png
├─ output-images/       # 输出图片，按尺寸分目录
│   ├─ 256/
│   ├─ 512/
│   ├─ 1024/
│   └─ 2048/
├─ optimize.js          # 优化脚本
└─ package.json

这个结构里有两个关键选择。第一，原始图片和输出图片严格分离，避免脚本在读文件时候把自己生成的WebP再读一遍，造成死循环。第二，输出目录按宽度分目录组织，文件名本身带尺寸后缀，这样后面生成HTML的时候很容易拼接路径。

脚本的设计思路也很直接：

1. 遍历original-images目录下所有jpg/png文件。
2. 对每个文件读取元数据，拿到原始宽度。
3. 根据预定义的尺寸列表，对每个宽度做一次缩放和WebP转换。
4. 如果原图宽度小于目标尺寸，直接跳过，不为小图强行放大。
5. 输出到一个汇总的JSON文件，里面记录每张图的文件名、候选尺寸和对应URL。

这个设计的好处是容错性强，不会因为某张图太小就报错。而且输出JSON是为了后面生成HTML模板时直接使用。

4.2 完整脚本实现与逐行解析

下面是我实际在用的optimize.js，代码不算长，但把整个流程包装得很完整：

javascript复制const sharp = require('sharp');
const path = require('path');
const fs = require('fs');
const { glob } = require('glob');

const INPUT_DIR = './original-images';
const OUTPUT_DIR = './output-images';
const SIZES = [256, 512, 1024, 1536, 2048];

// 按图片类型设定不同质量
// 截图、UI图这类细节锐利的，质量可以高一点；照片类可以略低
const QUALITY_MAP = {
  'screenshot': 90,
  'photo': 80,
  'default': 82
};

// 一个简易的类型判断函数，实际使用时可以按需求调整
function getImageType(filePath) {
  const name = path.basename(filePath).toLowerCase();
  if (name.includes('screenshot')) return 'screenshot';
  if (name.includes('photo')) return 'photo';
  return 'default';
}

async function processFile(filePath) {
  const fileName = path.basename(filePath, path.extname(filePath));
  const type = getImageType(filePath);
  const quality = QUALITY_MAP[type];

  const metadata = await sharp(filePath).metadata();
  const originalWidth = metadata.width;

  console.log(`处理: ${fileName} (原图宽度: ${originalWidth}px)`);

  const candidates = [];

  // 对每个目标尺寸，判断是否小于原图宽度
  // 只有小于原图宽度才生成，避免把小图强行放大
  for (const width of SIZES) {
    if (originalWidth <= width) {
      continue;
    }

    const outputPath = path.join(
      OUTPUT_DIR,
      String(width),
      `${fileName}-${width}.webp`
    );

    await sharp(filePath)
      .resize({ width })
      .webp({
        quality: width > 1536 ? quality - 5 : quality,
        effort: 4
      })
      .toFile(outputPath);

    candidates.push({
      width: width,
      url: `/output-images/${width}/${fileName}-${width}.webp`
    });
  }

  // 同时生成原始宽度的WebP，作为最终的兜底
  if (originalWidth > 2048) {
    const outputPath = path.join(
      OUTPUT_DIR,
      'original',
      `${fileName}.webp`
    );

    await sharp(filePath)
      .webp({ quality })
      .toFile(outputPath);

    candidates.push({
      width: originalWidth,
      url: `/output-images/original/${fileName}.webp`
    });
  }

  return {
    name: fileName,
    sizes: candidates
  };
}

async function main() {
  // 确保输出目录存在
  for (const size of [...SIZES, 'original']) {
    fs.mkdirSync(path.join(OUTPUT_DIR, String(size)), { recursive: true });
  }

  const files = await glob('**/*.{jpg,jpeg,png}', {
    cwd: INPUT_DIR,
    absolute: true
  });

  const summary = [];

  for (const file of files) {
    try {
      const result = await processFile(file);
      summary.push(result);
    } catch (err) {
      console.error(`处理失败: ${file}`, err);
    }
  }

  fs.writeFileSync(
    path.join(OUTPUT_DIR, 'manifest.json'),
    JSON.stringify(summary, null, 2)
  );

  console.log(`完成，共处理 ${summary.length} 张图片`);
}

main();

这段代码里有两个容易忽略的点，我说一下为什么这么设计。

第一个是SIZES列表的选择。256、512、1024、1536、2048这组数值不是拍脑袋来的，它大致覆盖了手机小屏、手机大屏、平板、桌面端和2倍屏桌面端的常见需求。特别是1536这个尺寸，在很多桌面端的半宽布局里恰好够用，512和1024又是移动端主力。如果你的站点图片布局比较特殊，可以自己调整这组数值，但建议不要只保留一两个尺寸，那样响应式效果就大打折扣了。

第二个是webp()方法里的effort: 4这个参数。它控制编码器的压缩努力程度，范围是0到6，数值越高压缩率越好但编码时间越长。我之前测试过，effort从默认值改成4到6，体积能再缩小一些，但处理时间也成倍增长。对于批量处理场景，4是一个效率和压缩率平衡得比较好的点。如果你不赶时间，或者图片量不是特别大，直接调成6也行。

4.3 根据manifest生成HTML片段

图片转换完成之后，有时候你不想手写那串srcset和sizes，就可以加一个函数，直接从manifest.json生成HTML片段。我在脚本里加了这么一段辅助逻辑：

javascript复制function generateHtmlSnippet(item, altText, sizesAttr = '100vw') {
  if (!item || item.sizes.length === 0) {
    return '';
  }

  const srcset = item.sizes
    .map(s => `${s.url} ${s.width}w`)
    .join(',\n          ');

  return `<img
  srcset="${srcset}"
  sizes="${sizesAttr}"
  src="${item.sizes[0].url}"
  alt="${altText}"
  width="${item.sizes[item.sizes.length - 1].width}"
  height="auto"
  loading="lazy"
>`;
}

这段代码会读取manifest.json里某张图片的候选尺寸列表，按w描述符的格式拼出srcset，然后填好src、alt、width等属性。你只需要在Node里调一下：

javascript复制const manifest = require('./output-images/manifest.json');
const snippet = generateHtmlSnippet(manifest[0], '我的示例图片');

出来的HTML片段可以直接贴到博文或页面里，不用每次手敲。这个功能对内容维护者特别友好，因为图片处理和HTML生成变成了两件独立的事，谁都能操作。

4.4 把脚本接入日常开发流程

脚本写完只是第一步，关键是它能不能融入你的日常开发流程。最简单的方式是用npm scripts管理：

json复制{
  "scripts": {
    "images": "node optimize.js",
    "build": "npm run images && YOUR_BUILD_COMMAND"
  }
}

之后每次新增图片，只要把原始图片丢进original-images目录，跑一下npm run images，所有尺寸的WebP就自动生成好了，再根据manifest.json的内容把HTML片段贴进页面即可。

如果图片变更频繁，还可以加一个监视模式。用chokidar这个库监听目录变化，一旦有新增图片就只处理那一张，不用每次都全量跑。不过对于大多数个人站点来说，全量跑一次也就几秒钟的事，我自己的200张图片全量处理大概不到半分钟，其实不太需要监听模式。但如果你的图片量特别大，比如几千张，那就建议加监听了。

5. 常见问题与排查技巧实录

5.1 浏览器加载了错误的图片尺寸怎么办

实际使用中最常见的现象：明明写了srcset和sizes，但DevTools里看到浏览器还是加载了最大的那张图，页面加载速度没有明显改善。这种情况我建议先按下面几步排查。

第一步，检查Network面板里实际加载的文件尺寸。右键经过浏览器请求的图片，能看到具体返回了哪个文件、文件多大。如果加载的是2048像素的图，但当前屏幕明明只有375像素宽，说明浏览器在比较候选文件时认为大图更合适。

第二步，看一下sizes属性是否写对。sizes如果写成了(max-width: 640px) 100vw，但页面容器实际只有400像素宽，浏览器按照sizes算出来的渲染宽度偏大，自然会去选更大的图。这里有个隐含逻辑，sizes描述的是“图片在页面布局中占多宽”，它由你的CSS决定，而不是由图片实际需要的宽度决定。所以如果你的页面布局里图片实际显示宽度比sizes声明的要小，浏览器就会选过大。

第三步，检查浏览器的Device Pixel Ratio。现在很多人用Retina屏幕，DPR是2，浏览器会按两倍的像素密度去选择图片。它在375像素宽的屏幕上需要750像素的图片数据，如果你没有生成768这个档位，它可能直接跳一档，选了1024或者更宽的图。这种情况下不用太担心，浏览器是按规则选的最优解，只是我们要额外注意生成的尺寸档位要足够密集。

还有一个实用的调试技巧：在Chrome DevTools里打开Rendering面板，在CSS media特性那里可以模拟不同的屏幕宽度。这样不用真的换设备，就能快速测试在不同视口下浏览器到底会加载哪个图片文件，非常适合调试响应式图片。

5.2 WebP图片在本地无法预览

日常开发中不少人会遇到一个问题：下载下来的WebP图片，在Windows自带的照片应用里打不开。这不是WebP格式有问题，也不是转换脚本写的不对，纯粹是本地看图工具没跟上。

Windows的照片应用在更新到新版之后基本支持WebP，但旧版本确实不行。解决办法很简单：直接用Chrome、Edge这类浏览器打开WebP文件，或者在Windows里安装官方的WebP组件包，安装后资源管理器就能生成缩略图了。macOS的预览应用从Catalina开始原生支持WebP，基本没这个问题。

在判断问题归属的时候，要区分“图片文件本身有问题”和“看图工具不支持”。判断方法也简单，把WebP文件拖到浏览器里，如果能正常显示，说明文件没问题，那就是本地工具的问题。这个区分能省去很多不必要的排查时间。

5.3 转换后的WebP看起来比原图模糊

图片转成WebP之后视觉上变模糊了，这是另外一个高频问题。我先给结论：绝大多数情况是质量参数设太低，或者是图片类型和质量值不匹配。

WebP在质量值为75以下时，对一些边缘锐利、对比度高的图片会出现明显的“振铃效应”，差不多就是在文字边缘或者UI图标周围出现光晕一样的失真。所以如果你的页面里大部分是文字截图、代码截图、UI界面图，建议WebP质量设在90上下。普通照片类图片则用80到85，人眼几乎分辨不出区别，但体积控制得很好。

我个人习惯是按图片类型区分质量，而不是统一用一个值。截图类的细节一旦糊了就非常显眼，照片类稍微损失一点细节完全看不出来。这也是为什么我在上面的脚本里加了QUALITY_MAP这个配置——专门为不同图片类型设置不同质量。

还有一个情况容易被忽略：如果我们在CSS里把一张小图强行放大到很大的尺寸，比如对一个256像素宽的图片设置了width: 800px，它显示出来一定会糊。这不是WebP压缩的问题，而是图片本身的像素数量不够用了。排查的时候要确认sizes和srcset选的图片尺寸确实匹配当前的布局尺寸。

5.4 透明PNG转WebP后出现黑底

透明图片转WebP之后背景变成黑底，这个坑踩过的人应该不少。这里我说两个原因。

第一，源图本身可能没有保存透明通道。有些图片看起来是透明的，但保存成白底JPG了，这种情况转成WebP当然不会透明。用PS、Figma这类工具导出时，要确保导出格式是PNG且勾选了透明背景。

第二，转换工具在处理alpha通道时出了岔子。sharp库处理PNG到WebP的透明通道默认是没问题的，但如果你用某些在线工具，或者自己写代码时没有显式处理alpha通道，就会出现透明转黑底的现象。使用sharp时，可以通过设置alphaQuality参数来让透明通道的压缩保持在高质量：

javascript复制sharp(filePath)
  .resize({ width: 1024 })
  .webp({ quality: 80, alphaQuality: 100 })
  .toFile(outputPath);

alphaQuality控制的是透明通道的压缩质量，默认值虽然是100，但如果你在链式调用中设置了quality为较低的值，最好显式确认一下alphaQuality没有被一并压低。

5.5 缓存与CDN之间的那些事

图片处理完成后，如果你把站点放在了CDN或者静态托管平台上，还有一个容易踩的坑是缓存更新。我遇到过的情况是：本地更新了图片，重新构建部署之后，线上看到的还是旧图。原因很简单，文件名没变的时候，CDN或者浏览器把旧版本缓存了。

解决办法有两个方向。第一个方向是文件名带内容哈希。简单理解就是，文件内容变了，哈希值就变了，文件名也跟着变，CDN和浏览器自然会把新文件当作一个新的URL去请求。具体实现上，可以在优化脚本里用Node的crypto模块计算文件内容的MD5，然后拼到文件名后面：

javascript复制const crypto = require('crypto');

function hashFile(buffer) {
  return crypto.createHash('md5').update(buffer).digest('hex').slice(0, 8);
}

生成的图片名为hello-1024-a1b2c3d4.webp，内容变了哈希就变，缓存问题从根源上解决。

第二个方向是在HTTP响应头里设置Cache-Control和ETag。但如果你用的是纯静态托管，没有权限改服务端配置，那还是文件名加哈希更实在。我比较推荐第一个方案，因为它在任何静态托管平台上都能生效，不用依赖服务端的配置。

6. 扩展：还能怎样进一步压榨图片性能

6.1 AVIF格式的引入

如果你的浏览器支持矩阵允许，可以考虑朝AVIF更进一步。AVIF是基于AV1视频编码的图片格式，它的压缩率比WebP再高20%到30%。我试过把同一张照片分别存成WebP和AVIF，WebP是120KB，AVIF只有85KB左右，视觉差距几乎看不出来。

当前AVIF在Chrome、Firefox、Edge这些主流浏览器上早就支持了，Safari也从16.4开始支持。所以在实际部署时，可以把AVIF加上去，用picture元素做多格式降级，这样支持AVIF的浏览器会用AVIF，不支持的自动走WebP，再不支持的走JPEG。成本就是你需要额外生成一套AVIF文件，但对于自动化脚本来说，代码改动很小：

javascript复制await sharp(filePath)
  .resize({ width: 1024 })
  .avif({ quality: 65 })
  .toFile(outputPath);

这里注意AVIF的质量建议比WebP再低一些，65到70比较合适，因为AVIF在更低的质量下依然能保持不错的视觉表现。

6.2 懒加载占位图与感知性能

除了格式和尺寸，还有一类优化是提升感知性能，不是真的减少数据量，而是让用户觉得页面加载更快。最简单实用的方案是使用模糊占位图。

大致思路是：首屏只加载一个非常小、非常模糊的WebP缩略图，比如宽度只有16像素，体积可能就几百字节。然后用IntersectionObserver在图片进入视口的时候，把真实图片替换上去。这样做的好处是，用户在滚动页面的时候不会看到一片空白，而是先看到模糊的轮廓，然后图片清晰起来。网易云音乐、Medium这些产品都有类似的做法，体验确实不错。

不过要提醒一下，这个方案会增加代码复杂度，不能只靠HTML标签搞定。如果你的站点图片数量不是特别多，加载速度本身也没有太大问题，可以先不加这个功能，优先级低于前面的格式和尺寸优化。

6.3 与现有框架的集成方式

如果你用的不是纯HTML静态站点，而是React、Vue这些框架，图片优化也有对应的更自动化的方案，但底层思路仍然是类似的。

在Vite环境里，可以直接用vite-plugin-imagemin这类插件做构建时压缩和格式转换。在Next.js里，next/image组件自带响应式图片、懒加载、WebP/AVIF转换，开箱即用。这些工具的底层无外乎就是sharp或者类似的原生图片处理库，封装成了构建插件的形式。

但如果想真正理解这些组件为什么这样配置，以及遇到问题时怎么排查，还是建议先把本文里讲的原生机制搞清楚。框架组件的配置选项那么多，本质上都是对srcset、sizes、loading、fetchpriority这些原生能力的封装。我之前遇到过几个朋友，用next/image配置了半天发现图片格式没生效，最后发现是没配好formats字段，这个字段底层就是把图片从JPEG转成WebP/AVIF。

所以不管你的技术栈怎么变，先掌握最底层的一套机制，后面用任何框架都能举一反三。

我自己的体会是，图片优化这件事，做一次流程梳理之后，后面就变成了一件很省心的日常操作——每次丢图进目录，跑脚本，贴HTML，完事。核心其实就三件事：格式选对、尺寸给够、加载时机安排好。技术细节会慢慢过时，格式化工具会更新换代，但这三个原则基本不会变。如果你也在被页面加载速度折磨，试着先把图片这套流水线搭起来，我猜你会有种“这才对嘛”的感觉。