工具

如何减少图片文件大小,让网站更快

沉重的图片,是网站感觉慢的头号原因。一个典型的商品或营销页面会输出 2 MB 多的重量,其中大约一半是图片——而且以全分辨率、全画质、错误的格式在传输。体积一上去,最大内容绘制时间就会突破 2.5 秒目标,跳出率被推高,转化悄然流失——头图每多 100 KB,移动端和桌面端两边都会损失可量化的参与度。本季度只能做一轮性能优化的话,就做图片。

为什么沉重的图片会拖垮页面

Google 的 Core Web Vitals 把页面上最大的图片当作最大内容绘制(LCP)元素。目前的「良好」门槛是 2.5 秒以内,按真实用户的第 75 百分位统计。HTTP Archive 显示,桌面页面的中位重量约 2.5 MB, 手机页面的中位约 2.2 MB,而图片始终占到 约 50% 的重量。因此单单一帧 1.2 MB 的头图照片,就能决定你的 LCP 评分是绿、黄还是红——这一切都还在你精心写的 JavaScript 开始执行之前。

商业层面同样清晰。Google 自己的研究表明,移动加载时间每改善 1 秒, 零售、旅游、潜客开发等站点的转化率都会随之提高。在不稳定的 4G 连接下, 600 KB 的图和 60 KB 的图会被当成两个截然不同的产品:前者是卡顿滑入, 后者是瞬间完成。减少图片文件大小,是现成的最便宜的性能优化手段—— 不必重写服务端,不必改架构,只是少送一些本来不需要的字节。

4 步缩减小流程

你不必依赖图片优化服务或构建流水线。现代图片 CDN 内部做的同一套事, 你可以在浏览器里一张张完成,一分钟内搞定。请按顺序执行,因为每一步都依赖前一步。

步骤	动作	常见节省幅度
1. 缩到显示尺寸	把位图缩到布局实际渲染的最大尺寸。一张 4000×3000 的照片喂进 1200×600 的位置,90% 以上的像素根本是多余的。	60–80%
2. 把画质设到 75–80 左右	把编码器的画质滑杆拖到大约 75–80(针对照片)。正常观看距离下视觉差异几乎不可见,字节节省却非常显著。	30–50%
3. 转为 WebP	把缩好尺寸、重设过量化的位图再编为 WebP。同尺寸、同画质下, 通常只占原 JPG 或 PNG 的三分之一字节。	25–35%
4. 清除元数据	删除 EXIF、IPTC、XMP、色彩配置和作者注释。一张手机照片可能附带 50–100 KB 浏览器根本不会渲染的元数据。	2–10%

四步叠在一起,常常能把 1.2 MB 的原图压到 150 KB 以下,在常见网页尺寸下完全看不到画质损失。

逐格式指引

不同的视觉任务需要不同的格式。请按内容选,不要按习惯选。

照片。JPG 画质 75–80,或同等画质的 WebP。AVIF 还能再省,但编码时间偏长,且在少数旧设备上不兼容—— 如果兼容性优先,就退回 WebP。
标志、图标、UI 图形。需要透明就用 PNG, 更佳的选择是带 Alpha 通道的 WebP。如果源是矢量,SVG 更小,而且能无限制缩放、不带位图瑕疵。
插画与平面美术。WebP 或 PNG。WebP 赢在字节数,PNG 赢在无处不在的兼容性。若两个都要,用 picture 元素生成一份 WebP,再用 PNG 当兜底。

想把一整批旧素材从某个格式切到另一个?图片转换器支持一次性把 JPG、PNG、WebP 与 AVIF 批量重新编码,并并排显示预览, 让你在点下确认之前先看清画质取舍。

设定预算

没有预算的优化,只是把图片稍微变小。给页面上的每类资源设一个硬性字节上限,在 CI 里强制执行,页面平均重量就会应声下降。一个内容为主的网站, 合理的起步预算:

头图:100 KB 以内。这是你的 LCP 元素, 再重一点就是在用 Core Web Vitals 付代价。
画廊缩略图:每张 50 KB 以内。乘以首屏可见的缩略图数,就是个站得住脚的预算。
Open Graph 图:200 KB 以内。爬虫和社交预览会反复重抓这张,严的上限让链接卡片保持轻快。
首屏图片总计:300 KB 以内。突破这条线, 再多 code-splitting 也救不回 LCP。

跑一次 4 步流程,把输出贴进上面的预算,再上线。页面更快、Core Web Vitals 更好、访客更满意——而你少送的每一个字节,都是你不必为它付费传输的字节。