这篇文章进入了性能调整的另一个大头—— “图片性能调整”。按理说，

图片通常是网页上体积最大、最占带宽的资源。按理说，文章的主要思想是： “在不牺牲肉眼可见画质的前提下通过各种手段让浏览器下载最少的图片字节数”。

响应式图片与尺寸调整

使用者痛点：不同设备拥有不同的屏幕宽度和设备像素比。如果统一使用高清大图会浪费流量，使用小图又会在高分屏上出现模糊。

• 方法 1 – srcset & sizes：利用 srcset 提供多种分辨率/宽度的候选图。配合 sizes 声明在各视口下实际展示宽度，让浏览器自行挑选最合适的一张下载。
• 方法 2 – 元素：通过在 中使用多个 可以针对特定屏幕尺寸、DPR 或方向切换不同尺寸甚至不同裁剪方式的图片，实现更精细的适配。

现代文件格式与压缩

使用者痛点：传统 JPEG/PNG 在同等画质积偏大，导致页面加载慢、流量消耗高。

• 下一代格式推荐： 与 提供更高压缩率；在相同视觉质量下可节省 30%~70% 的字节。
• 格式降级策略： 可先尝试加载 IF。不支持时回退到 WebP，再不支持时降级为 JPEG/PNG，兼容所有浏览器。
• 有损 vs 无损：
  • 有损压缩：适用于色彩丰富的照片，通过舍弃肉眼难以察觉的细节实现体积大幅下降。
  • 无损压缩：适用于线条图、带文字的图标，需要保持像素完整性。

服务端动态投喂

使用者痛点：前端代码往往需要写大量条件判断才能兼容不同图片格式，维护成本高且易出错。

• Accept 请求头检测：浏览器会在请求中携带A​ccept: image/avif,image/webp,…
• SaaS / CDN 自动转换：在后端或图片 CDN 层拦截请求。根据A​ccept返回最佳格式（如原始)，无需改动前端 HTML，实现“写一次代码，服务所有格式”。

浏览器渲染与加载控制

使用者痛点：LCP受大图阻塞影响显著，页面首屏渲染慢导致跳出率升高。

• Lazily Load – loading="lazy": 对非首屏图片启用延迟加载。仅在滚动到视口附近时才开始下载，大幅降低首屏带宽消耗。
• Aysnc Decode – decoding="async": 告诉浏览器异步解码图片数据。防止阻塞主线程，提高交互流畅度，特别适用于高分辨率的大图。
• Eager vs Lazy 决策教程：
• Eager适用于 LCP 所占比重大的关键视觉元素，如 Hero Banner、产品主图。
• Lazily 加载适用于列表页、文章正文中的次要插图或底部装饰图。

Total Takeaway:

• Simplify front‑end markup：采用  Shrink bytes dramatically：使用 WebP/IF 并结合有损/无损策略，把同等画质下的体积砍至原来的三分之一甚至更低；怎么说呢，
• Leverage server‑side negotiation：让 CDN 根据 Accept 头自动返回最佳格式。无需维护冗余 HTML，
• Control when and how images load：通过 lazy‑load 与 async‑decode 把首屏渲染时间压到最低，让使用者感受到“瞬间打开”。
• Monitor real‑world impact：部署后用 Lighthouse、Web Vitals 或自建 RUM 检查 LCP、CLS 与网络传输量变化，以验证调整效果。