WebP虽快但页面仍卡，根本原因是仅换格式未配<picture>回退、缺失width/height导致回流、缺sizes引发超大图下载、服务端未返回Content-Type: image/webp致fallback失效。
WebP 是当前最值得默认启用的格式，但必须配 <picture> + <source> 回退，且不能跳过 sizes 和宽高约束——否则加载快不起来，反而更卡。
为什么 WebP 用着快却页面还是卡
不是 WebP 不行，是只换格式不改 HTML 结构，等于白干。浏览器拿到 <img src="hero.webp">，看似用了新格式，但若没设 width/height，图片加载完成前无法预留空间，触发回流；若没配 sizes，它仍可能按 100vw 下载一张 2MB 的 4K WebP；若服务器没返回正确的 Content-Type: image/webp，旧版 Safari 直接忽略该文件， fallback 失败后空白几秒。
常见错误现象：
– 页面首屏图片加载时“闪一下”或向下跳动
– Lighthouse 报告中 “Avoid large layout shifts” 红标
– Network 面板里明明有 WebP，但实际加载的是 fallback 的 JPEG（查看 Initiator 列）
- 确保 WebP 文件由支持 AVIF/WebP 的服务端提供，Nginx 示例配置：
add_type image/webp .webp; -
<img>必须带width和height（内联属性），值取原始图真实尺寸，比如width="1200" height="630" - 不用
aspect-ratio的项目，至少补上style="aspect-ratio: 1200/630;"（兼容性比纯 CSS 更稳）
<picture> 的 srcset 和 sizes 怎么配才不浪费流量
只写 srcset 不写 sizes，等于告诉浏览器“你自己猜这张图要多宽”，结果大概率猜错、下错图。尤其在侧边栏、卡片缩略图等窄容器里，sizes 写成 "100vw" 就是灾难——手机上拉一张 1920w 的图，只为显示 200px 宽。
立即学习“前端免费学习笔记（深入）”；
实操建议：
– 先看 CSS 中该图片容器在各断点下的实际宽度（DevTools → Computed → width）
– 按真实布局逻辑写 sizes，例如：sizes="(max-width: 768px) 100vw, (max-width: 1200px) 50vw, 33vw"
– srcset 中的 w 描述符必须与原图真实宽度一致，如 hero-400w.webp 就得是 400 像素宽的图，否则切换失效
- 避免堆砌冗余尺寸：不需要从 320w 到 3840w 每 100px 一个，只保留你 CSS 媒体查询真正生效的几个断点（如 480w / 768w / 1200w）
- 同一
<source>里别混用w和x单位，Safari 会直接跳过整条<source> - 用
curl -I https://yoursite.com/image.webp检查响应头是否含Content-Type: image/webp
loading="lazy" 加在哪张图上才算真优化
加在首屏 banner、logo、产品主图上，就是在自毁体验。原生 loading="lazy" 对离视口近的图几乎无延迟控制能力，而 Safari 旧版和部分安卓 WebView 根本不支持，一加就白屏。
典型误用：
– 所有 <img> 统一加 loading="lazy"，结果首页轮播图延迟 1.8s 才出现
– 用 background-image 替代 <img> 来“绕过懒加载”，结果 SEO 和无障碍全崩
- 首屏关键图必须移除
loading="lazy"，并加fetchpriority="high"（Chrome 109+） - 非首屏图才加
loading="lazy"，且确保已设width/height，避免占位塌陷 - 需要兼容老浏览器或精细控制加载时机（如提前 300px 开始加载），用
IntersectionObserver+data-src更可靠
AVIF 能不能现在就上
可以试，但不能当主力。AVIF 压缩率确实比 WebP 高 10–20%，但截至 2026 年 5 月，iOS Safari 16.6+ 才开始稳定支持 AVIF，macOS Safari 16.4+ 也仅限部分机型解码；Android WebView 仍有不少版本报 DOMException: The requested URL is invalid。
实操底线：
– <picture> 中 AVIF 必须放在 WebP 上方（优先尝试）
– 底层 <img src="fallback.jpg"> 必须存在，且路径可访问
– 服务端必须同时支持 image/avif MIME 类型，否则整条 <source> 被跳过
- 用
caniuse.com/avif查目标用户覆盖比例，低于 85% 就暂缓主推 - 生成 AVIF 时别盲目调最高压缩，部分解码器对高压缩 AVIF 渲染异常（尤其含半透明区域）
- CI 流程中加入检查：所有 AVIF 文件需通过
file image.avif | grep "AV1"验证编码正确性
真正难的不是选哪个格式或加哪行属性，而是让每个 <img> 都知道自己“在哪、多大、何时加载、加载失败怎么办”。这些细节一旦漏掉一个，高清和快就变成互斥选项。
