用 performance.getEntriesByType('resource') 获取图片网络各阶段耗时，结合 elementtiming 的 renderTime 判断实际渲染时间，二者交叉分析可准确定位图片加载慢是网络还是渲染瓶颈。
直接用 performance.getEntriesByType('resource') 抓取图片加载全过程数据，再结合 elementtiming 看它实际渲染到屏幕的时间——这两类指标一“网络”一“视觉”，合起来才能真实反映用户看到图片的快慢。
抓全量图片资源耗时（网络层）
图片是否下载得慢，得看浏览器真实记录的各阶段时间，不能只看 duration。必须等页面完全加载（window.addEventListener('load', ...)）后再调用：
-
过滤图片资源：用
performance.getEntriesByType('resource').filter(e => e.initiatorType === 'img')，避开 JS、CSS 干扰 -
拆解关键阶段：对每张图计算：
• DNS 查询：e.domainLookupEnd - e.domainLookupStart
• TCP + TLS 连接：e.connectEnd - e.connectStart
• TTFB（首字节）：e.responseStart - e.requestStart
• 下载耗时：e.responseEnd - e.responseStart -
注意跨域限制：CDN 图片若没配
Timing-Allow-Origin: *响应头，DNS/TCP 等字段会是 0，不代表没耗时，只是被浏览器屏蔽了
测图片真正“出现”的时间（渲染层）
用户不关心“下载完没”，只关心“看见没”。elementtiming 就是为此设计的，但它不是 HTML 属性开关，而是需主动标记 + 主动读取：
-
标记目标图片：给关键图加
elementtiming="hero"或elementtiming="product-1"，仅支持<img>、<video>等替换元素 -
延迟采集数据：不能在
DOMContentLoaded就查，要等window.addEventListener('load', () => { ... })或用requestIdleCallback，否则performance.getEntriesByType('element')返回空 -
提取 renderTime：结果数组里每个 entry 都有
renderTime字段，单位毫秒，起点是navigationStart，直接对比就能知道这张图比 FCP 晚多少毫秒才画出来
交叉分析定位瓶颈类型
单看某一项容易误判。比如一张图 renderTime 很晚，但 responseEnd 早就完成了——说明卡在 CSS 渲染阻塞或 JS 主线程忙；反之若 responseEnd 晚，renderTime 紧跟其后，问题就在网络或服务端。
立即学习“前端免费学习笔记（深入）”；
-
网络慢 → 渲染也慢：TTFB > 800ms 或 download 耗时 > 2s，优先查 CDN 缓存、图片格式（是否用了 .webp/.avif）、是否漏了
<link rel="preconnect"> -
网络快 → 渲染慢：responseEnd 很早，但 renderTime 滞后 > 300ms，检查是否因未设
width/height导致布局抖动（CLS），或被高权重 CSS/JS 阻塞绘制 -
首屏图异常：对 banner、logo 等 LCP 候选元素，同时比对它的
renderTime和 LCP 时间戳，差值超过 100ms 就说明优化空间很大
日常监控建议
别等上线后才发现问题。把核心图片的 renderTime 和关键资源的 TTFB / download 耗时打点上报，和 LCP、FCP 放在一起看趋势：
- 建立基线：统计近 7 天首页 Banner 图平均
renderTime，设为阈值（如 1200ms） - 自动告警：某次发布后该值上升 20% 且持续 3 分钟，触发 Slack 提醒
- 关联排查：同一张图若 TTFB 正常但
renderTime突增，基本可锁定前端渲染逻辑问题，不用翻后端日志
