根本原因是未正确设置sizes属性以匹配实际布局宽度，导致浏览器按视口全宽而非容器真实宽度选择图片；webp/avif需置于jpeg/png前以兼容旧版safari；必须预生成多尺寸图片并配置cdn识别accept头。

为什么里写了多张图，浏览器还是加载了最大尺寸？

根本原因不是浏览器“选错了”，而是你没告诉它图片在页面上实际占多宽。浏览器拿到 sizes 后，先算出渲染宽度，再从 srcset 里挑最接近且不小于该宽度的图——如果 sizes 写成 "100vw"，桌面端就真按视口全宽算，哪怕容器只有 720px 宽，它也会拉下 2400w 的图。

• 必须和真实 CSS 布局对齐：先写好 @media (min-width: 768px) { .hero-img { width: 720px; } }，再转成 sizes="(max-width: 767px) 100vw, 720px"
• 注意单位统一：不能混用 vw 和 px，更不能塞 rem
• 有 padding 就要减：父容器 padding: 0 20px，视口宽 390px，有效宽度 ≈ 350px，sizes 得写成 "(max-width: 767px) 350px, 720px"

中顺序错位会导致旧版 Safari 加不到 WebP

浏览器从上到下解析 <source></source>，遇到第一个 media 匹配且 type 受支持的就停。Safari 14+ 支持 WebP，但 Safari 13 及更早版本不支持——如果你把 <source type="image/jpeg"></source> 放前面，它永远卡在这条，根本不会往下看 WebP。

html-ppt-to-pdf

将使用 `

` 约定的 HTML 幻灯片转换为高保真、矢量文本 PDF（使用 Playwright + Chromium 原生 PDF 功能）。

下载

• WebP/AVIF 必须排在 JPEG/PNG 前面：<source type="image/webp"></source> → <source type="image/jpeg"></source>
• 同一 <source></source> 内不能混用 w 和 x 描述符，部分 Android 浏览器会直接忽略整条 srcset
• 只保留真实触发的断点：<source media="(min-width: 1440px)"></source> 如果你的 CSS 根本没定义这个断点，就是冗余项，徒增 HTML 体积

没设 width 和 height 的 <img> 会让 LCP 指标恶化

没设内联 width/height 的 <img> 在加载前不占空间，内容会突然下移——这不是视觉小问题，它直接拉长 LCP（最大内容绘制），导致浏览器误判“首屏关键内容还没出来”，进而提前加载更大图来抢时间，反而推高带宽消耗。

• 必须填原始图比例：1200×800 的图，就写 width="1200" height="800"
• object-fit: cover 不解决占位问题，它只控制裁剪，容器尺寸仍由 width/height 或 aspect-ratio 决定
• 推荐双保险：<img style="max-width:90%" style="max-width:90%"> + CSS aspect-ratio: 1200 / 800，Safari 旧版可用 padding-top 技巧降级

超大图不能靠前端缩放，必须预生成多档位

直接 <img src="banner-10MB.jpg"> 即使加了 sizes，浏览器也只会下载这张图再缩放——它没能力在客户端实时降质或裁剪，10MB 还是得全量拉下来。营销页高峰期 CDN 带宽账单飙升，八成来自这种“假响应式”。

• 必须按断点预生成：400w、800w、1200w、1600w、2400w、3200w……每档都输出 WebP + JPEG 备份
• 构建流程里加自动化工具：sharp、ImageMagick 或 Cloudinary API，别靠人工切
• CDN 配置要识别 Accept: image/webp 请求头，自动回源取对应格式，否则 fallback 逻辑就失效

真正难的不是写对标签，是让设计、开发、运维三方对齐：设计师给的图稿尺寸要能映射到 CSS 断点，开发写的 sizes 要和布局代码同步更新，运维得确保 CDN 正确识别格式请求头——漏掉任何一环，响应式图片就退化成带宽黑洞。

前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！