图片尺寸对网页速度还有影响吗

直接给结论：仍然影响，而且比多数人以为的严重得多。浏览器下载的是文件本来的尺寸， 不管你把它画进多小的框里。一张 4000 像素的照片被塞进 400 像素的卡片，访客就为十倍于他实际能看到的像素买了单。 上传之前先改尺寸，然后核对本文给出的那两个数字。

大家聊图片体积的时候，注意力几乎都在「压缩」上。但在多数网站上，更大的问题其实更简单、也更少被提起： 图片被画进去的地方，远小于承载它的那个文件。

没人看的那个浪费

一张手机照片大约 4000 像素宽。把它当成卡片缩略图放进页面，浏览器大概把它画成 400 像素。 剩下那 3600 列像素，每一列都被下载了、解码了、在内存里放着，最后被缩放这一步扔掉。

真实数字比听上去更糟，因为像素数和长度是平方关系。4000×3000 是 1200 万像素，400×300 是 12 万像素 —— 后者是前者的 1%。文件大小的差距大致也是这个倍数。

所以，一个展示八张商品缩略图的页面，可能正在传输 12MB 的图片数据，来显示八张实际各只有 12 万像素的图。 这笔账访客全部用下载时间、解析时间和内存付掉了。

「浏览器会帮我缩放」不是理由

浏览器确实会把它缩小。但这件事发生在整个文件已经穿过网络之后，而穿网络恰恰是贵的那一部分。 而且浏览器在时间压力下做的缩放，不是专业工具那种从容的重采样，而是一个快速近似 —— 这正是尺寸过大的图有时候在屏幕上看起来有点发虚的原因之一。

还有一笔很少被提到的成本：内存。解码后的图片在内存里占「宽 × 高 × 4 字节」，和它在磁盘上压得多好无关。 一张 4000×3000 的照片解码后约占 48MB。在手机上，一个页面放八张这样的图，就真的有可能触发浏览器在滚动时 反复丢弃并重新解码图片 —— 表现出来就是画面闪。

发布前值得核对的两个数字

第一：图片被画进去的那个框，实际有多宽

不是文件的宽度，是显示的宽度。用浏览器的开发者工具选中那个元素，看它渲染出来的尺寸。 在响应式布局里这个值随视口变化，所以要按你布局支持的最宽断点来检查。1440 像素屏幕上的通栏主图， 1600–2000 像素宽通常就对了：够高清屏用，也不夸张。

第二：在这个宽度下，文件是不是大得过分了

尺寸合理之后，剩下的问题是「每像素多少比特」。照片类 JPEG 的合理区间大约是每像素 0.5–1.5 比特。 所以一张 1200×900 的照片，应该落在 70KB 到 200KB 之间。如果是 900KB，那就有问题了 —— 要么质量设得过高，要么这文件压根没压过。

这个公式值得记住，因为它让你不打开任何工具就能一眼看出毛病：

每像素比特数 = (文件字节数 × 8) ÷ (宽 × 高)

那高清屏怎么办

一个 CSS 像素对应两三个物理像素的屏幕确实存在，给它们只发 1 倍图，看起来是会发虚。 但天真的做法 —— 给所有人发 3 倍图 —— 会让你的图片体积变成三倍，而只有一部分访客看得见这点好处。

正确做法是 srcset：给浏览器一组候选，让它根据设备像素密度和当前视口宽度自己挑。 实际执行就是：产出两三个尺寸，剩下的交给浏览器。如果渲染宽度是 800 CSS 像素， 一般准备 800、1600，有时再加一个 2400 的版本。

如果你没有权限改页面结构，那么「按渲染宽度的 2 倍出一张图」是个不错的折中： 在高清屏上够锐利，同时仍然只是原始相机文件的一个零头。

该按什么顺序做

1. 先改到实际要显示的尺寸。这是最大的一笔，绝大部分节省都在这里。用 尺寸调整工具时，建议设「最大宽度」而不是精确尺寸， 这样长宽比会被保持，奇形怪状的图也不会被拉变形。
2. 再选对格式。照片用 WebP 或 JPEG，截图和纯色图形用 WebP 或 PNG。 理由写在格式指南里。
3. 最后才调质量。而且调到你肉眼看不出差别就停 —— 照片通常就在 75 到 80 附近。 细节见压缩实操那篇。

把顺序做反，是网页性能优化里最常见的一种白费力气：在一张比应有尺寸大十倍的图上， 仔仔细细地调压缩参数。

一个大致的感觉

上面这些数字是按照片估的。同样渲染宽度下，一张界面截图用无损 PNG 存，往往明显更小， 因为纯色压缩率极高。

怎么在不把文件发出去的前提下做完这些

上面全是本地操作 —— 量、改、转、比。每一步浏览器都能在没有服务器往返的情况下完成， 附带的好处是整个过程快到可以真的反复试：改一版、看一眼、调一下、再看一眼。 合适的尺寸就是这么试出来的，而如果每试一次都要上传一遍，这件事根本做不下去。

这里的尺寸调整工具和压缩工具 都是这么工作的，可以一次处理一批，而且没有任何东西离开你的电脑。