响应式图片的终结

# 响应式图片的终结 来源：https://piccalil.li/blog/the-end-of-responsive-images/ 我等了十四年，就为了写这篇文章。 **十四年**，只为告诉你一项相对较新的 Web 图片机制。对你来说，只是几个字符的改动，却能从根本上改善图片的开发体验；对用户来说，则是无声、无缝、**巨大**的前端性能提升，永远织进 Web 的肌理。 而对我来说，是时候坦白我“阴险”的谋划了——这份忏悔酝酿了将近十五年。 当年，我是 RICG（https://www.w3.org/community/respimg/）的主席——这个“海盗电台”式的 Web 标准组织，负责把响应式图片标记带进 Web 平台。你们中有人亲历过：响应式 Web 设计刚诞生时，平台能力处处掉链子，一群前端“散兵游勇”集结起来，硬闯进并不欢迎我们的标准流程。我们要求与浏览器厂商平起平坐，为设计师、开发者，乃至最终用户发声。人数很快破百，历经数年迭代、无数被废弃的草案与原型，在古董邮件列表和 IRC 频道里吵出共识，最终与浏览器厂商一起敲定了可用的语法。 然后，我们把它**落地**——众筹资金给浏览器写独立实现、做 polyfill 推动落地、把新特性塞进主流 CMS、写文章、做演讲，还顺手发了——容我吹一句——Web 标准史上最酷的 T 恤。 我猜，同样多的人完全没经历过这些。对你们来说，响应式图片标记自你们建站以来就存在：晦涩、 opaque、不可回避，一套常让人抓狂的“黑魔法”。如果你是后者，请允许我自我介绍： **是我干的。** 看这里，别眨眼——**我**。 每次你想不通浏览器为何从 `srcset` 里挑了那张图？你不知道，但幕后黑手就是我。 每次你得拉个巨大第三方库来解析显然不是给人看的语法？我不但罪魁祸首，可能还亲手写了那库。 当你用某个书签工具，跑一遍工作流只为生成一个**差不多**对的 `sizes`？当一切太痛苦，你索性摆烂，把巨大原图扔给所有用户——他们得不到好处，却承担所有流量成本？ 别自责，全算我头上。 我不仅没阻止这些语法成为标准，还是响应式图片的**旗手**——为你们咒骂过的那些标记**拼命**站台。 哦，还有更气的：**我也讨厌它们**。 我写的每篇演讲、每篇文章——那门[课程](https://web.dev/learn/images)、那本[专著](https://abookapart.com/products/image-performance)——全是咬牙切齿地完成的。有些语法，我第一眼就深恶痛绝，却也在同一秒成了它们最响亮的吹鼓手。 我不道歉。 再来一次，我还会这么干。 --- ## 那头怪兽 {#the-beast} 先别误会：我不讨厌**响应式图片**这个概念。问题必须解决，没得选。彼时——亦如今日——[网页传输体积的大头](https://httparchive.org/reports/state-of-the-web?start=latest#bytesperpage)是图片。一张弹性图片必须大到覆盖它在布局中的最大尺寸；没有响应式图片的话，一张在 2000 px 宽布局里全幅展示的图，就得**人人**下载 2000 px 的源文件。CSS 缩放简单，但**请求**不变——用户白掏流量，却看不到好处。别忘了，那时普遍还是 3G 以下网络，又没法在保持浏览器级性能优化的前提下“按需”请求。最终方案确实有效、省流量，且为用户节省了**天文数字**的带宽。作为概念，响应式图片是 Web 平台的**绝妙**补充，我为之骄傲。 甚至，也不是所有语法我都讨厌。`picture` 我从一开始就喜欢。毕竟它是**指令式语法**，满足“我要掌控”的执念——掌控源、掌控选择条件、甚至让浏览器“算了别加载”——我后来也接受了。`picture` 让我们能安全上新格式、带可靠降级，无需一行 JS；语义清晰，还为所有媒体请求的智能决策提供模板，随新 MQ 持续进化。`picture` 很棒，人人都爱 `picture`。 今天不谈 `picture`。 `srcset` / `sizes` 则是**描述式语法**：你给浏览器一组仅尺寸不同的候选源，再告诉它图片在布局里大概多大，**绝不命令**它怎么做。浏览器凭此做唯一且极复杂的事：选出最适合当下场景的源。视觉上所有候选图一模一样，但候选源最贴合用户环境。 你既无法控制，也**无权知道**浏览器怎么选——规范里明写着“实现自定义”： > 以实现自定义方式，从 sourceSet 中选一个图像源。 > ——[来源](https://html.spec.whatwg.org/multipage/images.html#selecting-an-image-source) 吓人吧？翻译过来：浏览器“随便”挑。 这份“失控”并非偶然——我本可喊停，却亲自拍板： **开发者不配拥有控制权，甚至不配知道细节。** 十四年后，我才能坦白缘由——你肯定不会喜欢： **因为我知道你肯定搞砸。** --- ## 人力不可为之 {#a-human-work} 别往心里去，我自己也会搞砸——事实上我**确实**搞砸过，提案、原型一路错，所有人都错。最终迭代只证明一件事：**没人能搞定这部分。** `srcset`/`sizes` 那“一件事”——综合视口、DPR、用户偏好、带宽、乃至无数不可知因素来选图——包含了我们**无法**也不**应**知道的信息。 比如，我们拿不到用户网速，可惜吗？假设能拿到，让你写逻辑：“高于 ×× 用高清，低于用低清”，你会设什么阈值？我设的肯定跟你不同。于是同一网速，用户在你的站点被豪华大图砸晕，在我这儿却看高压缩图。用户到底想要啥？——答案人人不同。 你的组织想要什么？哦，会议半小时后开始，工单堆成山，现在全让你拍板。网站咋又慢了？图怎么比竞品糊？**怎么又慢了？** 一旦我们把控细节，用户就失去他们的控制权；还没完，除了网速还有无数变量。 浏览器掌握的信息比我们多得多——它**应该**也多——于是能在不麻烦我们的情况下，综合屏幕、DPR、带宽、偏好乃至未来未知因素做决策。 它还能避免浪费：缓存里已有大图就不再请求小图；能读取用户偏好，保证跨站体验一致。 说到底，我们要的是**更快图**，而非**控制图**。`srcset`/`sizes` 把这事办得漂漂亮亮——比我们亲自操刀好得多。真让我们自己算，那是灾难。 描述式语法帮我们逃过此劫，让浏览器做它最拿手的：凭手边信息高效请求唯一最优源——**只有浏览器能办到**。我们只需提供它**没有**的那点信息。 说实话，`srcset` 本身还行！全球 CMS、静态生成器、构建工具都能秒出逗号分隔的宽度列表；候选越多，请求越精准，就多几个字节标记，挺清爽。 `srcset` 我忍得了，它**还行**。 今天我们也不是来骂 `srcset`。 响应式图片不是问题：`picture` 不是问题，`srcset` 甚至也不是问题。 我们都知道问题在哪。 --- ## `sizes` 困境 {#the-sizes-dilemma} 浏览器在布局还没影的时候就得决定请求哪张图，它上哪知道图片最终占多大？视口宽度倒是有，可放在真实布局里，这 proxy 烂透了。 Web 不是满幅英雄图，而是列、网格、侧边栏、卡片、小圆头像。规范也明白：缺 `sizes`（非法）时按 `sizes="100vw"` 算，比没有强，但强得有限。 于是，我们只能**在 HTML 属性**里，用**一个字符串**，描述元素在所有断点 / 容器查询下的尺寸。 恶心。 正因为依赖布局信息，`sizes` 几乎**无法自动化**。构建工具要算出它，得“先全站构建→渲染所有页→逐图测量→回写 `sizes`”， overhead 爆炸。于是只能**手写**；而除最简单场景，**人手算不出**。 `\(min-width: 1340px\) 257px, ...` 这段出自**相对简单的布局**，你让谁裸写？靠拉窗口肉眼？猜？ `sizes` 是极少数**强制上工具**的标记，与“打开记事本就能建站”的 Web 精神背道而驰——而我**极度珍视**这种精神。 就算你硬用媒体查询描述——