图片压缩需兼顾格式选择、参数设置与加载策略：PNG图标用无损压缩防边缘模糊，JPEG照片质量设75–85，WebP须配picture标签及MIME头，srcset需匹配实际容器尺寸，lazy加载须作用于img标签并注意兼容性。
图片压缩能直接减小文件体积，是降低 HTML 页面加载时间最见效的手段之一。但光“压”不行，压错格式、压完不改用法、压了还塞一张 4000×3000 的图进移动端页面，照样拖慢加载。
用 TinyPNG 或 Squoosh 做有损压缩时要注意什么
这类工具默认启用“智能压缩”，对 PNG 和 JPEG 都有效，但实际效果差异很大：
- PNG 图标类资源：优先选“无损压缩”模式，
TinyPNG的有损压缩有时会模糊边缘或吃掉半透明像素，导致图标发虚 - JPEG 照片类资源：把质量滑块拉到 75–85 区间通常够用，再低肉眼可见色块；别盲目追求“最小体积”，
quality=60在 Retina 屏上容易显脏 - 上传前先裁掉画布外空白、删掉 EXIF（尤其是手机直出图带 GPS 信息），
Squoosh.app右侧的 “Remove metadata” 要勾上 - 压完务必检查导出尺寸——有些工具会自动缩放，但没改
width/height属性，浏览器仍按原尺寸预留布局空间，引发 CLS（累积布局偏移）
WebP 格式转换后为什么图片不显示
不是所有 WebP 图片都能直接替换 JPEG/PNG，常见断点在 MIME 类型和浏览器兼容性：
- 服务器必须返回正确的响应头：
image/webp，Nginx 需加配置：types { image/webp webp; }，Apache 要确保.webp关联了image/webp - 不能直接把
-
- 注意 WebP 不支持动画（APNG/GIF 动画需保留原格式或转为 MP4）
srcset + sizes 配置不当反而增大流量
很多人以为加了 srcset 就万事大吉，结果发现 3G 网络下加载了 1200w 的图——问题出在 sizes 写得太宽泛：
-
sizes="(max-width: 768px) 100vw, 50vw"是常见写法，但如果容器实际只占视口 30vw，浏览器仍可能选 800w 版本；更准的是用 CSS 容器查询后填具体值，比如sizes="30vw" - 准备的源图尺寸别跨度太大：比如只提供
400w和1600w，中间缺档，浏览器在 900px 视口可能硬选 1600w，浪费带宽 -
srcset中的宽度描述符（如400w）指的是图片文件本身的自然宽度，不是 CSS 渲染宽度；别把缩放后的尺寸当w值填 - Chrome DevTools → Network → 切换设备模拟器后刷新，看实际加载的是哪个 URL，验证是否真按预期选图
懒加载 loading="lazy" 为什么没生效
loading="lazy" 是最简懒加载方案，但有几个隐藏前提：
- 只对非首屏图片起作用，且仅当图片进入“即将可视区域”（约 1250px 外）才触发加载；如果页面很短或图片离顶部太近，它会立刻加载，和不写一样
- 不支持
loading属性，必须写在内部的
- 部分老安卓 WebView 或 iOS 12.2 以下不支持，可降级用
IntersectionObserver，但别为了兼容性放弃原生 lazy——95%+ 流量已覆盖 - 和服务端渲染（SSR）配合时注意：服务端不会执行 JS，所以初始 HTML 里
loading="lazy"是安全的，但别依赖 JS 动态插入后补这个属性，那等于没懒
真正卡住加载速度的，往往不是“没压缩”，而是“压了但没管尺寸、没配格式、没控加载时机”。每张图都要回答三个问题：它最终在页面上占多大？用户用什么设备看？这张图到底要不要第一时间出现？漏掉任何一个，压缩就白做了。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
