大型网站HTML媒体元素及加载结构优化实战

loading="lazy"在首页轮播图上失效，是因为浏览器对<img>懒加载有明确限制：首屏内、缺失width/height、或被CSS强制拉伸的元素会被自动降级为eager；轮播图常因JS动态插入、无固有尺寸、父容器overflow hidden或transform移动导致检测失败。

为什么 loading="lazy" 在首页轮播图上失效了

因为浏览器对 <img> 和 <iframe> 的懒加载支持有明确限制：首屏内、width/height 缺失、或被 CSS 强制拉伸的元素，loading="lazy" 会被自动忽略并降级为 eager。轮播图常因 JS 动态插入、无固有尺寸、或父容器 overflow hidden 导致检测失败。

• 确保每个 <img> 都声明 width 和 height（哪怕只是占位值，如 width="800" height="450"）
• 避免用 max-width: 100% + height: auto 替代固有尺寸——这会让浏览器无法计算布局占位
• 轮播容器若使用 transform 或 position: absolute 移动子图，需在初始 DOM 中就包含所有 <img>，而非 JS 动态 append
• Chrome 120+ 支持 fetchpriority="high"，对首屏关键图可叠加使用：<img loading="lazy" fetchpriority="high" ...>

如何让 <video> 不阻塞页面解析又保持首帧可见

直接写 <video preload="metadata" poster="..."> 是常见误区：虽然 preload="metadata" 能减少体积，但若 poster 图未内联或未设尺寸，仍会触发 FOUC 且影响 LCP。更稳妥的做法是分离加载逻辑与渲染控制。

• 始终提供 poster 属性，且该图片建议转为 WebP + 小于 10KB；否则浏览器会等待视频元数据返回才渲染占位，拖慢 LCP
• 移除 autoplay 和 controls 属性，改用 JS 在 DOMContentLoaded 后动态添加（避免预加载干扰主线程）
• 对非首屏视频，用 IntersectionObserver 触发 load() 而非依赖 preload —— 更精准控制资源时机
• 若需静音自动播放（如背景视频），必须加 muted，否则 Chrome 会拒绝 autoplay 并抛出 NotAllowedError

decoding="async" 对 JPEG/PNG 实际有用吗

有用，但仅限解码阶段，且效果高度依赖图像尺寸和设备内存。它不会减少下载时间，也不会改变渲染顺序，只把图像像素解压从主线程移到后台线程，防止大图解码卡住 UI。

• 对 >2000×1500 的 JPEG/PNG 建议强制启用：<img decoding="async" ...>
• WebP/AVIF 格式原生支持异步解码，无需显式设置 decoding
• 注意 Safari 直到 iOS 17.4 才完全支持 decoding="async"，旧版本会忽略该属性，不报错也不生效
• 不要和 loading="lazy" 混用优化预期——两者解决不同问题：一个是加载时机，一个是解码线程

CDN 返回的 Content-Length 为 0，但图片能正常显示？

这是典型分块传输（chunked encoding）行为，不是错误。当 CDN 开启 Brotli 压缩、或启用边缘重写规则（如图片格式自动转换、水印注入）时，响应头往往不带 Content-Length，改用 Transfer-Encoding: chunked 流式下发。

立即学习“前端免费学习笔记（深入）”；

• 只要浏览器收到 200 OK 和正确 Content-Type（如 image/webp），即使 Content-Length 缺失，也能正常解码渲染
• 真正要警惕的是 Content-Length 存在但与实际 body 长度不符——这会导致截断、白图或 CORB 错误
• 若用 fetch() 加载图片并手动读取 blob，需检查 response.bodyUsed 状态，chunked 响应下多次读取会报 TypeError: Failed to execute 'blob' on 'Response': body stream is disturbed

关键点在于：媒体优化不是堆参数，而是理解每个属性在渲染流水线中的作用位置——loading 影响请求发起时机，decoding 影响 CPU 解码调度，fetchpriority 影响网络调度队列，三者不在同一层，不能互相替代。