产品图一张 4MB？
先别换服务器，先换图。

先做一件事：打开你站上卖得最好的那个产品页，右键点开第一张图，看它多大。超过 500 KB 的，这篇就是写给你的——不是让你换服务器，是让你换图。服务器能救的是「第一字节什么时候到」，救不了一张 4 MB 的图。

一、一张图，到底在扣你多少钱？

图片的成本有三笔，只有第一笔是明账。

第一笔是带宽。4 MB 的图，在一条 1.5 Mbps 的实际移动网络上下载要二十秒出头。买家不会等二十秒，他会在第三秒就划走，而你后台只看到「跳出率 78%」，看不到「图片 4 MB」。

第二笔是内存。一张 4000×3000 的图，浏览器解码后占的内存是像素数乘 4 字节，大约 48 MB——不管它显示在屏幕上只有 300 像素宽。中低端安卓上开三个这样的页面，标签页就会被系统回收。这不是「慢」，是「白屏重载」。

第三笔是布局。图片没写宽高，浏览器事先不知道它要占多大位置，只能等图下载完再撑开。于是正文往下跳一下，买家正要点「联系我们」，按钮跑了。这一下的专业名字是 CLS，累计布局偏移。

三笔加起来，才是「你的站怎么这么慢」的完整答案。多数人只处理了第一笔，而且是用换服务器的方式。

二、为什么「压缩一下」通常没用？

因为影响体积的三个变量，权重是反的。按影响力排序：尺寸（像素）> 格式 > 编码质量。而大多数人上手就调质量，把 4 MB 压到 2.8 MB，图还糊了。

尺寸才是那个大头。一张 4000 像素宽的图，压到质量 60 依然是 4000 像素宽，解码照样吃 48 MB 内存——你只是让它变丑了，没让它变快。

正确的顺序是裁、转、再压，四步走完一张 4 MB 的图能到几十 KB：

这四步没有一步需要写代码，也不需要换主机。它需要的是「上传前过一道」的规矩，而这件事九成的站在等以后再说。

三、WebP 和 AVIF，要不要两套都备？

先说能省多少，这是有实测口径的，不是玄学：

“Lossy WebP images are on average 25–35% smaller than JPEG images of visually similar compression levels. Lossless WebP images are typically 26% smaller than the same images in PNG format.”

MDN 的格式指南：有损 WebP 比同等视觉质量的有损 JPEG 平均小 25–35%；无损 WebP 通常比同图 PNG 小 26%。注意这是「同等视觉质量」的前提——拿 q60 的 WebP 去比 q90 的 JPEG 然后说自己省了八成，是自欺欺人。

MDN · Image file type and format guide

再看兼容。WebP 现在 Chrome、Edge、Firefox、Opera、Safari 全支持，Safari 需要 14 以上加 macOS 11 以上——这个门槛在 2026 年基本等于没有。AVIF 压缩率更好，但需要 <picture> 兜底，而且不支持渐进渲染：图必须整张下完才能显示。

所以决策很简单：JPEG 兜底 + WebP 主力，这两套覆盖了全部在用的浏览器，收益已经拿走七成。AVIF 的额外一成半，等你的图片数量上了几百张、而且有人愿意维护三条编码链路时再上——否则你多出来的不是性能，是半年后没人记得怎么改的构建脚本。

四、首屏那张大图，为什么不能加懒加载？

因为懒加载的作用是「等快到了再下」，而首屏那张图本来就该立刻下。给它加 loading="lazy"，浏览器会等布局完成才发起请求，正好把最该早到的资源推到了最后。

首屏大图的地位，写在 LCP 的定义里：

“LCP reports the render time of the largest image, text block, or video visible in the viewport, relative to when the user first navigated to the page. To provide a good user experience, sites should strive to have Largest Contentful Paint of 2.5 seconds or less.”

LCP 记录的是视口里最大的那张图、那块文字或那段视频渲染完成的时间，从用户开始导航算起；良好线是 2.5 秒以内。对绝大多数产品站来说，视口里最大的那块就是产品图本身——所以 LCP 好不好，一半是图的问题。

web.dev · Largest Contentful Paint (LCP)

2.5 秒里，能分给图片的预算大概 1.5 MB，还要和 HTML、CSS、字体、脚本分。一张 4 MB 的图进场，这场考试已经结束了。

做法不复杂：首屏图正常加载，加 fetchpriority="high" 提优先级，条件允许就 preload；首屏之外的所有图才上懒加载。判断标准是「滚一屏之内还在不在视口里」，别按「看起来像配图」来分。

五、图片尺寸对不上，像素再多也是浪费

手机视口宽 390 像素，屏幕密度 2 到 3 倍，所以它真正需要的是 780 到 1170 像素宽的图。你给它 2400 像素，多出来的部分像素被丢弃，但字节照付。

srcset 就是干这件事的：同一张图导出 640、960、1440 三个宽度，让浏览器按自己的屏幕挑。这里最常见的错是只写 srcset 不写 sizes——浏览器不知道这张图在版面上占多宽，只能按 100vw 猜，于是你的三栏产品列表里，每个格子的图都按整屏宽去挑，等于白做。

还有一个更常见的误会：CSS 里写 max-width: 100% 不叫「响应式图片」，那只是「不溢出容器」。图该多大还是多大，只是被缩着显示。

六、几百张产品图，谁来管？

技术方案再对，落不到上传流程里就是零。实际卡住的地方从来不是「不会压」，是「谁来压、什么时候压」。

比较省事的做法是把规矩写死在上传口：长边 1600（详情页）、800（列表缩略图），单张不超过 300 KB，格式 jpg 加 webp 各一份。销售拍完直接拖进去，系统按规矩处理，不合格的进不去。比事后组织一次「图片大清理」有效得多——那种清理通常只有第一次，半年后又回到 4 MB。

如果没有上传口，只能走脚本，那就把顺序固定下来：裁 → 压 → 转 WebP → 生成 srcset 尺寸 → 写 alt。顺序错了白忙——先转格式再裁，等于把大图转了一遍再扔掉大部分像素。

文件名也顺手管一下。IMG_2931.jpg 换成 stainless-steel-flange-dn50-pn16.jpg，成本为零，好处有两个：图片搜索能读到，以及半年后你自己能认出这是哪张图。

七、alt 和文件名，真能带来询盘吗？

图片搜索的流量不大，但意图很明确——有人是在找具体型号、具体材质。不过 alt 的第一职责不是 SEO，是「图没加载出来的时候，这句话还在」。所以写「不锈钢法兰 DN50 PN16 实拍」而不是「产品图 1」。

还有两件比 alt 更影响成交的事。

一是缩略图风格要统一。列表页里九张图有三种背景、两种比例、两种打光，看起来就像个杂货铺，买家不会相信你能稳定交货。

二是别把文字做成图。参数表截图、证书照片、报价单图片——这些内容机器读不出、翻译不了、手机上放大就糊，而且永远无法被搜索到。能写成 HTML 表格的，就别用图。

八、现在就能照着查的清单

这张表不需要开发排期，一个人半天能把一个产品页改完。改完再去测首屏，你会发现之前怀疑的「服务器不行」，其实一直是图不行。

图不会因为「以后再说」而变小。它只会在你换完服务器、加完 CDN、买完加速包之后，还在那里，4 MB。