图片多的网站怎么用CDN？缓存、格式和加载速度怎么测

图片站、电商网站、作品集和资讯网站接入CDN以后，最容易出现一种错觉：图片已经从CDN节点返回，缓存状态也是HIT，网站就应该很快。

实际打开页面，却还是要等。商品列表一张张往外蹦，首屏大图半天才出现，手机流量下尤其明显。

这并不矛盾。CDN解决的主要是“从哪里把图片传给用户”，但一张图片最终多久显示出来，还取决于它有多大、浏览器下载了哪个尺寸、是否命中缓存、什么时候开始请求，以及页面同时抢带宽的资源有多少。

所以，图片多的网站使用CDN，不能只完成“把图片域名接入CDN”这一步。真正有效的方案应该同时处理三层问题：

1. 交付层：图片有没有从离用户较近的CDN节点返回；

2. 文件层：图片的尺寸、格式和压缩质量是否合理；

3. 页面层：首屏图片有没有被优先加载，非首屏图片有没有延后请求。

如果只优化其中一层，测试结果往往会出现“节点挺快，页面还是慢”。

先说答案：图片多的网站应该怎样接入CDN

一套比较稳妥的做法是：

• 使用独立图片域名，例如img.example.com，并让页面中的图片地址真正指向这个域名；

• 在CDN上缓存公开图片，稳定不变的图片使用较长缓存时间；

• 图片内容更新时更换文件名或版本号，不依赖用户手动清理缓存；

• 按页面展示宽度生成多个尺寸，避免手机加载桌面大图；

• 照片优先评估WebP或AVIF，同时保留兼容格式；

• 首屏主图不要懒加载，屏幕下方的图片再使用loading="lazy"；

• 用真实图片URL分别测试冷缓存、热缓存、不同地区和不同运营商；

• 最后回到浏览器检查LCP、图片总字节、请求顺序和布局偏移。

这里面没有哪一条特别神秘，难点在于它们必须配合。比如，一张4000像素、3MB的商品图即使命中附近节点，也不适合直接塞进宽度只有360像素的手机卡片里。

不同图片，不应该使用同一套策略

图片多的网站通常不是只有一种图片。Logo、商品缩略图、首屏横幅和高清原图的用途不同，缓存和加载方式也应该不同。

最常见的浪费，是为了省事只保存一份原图：列表页、详情页、弹窗和手机端全部引用它。这样虽然URL管理简单，却会让用户在每个场景都为最大尺寸买单。

图片域名接入CDN后，先确认流量真的走了节点

网站配置了img.example.com的CNAME，不代表所有图片都已经获得加速。旧页面可能仍引用源站地址，CSS背景图可能使用另一个域名，第三方编辑器上传的图片也可能绕过新域名。

接入后至少检查四件事：

页面是否真的使用CDN图片地址

打开浏览器开发者工具的Network面板，筛选Img，查看图片请求的Host。也可以查看页面源代码，搜索旧的源站域名。

需要特别留意：

• HTML中的src和srcset；

• CSS中的background-image；

• JavaScript运行后插入的图片；

• Open Graph分享图和结构化数据中的图片；

• 富文本内容里历史遗留的绝对地址。

DNS是否已经指向CDN

可以查看CNAME链：

dig img.example.com CNAME +short
dig img.example.com A +short

不同网络和地区可能被调度到不同节点IP，这是CDN的正常工作方式，并不要求全球用户得到同一个IP。如果需要判断当前域名是否已经接入CDN，可使用CDNChart的CDN检测工具，再结合服务商控制台中的CNAME状态核对。

HTTPS证书和访问权限是否正常

图片域名需要正确的HTTPS证书。页面本身使用HTTPS时，如果图片仍通过HTTP加载，浏览器可能拦截混合内容。

如果图片配置了防盗链、签名URL或Referer白名单，还要测试正常页面、搜索引擎抓取、社交分享和需要展示图片的第三方渠道。不要因为防盗链规则过严，让真实用户或搜索引擎拿到403。

响应来自节点还是源站

查看响应头中的缓存状态、Age、Via或服务商自定义头，再对照源站日志。如果每次访问都回源，即使域名经过CDN，源站压力和访问延迟也不会真正降下来。

关于接入验证的完整步骤，可以参考《CDN加速有没有生效？接入后这样检查》。

图片缓存怎么设置，既快又不会更新失败

图片通常适合缓存，但“缓存时间越长越好”只说对了一半。长缓存的前提是：图片内容变了，URL也跟着变。

不再修改的图片，可以使用长缓存

如果文件名中带有版本或内容哈希，例如：

/products/sku-1280.a84f2c.webp
/assets/logo.v5.svg

文件内容发生变化时会生成新URL，旧文件就可以安全地设置较长缓存：

Cache-Control: public, max-age=31536000, immutable

这里的31536000是一年。它适合“同一个URL下内容永远不变”的静态资源，不应该不加判断地用于所有图片。

同名图片会被覆盖，就不要盲目设置一年

如果后台上传新商品图后仍然使用：

/products/123.jpg

浏览器和CDN可能继续使用旧缓存。此时有三种办法：

• 推荐：更新图片时改成新文件名或新的版本路径；

• 次选：URL增加可控版本，例如123.jpg?v=20260919；

• 临时处理：上传后调用CDN刷新接口，并配合相对较短的TTL。

版本参数是否进入缓存键，要按CDN配置核实。如果CDN忽略查询参数，?v=2和?v=3可能仍被视为同一个缓存对象；如果CDN把所有参数都纳入缓存键，无意义的追踪参数又可能制造大量重复缓存。

图片处理参数必须进入缓存键，但不能无限组合

动态图片服务常见这样的URL：

/photo/123.jpg?w=640&format=webp&q=80

宽度、格式和质量改变了返回内容，通常必须参与缓存键。否则，请求640像素WebP的用户可能拿到1280像素JPEG，甚至出现响应格式和Content-Type不匹配。

但也不要允许任意尺寸。攻击者或爬虫可以不断请求w=641、w=642、w=643，生成大量衍生文件和缓存对象。更稳妥的做法是将尺寸限制在几个业务档位，例如：

320 / 480 / 640 / 960 / 1280 / 1920

质量也可以固定为少量预设，而不是接受任意数字。这样既提高缓存复用率，也方便估算图片处理和存储成本。

检查妨碍缓存的响应头

如果图片一直显示MISS或绕过缓存，重点检查：

• Cache-Control: private、no-store或no-cache；

• 响应中不必要的Set-Cookie；

• CDN规则是否只缓存特定后缀；

• 请求是否带鉴权信息；

• URL参数是否导致每次生成新缓存键；

• 源站是否返回错误状态或不稳定的重定向。

不同服务商对这些响应头的默认处理并不完全相同。例如，Cloudflare在其默认缓存行为文档中列出了常见可缓存文件扩展名，也说明了private、no-store、no-cache、max-age=0和Set-Cookie等情况对默认缓存行为的影响。实际部署时仍应以你所使用CDN的官方文档和当前规则为准。

如果不确定HIT、MISS和Age分别代表什么，可继续阅读《CDN缓存命中怎么看？HIT、MISS和Age怎么理解》。

JPEG、PNG、WebP和AVIF应该怎么选

图片格式不是越新越好，也不是把所有图片批量转成WebP就结束了。应该比较的是：在用户可以接受的画质下，哪个格式的文件更小、生成成本合理，并且目标浏览器能够正常显示。

JPEG：照片类内容仍然实用

JPEG兼容性好，适合照片和连续色调图片。它不支持透明通道，反复编辑和重新保存也会积累有损压缩痕迹。

如果现有图片已经是经过合理压缩的JPEG，不必为了“格式统一”强行放大、重新编码多次。先看最终字节数和视觉效果。

PNG：适合透明或需要无损的内容，但容易过大

PNG适合透明图、界面截图和需要无损保真的内容。对于摄影照片，大尺寸PNG通常非常重。

一个常见问题是设计软件导出了一张带透明背景的超大PNG，但页面实际背景固定且不需要透明。这类图片改用JPEG、WebP或AVIF，往往比调CDN参数更能减少下载量。

WebP：兼顾照片、透明和广泛兼容性

WebP支持有损、无损和透明通道。Google的WebP官方说明介绍了它的压缩能力和相关工具。对多数面向现代浏览器的网站，WebP通常是容易落地的一档格式。

但不要根据宣传比例直接估算自己的节省量。商品图、插画、文字截图和已经高度压缩的JPEG，转换后的收益可能完全不同。

AVIF：体积可能更有优势，但必须用真实图片试

AVIF在一些照片和复杂图像上能得到更小文件，但编码时间、解码表现、画质参数以及你的图片处理服务能力都需要评估。对于后台即时生成大量衍生图的网站，还要看转码CPU成本和首次生成延迟。

实用的选择方法不是争论“WebP和AVIF谁更先进”，而是从真实业务图片中抽样：人像、商品、深色图、细节丰富的照片、文字截图各选一些，在相近视觉质量下比较文件大小和生成时间。

SVG：适合Logo和图标，不适合所有图片

SVG在矢量Logo、图标和简单插画上很有优势，可以在不同分辨率下保持清晰。用户上传的SVG可能包含脚本或外部引用，必须进行安全清洗，不能把它当作普通图片无条件开放上传和展示。

只转换格式还不够，图片尺寸往往更重要

如果页面中的图片只显示为360×240像素，却下载了一张4000×2667像素的原图，即使换成WebP，仍然可能浪费大量流量。

浏览器提供了srcset和sizes，可以根据屏幕与布局选择更合适的候选图片。一个同时提供AVIF、WebP和JPEG后备格式的示例是：

<picture>
  <source
    type="image/avif"
    srcset="/images/product-640.avif 640w,
            /images/product-1280.avif 1280w">
  <source
    type="image/webp"
    srcset="/images/product-640.webp 640w,
            /images/product-1280.webp 1280w">
  <img
    src="/images/product-1280.jpg"
    srcset="/images/product-640.jpg 640w,
            /images/product-1280.jpg 1280w"
    sizes="(max-width: 768px) 100vw, 50vw"
    width="1280"
    height="853"
    loading="lazy"
    decoding="async"
    alt="黑色双肩包正面和侧面细节">
</picture>

这段代码里有几个容易被忽略的点：

• srcset告诉浏览器有哪些图片尺寸可选；

• sizes描述图片在不同布局下大约占多宽，而不是图片文件本身多宽；

• width和height帮助浏览器提前预留比例，减少图片出现时页面跳动；

• alt应该描述图片内容和用途，不能为了SEO堆砌“图片CDN加速”等无关关键词；

• JPEG的src和srcset为不支持新格式的环境提供后备。

MDN的响应式图片说明详细介绍了srcset、sizes和picture的工作方式。上线前最好在手机、平板和桌面不同视口下检查浏览器实际选择的文件，而不是只确认页面“能显示”。

懒加载不是越多越好，首屏主图尤其不能乱用

对于屏幕下方的图片，原生懒加载可以减少首屏阶段的请求：

<img
  src="/images/gallery-960.webp"
  width="960"
  height="640"
  loading="lazy"
  decoding="async"
  alt="产品内部结构展示">

但首屏横幅、商品主图或文章封面如果是页面的最大内容元素，很可能参与LCP。给它加上loading="lazy"，可能让浏览器更晚才开始下载，反而拖慢用户看到主要内容的时间。

首屏关键图片可以正常加载，并在确有必要时谨慎使用：

<img
  src="/images/hero-1280.webp"
  width="1280"
  height="720"
  fetchpriority="high"
  alt="秋季新品系列展示">

fetchpriority="high"不是给所有首屏图片统一加的“加速开关”。优先级过多就等于没有优先级，还可能挤占CSS、字体或其他关键资源的带宽。web.dev在浏览器原生图片懒加载说明中明确建议，不要对首屏可见图片使用懒加载；其LCP优化指南也强调，LCP资源需要尽早被发现并开始加载。

如果主图藏在CSS背景中或等JavaScript运行后才插入，浏览器发现它的时间也会变晚。这时即使CDN节点响应很快，LCP仍可能不好看。

图片CDN测速，至少要测四类对象

只测一张几十KB的Logo，不能代表图片网站的真实体验。建议从线上业务中选择：

• 一张10KB至50KB的小图标或小缩略图；

• 一张常见列表图；

• 一张首屏主图；

• 一张详情页大图或高清预览图。

这些文件不需要刻意凑到某个大小，应该代表真实用户最常下载的内容。测试时记录URL、文件类型、像素尺寸和文件字节数，避免过几天图片被替换后还拿新旧结果直接对比。

第一次和第二次请求要分开看

第一次请求可能是冷缓存，需要CDN回源；第二次请求可能已经命中节点。两者都重要，但回答的问题不同：

• 冷缓存反映回源链路、源站处理和缓存填充速度；

• 热缓存反映边缘节点向用户交付图片的能力。

连续请求同一个公开图片URL，可以快速查看响应头与耗时：

curl -sS -D /tmp/image-headers.txt -o /dev/null \
  -w 'remote_ip=%{remote_ip}\ncontent_type=%{content_type}\nsize=%{size_download}\ndns=%{time_namelookup}\nconnect=%{time_connect}\ntls=%{time_appconnect}\nttfb=%{time_starttransfer}\ntotal=%{time_total}\n' \
  'https://img.example.com/products/sku-1280.webp'

sed -n '1,30p' /tmp/image-headers.txt

重点查看：

• Content-Type是否与实际格式一致；

• Content-Length或实际下载字节是否符合预期；

• Cache-Control是否允许需要的缓存；

• Age是否增长；

• 服务商的缓存头是否从MISS变为HIT；

• Vary是否与格式协商方式匹配；

• ETag或Last-Modified是否合理；

• TTFB和总耗时在多次请求中是否稳定。

不要为了避免缓存而每次给URL加随机参数，再据此判断CDN速度。随机参数可能创建新缓存对象，测到的始终是回源表现。

不要只在办公室测一次

北京联通访问快，不代表广州移动、成都电信或海外用户也快。图片CDN测试至少应该覆盖真实用户集中的地区、运营商和访问高峰。

可以把代表性图片URL放入CDNChart网站测速，观察不同地区和网络下的连接、TTFB、下载耗时与成功情况。测试时建议保留：

• 测试时间与时区；

• 测试地区和运营商；

• 解析或连接到的IP；

• HTTP状态码；

• 缓存状态；

• TTFB、总耗时和下载字节；

• P50、P95以及失败请求。

一次最快结果只能说明“某次请求很快”。要判断图片交付是否稳定，应连续采样，并把缓存HIT与MISS分组。具体方法可参考《网站有时快有时慢，CDN测速应该怎么测》。

CDN图片很快，为什么页面看起来还是慢

单张图片测速关注的是一个URL，页面加载却是几十甚至几百个资源共同竞争的过程。二者不能互相代替。

在浏览器开发者工具中打开Network面板，建议检查：

页面一共下载了多少图片

分别查看请求数量、传输字节和资源原始大小。压缩率不错但页面一次请求200张图，首屏仍然可能被挤占带宽。

首屏主图什么时候开始请求

如果HTML解析很久以后才发现主图，或要等待一段JavaScript执行后才插入，CDN无法补回前面失去的时间。瀑布图中，主图请求开始时间往往比单看下载时长更有价值。

手机上是否下载了桌面大图

切换不同视口后检查图片的实际URL和Content-Length。页面CSS把4000像素图片缩成300像素显示，不等于浏览器只下载了300像素版本。

LCP元素是不是一张图片

如果LCP元素是首屏大图，就应继续分解：服务器响应是否慢、图片是否很晚才被发现、下载是否过大、下载后是否还因脚本或动画延迟显示。

图片出现时页面有没有跳动

图片缺少明确尺寸时，浏览器开始布局时不知道要预留多少空间。图片加载后，文字和按钮被挤走，就会造成布局偏移。给图片提供正确的宽高或aspect-ratio，通常比单纯提高CDN速度更直接。

CDN测速与整页测速解决的问题不同，二者的边界可以参考《CDN测速和网站测速有什么区别？分别能测出什么》。

一张排查表：从现象找到真正的问题

一套可以落地的改造顺序

如果网站已经在线，不建议第一天就把全站图片格式、域名和URL规则全部改掉。变化太多时，一旦图片无法显示，很难快速确定是哪一层出了问题。

可以先选访问量较高、结构比较稳定的一类页面做小范围改造：

1. 统计该页面当前的图片请求数、总字节、LCP和主要图片耗时；

2. 选出Logo、缩略图、首屏主图和详情图四类资源；

3. 让图片URL真正经过CDN，并验证证书、状态码和缓存头；

4. 为高频展示位置生成固定尺寸，先避免明显的超规格下载；

5. 对真实样本比较JPEG、WebP和AVIF的画质、字节与转码成本；

6. 给不会原地修改的文件使用版本化URL和长缓存；

7. 首屏关键图取消懒加载，非首屏图片再分批延后；

8. 重复进行单图、多地区和完整页面测试；

9. 确认搜索抓取、社交分享、防盗链和图片更新流程没有被破坏；

10. 指标稳定后再逐步覆盖其他页面。

前后对比时，除了平均加载时间，还应记录图片总字节、缓存命中、不同地区P95、LCP和失败率。否则，很容易因为测试当天网络较好，把一次偶然波动当成改造收益。

常见问题

图片放到对象存储后，还需要CDN吗？

对象存储解决的是文件保存和源站访问，CDN负责将可缓存内容分发到更靠近用户的位置。用户分布广、图片访问量大或源站距离较远时，CDN通常仍有价值。是否值得接入，要用真实用户地区、缓存命中、回源流量和费用共同判断。

图片缓存时间设置多久合适？

没有适用于所有网站的固定答案。文件名带内容哈希或版本、同一URL内容永不变化时，可以设置很长的缓存时间；同名图片经常覆盖，则应使用版本化URL，或采用更短TTL并建立可靠的刷新流程。不要只给出“缓存30天”却不考虑更新机制。

WebP和AVIF一定比JPEG小吗？

不一定。结果与原图内容、编码器、质量参数和原JPEG压缩程度有关。正确做法是在相近视觉质量下对真实样本比较，不要只看文件扩展名。

图片已经HIT，为什么TTFB还是高？

可能连接到的节点较远、节点负载或网络路由不理想，也可能缓存状态头代表的是上层缓存而非最靠近用户的边缘层。记录响应IP、地区、运营商和多次P95，再判断是偶发波动还是持续问题。

所有图片都应该懒加载吗？

不应该。屏幕下方的图片适合懒加载，首屏主图或可能成为LCP的图片通常应该尽早请求。首屏图被懒加载，是“CDN很快但页面看起来慢”的常见原因之一。

图片CDN应该测Ping还是HTTP下载？

Ping只能提供基础网络往返时间线索，不能代表HTTPS握手、缓存、TTFB和文件下载。图片加速应以真实图片URL的HTTP请求为主，同时记录文件大小、缓存状态、TTFB、下载耗时和成功率。

图片用了CDN，会直接提升SEO排名吗？

CDN本身不是一个可以保证排名提升的开关。它可能改善图片交付速度、稳定性和用户体验，但页面是否获得搜索流量还取决于内容质量、抓取与索引、移动端体验、图片语义、内部链接等多种因素。图片alt应准确描述内容，不要为了关键词密度写成一串搜索词。

当图片网站出现加载慢时，可以先拿一张首屏主图做完整检查：它从哪个域名请求、解析到哪个节点、是HIT还是MISS、下载了多少字节、在瀑布图里何时开始、是不是LCP元素。把这一条链路看清楚，通常比一开始就批量调整所有CDN参数更容易找到真正的瓶颈。