随机图当封面：一张 250KB，我没让它进列表

三种封面方案#

本站的模板支持第三种：image: random 时，卡片渲染的不是一个本地文件，而是一次外部请求。

它到底返回了多大一张图#

curl -sI https://pic.060730.xyz/ri/h/42.webp

关键三行：

Content-Length: 256098                          ← 250 KB
Cache-Control:  public, max-age=0, must-revalidate
CF-Cache-Status: HIT                            ← 边缘有缓存，但浏览器每次都要问

max-age=0 意味着浏览器每次访问都要回来验证一遍。它不像我在缓存那篇里给 /_astro/ 加的 immutable —— 那张图永远处于”可能变了”的状态。

算一笔账#

对比之下，我这 19 篇文章的 51 张配图一共 3.63 MB，全部加载一遍比首页挂满随机图还省。

而且这 2.5 MB 还有一个隐含成本：它是串行增加的——卡片进入视口才加载，用户往下滚就一直有请求打出去，而每张都不便宜。

那随机图什么时候合理#

不是不能用，而是别用在”列表默认”。我总结的边界：

• ✅ 单篇文章的封面：一页就一张，250 KB 可以接受（还记得加 loading="lazy"）；
• ✅ 工具页/画廊的占位：用户明确在看图，愿意等；
• ❌ 首页列表的默认封面：10 张起步，成本 ×N；
• ❌ 移动端优先的站点：2.5 MB 在 4G 上就是几秒。

真要在列表里用，正确的做法是让接口返回缩略图（比如再压到 30 KB、宽度 400），并且给它一个正常的 Cache-Control。这两件事都得改服务端，改不了就别用。

兜底：图挂了怎么办#

外部图片还有一个绕不开的问题：对方挂了或者改规则了。本站的处理是 onerror 时隐藏图片、保留文字卡片：

<img src={image} onerror="this.style.display='none'" />

这样最坏情况是”卡片没有封面”，而不是”卡片里一个破图图标”。说实话，这个兜底本身也说明了外部图片的定位：锦上添花，不是必需品。

小结#

随机图是很典型的”看起来免费”的东西：省了自己做图的工夫，代价转移到了访客的流量和你的依赖清单上。

三条结论：

1. 列表默认不要挂 250 KB 级的随机图，成本按卡片数线性上升；
2. 单篇封面可以接受，配上 loading="lazy"；
3. 判断标准很简单：这张图属于”内容”还是”装饰” —— 装饰性的东西不该占据首屏流量的头几名。

我现在的做法是：文章有配图就用本地压缩好的 WebP（平均 70 KB、长缓存），没有就让卡片干净地只显示文字。空一块，比 2.5 MB 划算。