2026-10-02
图片 CDN 与自建托管的选择，几乎每个做网站的人都会遇到一次。直觉答案是流量小就自己扛、流量大了上 CDN，但真正决定结果的不是流量，而是你的访问者分布在哪里、图片有多少种尺寸变体、以及你愿不愿意维护一套转码链路。这篇把两种方案的账单、延迟表现和运维负担拆开对比，给出一套能直接套用的判断标准，以及一个绕开取舍的混合做法。
很多人把图片 CDN 理解成缓存图片的服务器，这个理解偏窄。现代图片 CDN 至少替你处理四件事。
这四件事里，最值钱的通常不是分发，而是格式协商和尺寸变体。手工做这两件事意味着你要为每张图维护多个版本，并在前端写正确的 srcset。
自建不是免费的，它只是把费用从账单转移到了人身上。需要自己承担的部分如下。
一个中型站点把这些做完，通常是一次性的几天工作量，加上之后每次依赖升级都要回头检查一遍。
首屏大图直接影响 LCP。两种方案在延迟上的差异主要来自第一字节时间和连接复用。
如果你的访问者集中在同一个国家，且你已经把图片压到了合理体积，CDN 带来的 LCP 改善会比你预期的小。图片本身体积的影响往往大于分发方式，这一点在 /blog/image-compression-web-performance-guide 里有具体数据。
图片 CDN 的计费通常按三项叠加。
自建的账单则是带宽加存储加服务器，外加无法计入账单的人力。真正容易踩的坑是请求数：一个页面 30 张图、每张 3 个变体，在移动端和桌面端各请求一次，请求量会快速吃掉免费额度。估算方法是用日均 PV 乘以单页图片数，再乘以平均变体数，得到月请求数后对照厂商的阶梯价格，不要用月流量去估算，误差会差一个数量级。
这类站点上 CDN，多数时候买到的是省心，不是性能。
不必二选一。一个务实的组合如下。
这样既避免了实时转码的请求计费，又不用自己维护全球节点。
如果访问者集中在单一地区且图片已经压到合理体积，收益有限。先把图片体积降下来通常比换分发方式更有效。
不能。CDN 负责分发和转码，不解决原图过大的问题。一张 3MB 的原图即使经过 CDN，弱网下的加载体验依然很差。
变体数量少且访问集中时，预生成更省。变体组合多、长尾访问分散时，实时生成更省存储，但要留意请求计费。
通常不需要再做一层。全站 CDN 已经解决了就近分发，缺的是格式协商和尺寸变体，这部分自建转码链路就能补齐。
先把体积降下来，再谈分发。image-compressor-saas.shop 在浏览器本地完成压缩，文件不上传服务器，你可以先把原图压到合理体积，再决定要不要上 CDN，多数站点在压缩之后会发现自建完全够用。相关阅读：/blog/image-compression-web-performance-guide、/blog/core-web-vitals-fix-lcp-images、/blog/avif-vs-webp-in-depth。