渐进式 JPEG 详解 - 理解图像逐步显示技术
渐进式 vs 基线 JPEG - 两种编码方式
JPEG 有两种编码模式。基线 (Baseline) JPEG 从上到下逐行编码图像，解码时也从上到下逐行显示。渐进式 (Progressive) JPEG 将图像分为多次扫描 (pass)，首先显示整幅图像的模糊预览，然后随着后续扫描逐步提升质量。
基线 JPEG 的显示行为: 随着数据到达从上到下绘制，因此在慢速连接下，只有图像上半部分显示，下半部分保持灰色。用户必须等待所有数据到达才能看到完整图像。
渐进式 JPEG 的显示行为: 第一次扫描 (约占总数据的 10-15%) 显示整幅图像的模糊版本。每次额外扫描到达后图像逐渐变清晰，直到达到完整质量。用户可以在早期阶段把握图像内容，减少感知等待时间。
文件大小差异: 在相同质量设置下，渐进式 JPEG 通常比基线小 2-10%。这是因为扫描之间对 DCT 系数进行了差分编码。但对于 10KB 以下的小图像，渐进式的开销 (扫描头) 可能反而增加文件大小。
渐进式 JPEG 编码原理 - 扫描层与 DCT 系数分割
渐进式 JPEG 的技术核心是将 DCT (离散余弦变换) 系数分割到多次扫描中的机制。每个 8x8 块的 64 个 DCT 系数按重要性逐步传输。
频谱选择 (Spectral Selection): 按锯齿形顺序分割 DCT 系数，将低频分量 (DC 分量和低阶 AC 分量) 放在第一次扫描中，高频分量放在后续扫描中。低频分量表示图像的大致形状和颜色，高频分量表示精细细节。
典型的扫描配置:
- 扫描 1: 仅 DC 系数 (整幅图像的平均亮度图)
- 扫描 2: AC 系数 1-5 (大致形状)
- 扫描 3: AC 系数 6-63 (精细细节)
逐次逼近 (Successive Approximation): 逐步提高每个 DCT 系数的精度。第一次扫描仅传输系数的高位比特，后续扫描添加低位比特。例如，先传输高 4 位，然后是第 5 位、第 6 位，依此类推。
实际的编码器 (libjpeg、MozJPEG) 会生成约 10 次扫描，结合频谱选择和逐次逼近。MozJPEG 具有优化扫描配置的算法，与基线相比可实现 5-10% 的文件大小缩减。
Web 性能影响 - 感知速度与实测速度的关系
渐进式 JPEG 对 Web 性能的影响不能仅通过简单的文件大小比较来衡量。需要从感知性能和实际加载时间两个方面进行评估。
感知速度改善: 由于渐进式 JPEG 在第一次扫描 (10-15% 的数据) 就显示整幅图像的预览，用户感觉"图像已出现"的时间缩短了。Akamai 的研究报告指出，使用渐进式 JPEG 的页面中，用户感知的加载完成时间平均改善了 15-25%。
LCP (Largest Contentful Paint) 影响: Core Web Vitals 的 LCP 测量"最大内容绘制完成时间"。对于渐进式 JPEG，某些浏览器实现在第一次扫描渲染时记录 LCP，而其他实现则等待最终扫描。Chrome 在第一次有意义的绘制 (第一次扫描) 时记录 LCP，因此渐进式 JPEG 可能有助于改善 LCP 分数。
解码开销: 渐进式 JPEG 的解码比基线有更高的 CPU 负载。整合多次扫描的处理使解码时间增加约 1.5-3 倍。但在现代设备上，这一差异仅为几毫秒，不构成实际问题。仅在低配置移动设备上同时解码大量图像时需要注意。
HTTP/2 环境下的效果: HTTP/2 的多路复用使多张图像并行下载，渐进式 JPEG 的逐步显示优势可能减弱。由于所有图像同时以小块到达，基线模式也能相对较快地显示所有图像的顶部。
生成渐进式 JPEG - 工具与库的使用
以下介绍如何使用主要的图像处理工具和库生成渐进式 JPEG。
ImageMagick:
convert input.jpg -interlace Plane output.jpg
-interlace Plane 选项生成渐进式 JPEG。-interlace Line 是基线交错 (不推荐)，-interlace None 是基线模式。
Sharp (Node.js):
const sharp = require('sharp');await sharp('input.jpg') .jpeg({ quality: 80, progressive: true }) .toFile('output.jpg');
MozJPEG (cjpeg):
cjpeg -quality 80 -progressive input.ppm > output.jpg
MozJPEG 是 Mozilla 开发的 JPEG 编码器，与标准 libjpeg 相比可实现 5-10% 的文件大小缩减。其渐进模式的扫描配置经过优化，非常适合 Web 用途。
Python (Pillow):
from PIL import Imageimg = Image.open('input.jpg')img.save('output.jpg', 'JPEG', quality=80, progressive=True)
检测方法: 要判断现有 JPEG 是渐进式还是基线，可使用 identify -verbose image.jpg | grep Interlace (ImageMagick)。JPEG 表示渐进式，None 表示基线。在 Python 中可通过 img.info.get('progressive') 判断。
何时使用、何时避免渐进式 JPEG
渐进式 JPEG 并非万能 - 有适合使用和应避免使用的场景。以下是判断标准。
适合使用的场景:
- 10KB 以上的图像: 渐进式开销相对较小，可获得文件大小缩减的收益
- 首屏大图和主视觉: 作为页面主要内容的大图像，通过逐步显示带来的感知速度改善效果显著
- 慢速连接用户较多的服务: 面向 3G 连接或发展中地区移动用户的服务，逐步显示的优势明显
- 图片画廊和作品集: 显示大量图像的页面，所有图像的预览早期显示效果显著
应避免的场景:
- 10KB 以下的小图像: 扫描头开销可能增加文件大小
- 缩略图: 小图像瞬间加载完成，逐步显示没有意义
- 图标和 Logo: 应使用 SVG 或 PNG 而非 JPEG
- 解码性能重要的场景: 同时解码大量图像时，渐进式的解码开销会累积
实用建议: 最实用的方法是在构建流水线中统一生成渐进式 JPEG，仅对 10KB 以下的图像回退到基线模式。将 Sharp 或 MozJPEG 的默认设置为渐进式，无需逐个判断即可应用优化。
渐进式 JPEG 的未来 - 与 JPEG XL 的对比及迁移展望
渐进式显示不仅在 JPEG 中，在下一代格式中也被定位为重要功能。通过与 JPEG XL 的渐进式解码对比，展望这项技术的未来。
JPEG XL 的渐进式解码: JPEG XL 大幅进化了 JPEG 的渐进模式。JPEG 只能有固定的扫描配置，而 JPEG XL 可以在任意分辨率和质量级别进行中间显示。例如，可以先显示 1/8 分辨率的预览，然后逐步提升到 1/4、1/2 分辨率。
JPEG XL 的优势:
- 更细粒度的渐进显示，可根据网络状况自适应显示
- 可在任意字节位置截断并仍然显示为有效图像 (截断友好)
- 易于与响应式图像集成 (可从单个文件提取多种分辨率)
当前的实用判断: 鉴于 JPEG XL 的浏览器支持有限，渐进式 JPEG 仍然是最广泛支持的逐步显示方法。作为迁移策略，推荐使用 AVIF/WebP 作为主要格式，同时使用渐进式 JPEG 作为回退方案。
AVIF 和 WebP 的渐进式支持: AVIF 默认不支持渐进式解码。WebP 同样如此。因此，当逐步显示很重要时，需要结合 LQIP 或 BlurHash 等占位符技术使用。渐进式 JPEG "格式本身包含逐步显示"的特性，目前是 JPEG 和 JPEG XL 独有的优势。
未来，结合 HTTP/3 优先级控制的自适应图像分发可能成为现实 - 服务器检测客户端带宽并优先传输渐进式 JPEG 的初始扫描。