是的，用 WebP。2026 年，对于你自己掌控的网站，这就是完整答案：每个浏览器多年前就能渲染 WebP，文件比被替换的 JPG 或 PNG 小 25–35%，访客体验的唯一变化是页面加载更快。真正有意思的问题是操作层面的：哪些图值得转、怎么交付 WebP 才不搞坏东西、哪些地方 PNG 和 JPG 仍然该留着。这篇指南讲的就是这些。
什么值得转，什么别动
不是每张图都配得上这份功夫。决策树很短：
先转大件。 首屏大图、产品照片、文章配图——一切以几百 KB 计的东西。一张 450 KB 的 JPG 变成 300 KB 的 WebP 是真实的收益，再乘以每个访客的每次页面加载。产品网格和相册是复利发生的地方。
转有分量的 PNG 图形。 以 PNG 传上去的截图、示意图和透明 UI 图，转成有损 WebP 后体积骤降；即使无损 WebP 也比 PNG 小约四分之一。技术上的原因见 WebP 与 PNG 对比。
小文件别碰。 一个 4 KB 的图标是四舍五入的误差。转它省不下任何可感知的东西，还白搭流水线里的一步。规则：如果一个文件已经小到从来没进入过你的脑海，那就继续别想它。
迁移路径
- 盘点关键页面上的图片——首页、核心落地页、产品模板。你的分析工具知道是哪些。
- 批量转换 PNG 和 JPG 素材。 把文件夹拖进 PNG 转 WebP 或 JPG 转 WebP；两者都在你的浏览器本地运行，吃下整个文件夹，交回一个 ZIP。没有任何东西离开你的机器——素材是客户成果时这一点尤其重要。
- 保留原图。 WebP 常用模式是有损的。你的 PNG/JPG 母版仍是未来任何重新编码的事实源头。
- 替换模板里的引用并重新上传。转换器保留文件名、只改扩展名，所以在模板里全局替换
.png→.webp就能覆盖大头。
如果你的网站跑在 CMS 上
动手转换之前先查一下。现代 WordPress 接受 WebP 上传并像其他图片一样生成各种子尺寸，很多托管服务和 CDN 还能在边缘自动转 WebP——那种情况下，迁移是一个设置页面的事，不是文件操作。手工转换仍然适用于静态站、手写模板，以及任何媒体流水线比这个格式还老的 CMS。
带回退地交付
<picture> 元素让现代浏览器拿走 WebP，古老的一切则落回原图：
<picture>
<source type="image/webp" srcset="/img/hero.webp" />
<img src="/img/hero.jpg" alt="Hero image" width="1600" height="900" />
</picture>
浏览器挑第一个它能看懂的 source；其余的一切照常读 <img>，仿佛什么都没发生。2026 年这属于双保险——浏览器的 WebP 支持早已普及——但它只花一行代码，就把这个问题彻底从桌上拿走。替代方案是基于 Accept 头的服务器端内容协商，在 URL 层面达成同样的效果；它很强大，但把复杂度挪进了服务器配置——大多数小网站应该拒绝这笔交易。
保留 PNG 或 JPG 的地方
即使在全站 WebP 的网站上，三类东西仍留在旧格式：
访客要下载的文件。 "下载媒体资料包"这种链接应该给 PNG 或 JPG，因为接收的人可能拿任何东西打开。浏览器之外的支持缺口是真实的——就是我们在 WebP 与 JPG 对比里画过的那道。
Open Graph 和邮件图片。 og:image 和 Newsletter 素材是被爬虫、聊天应用和邮件客户端抓取的，它们的图像栈比浏览器老得多。用 JPG 或 PNG 交付，否则就接受部分预览静默失败。
你的母版文件。 永远。WebP 是运输集装箱，不是档案馆。
想了解每种格式各自位置的完整地图，网页图片格式指南有全景。
切换之后
把核心页面在切换前后各跑一次测速。提升会出现在它该出现的地方：LCP（最大内容绘制）、页面总重量，以及字节最疼移动端体验。如果某个页面几乎没动，说明它的图片本来就小——也就是说上面的决策树完成了自己的工作，告诉过你跳过它们。把前后对比数字存好，它们是迁移网站其余部分的论据。
转换本身是这个项目里最快的部分。一个文件夹的产品图过一遍 PNG 转 WebP 不到一分钟；改模板花的时间更长。从你最重的页面开始——让瀑布图去说服那些仍觉得这事可做可不做的人。