文章目录
-
- 每日一句正能量
- 前言
- [一、现代图片格式链路：AVIF → WebP → JPEG](#一、现代图片格式链路：AVIF → WebP → JPEG)
- [二、Next.js `<Image>` 组件的自动优化](#二、Next.js
<Image>组件的自动优化) - [三、懒加载策略：eager vs lazy 与解码调度](#三、懒加载策略：eager vs lazy 与解码调度)
- 四、模糊占位图：消除空白与布局跳动
- [五、图片 CDN 的实时格式转换与质量压缩](#五、图片 CDN 的实时格式转换与质量压缩)
- [六、完整配置示例：Next.js Image 组件实战](#六、完整配置示例：Next.js Image 组件实战)
- 结语
每日一句正能量
三餐四季，温暖有趣，便是人间好光景。
在重复与平凡中创造诗意、感知幸福的能力，是一种"此心安处是吾乡"的满足感。真正的奢华不在别处，在于你如何经营触手可及的日常。
前言
在现代 Web 应用中，图片通常占据页面传输体积的 50%--80%，是影响 Largest Contentful Paint（LCP）和整体用户体验的首要因素。Codex 官网在重构过程中建立了一套完整的图片优化链路：从格式选择、响应式适配、懒加载策略到边缘 CDN 的实时转换，实现了首屏图片加载时间从 2.1 秒降至 0.6 秒的跨越式提升。本文将系统拆解这套全链路方案的核心决策与落地细节。
一、现代图片格式链路：AVIF → WebP → JPEG
2026 年的浏览器生态已经成熟到可以大规模部署 AVIF。根据 Can I Use 最新数据，AVIF 的全球支持率达到 94.9% ，WebP 达到 96.4%，而 Safari 自 16.4 版本起已完整支持 AVIF 解码。这意味着我们可以放心地将 AVIF 作为首选格式，WebP 作为次级回退，JPEG 作为终极兜底，形成三层降级链路。
Codex 官网的图片服务架构遵循这一逻辑：所有上传的原始高清图（通常为 2400px 宽的 PNG 或 JPEG）首先由构建流水线或 CDN 自动编码为 AVIF；当用户请求的 Accept 头不包含 image/avif 时，CDN 回退输出 WebP；若两者均不支持，则返回质量参数 q=75 的 JPEG。这一策略在保持视觉无损的前提下，将图片体积平均压缩了 45%--60%。
值得注意的是，AVIF 的编码耗时约为 WebP 的 5--10 倍，因此首访冷编码会带来 200--500ms 的额外延迟。解决方案是在部署后主动预热关键页面的图片缓存，或采用构建时预生成（SSG）策略，将首屏图片在构建阶段即完成多格式编码。
二、Next.js <Image> 组件的自动优化
Next.js 的 <Image> 组件是这套链路的枢纽。它通过内置的 sharp 库在请求时自动完成格式转换、尺寸裁剪和 srcset 生成，开发者只需关注语义化的 sizes 属性。
sizes 属性的核心作用是告知浏览器当前图片在不同断点下的显示宽度，从而让其从 srcset 中选择最匹配的分辨率，避免向移动端下发桌面级大图。例如，一个占据 50% 视口宽度的产品卡片图应声明为：
jsx
<Image
src="/product/hero.jpg"
alt="产品主图"
width={1200}
height={800}
sizes="(max-width: 768px) 100vw, 50vw"
priority
/>Next.js 会根据 deviceSizes（默认 [640, 750, 828, 1080, 1200, 1920, 2048, 3840]）和 imageSizes 配置，自动生成包含多倍 DPR（设备像素比）的 srcset。在 Retina 屏幕上，浏览器会自动选择 2× 甚至 3× 分辨率的变体，确保锐利度的同时不浪费带宽。
在 next.config.ts 中启用双格式支持：
ts
export default {
images: {
formats: ['image/avif', 'image/webp'],
deviceSizes: [640, 750, 828, 1080, 1200, 1920, 2048, 3840],
imageSizes: [16, 32, 48, 64, 96, 128, 256, 384],
},
}数组顺序至关重要：当浏览器同时支持 AVIF 和 WebP 时，排在首位的 AVIF 会被优先匹配。
三、懒加载策略：eager vs lazy 与解码调度
并非所有图片都需要在页面加载瞬间获取。对于视口外的图片（如列表页第 3 屏以下的商品图、文章页的评论头像），应启用原生懒加载：
jsx
<Image
src="/gallery/photo-03.jpg"
alt="相册图片"
width={800}
height={600}
loading="lazy"
decoding="async"
/>loading="lazy" 利用浏览器的 Intersection Observer 延迟加载，直到图片进入视口阈值（通常为 1250px 缓冲区）才触发网络请求。decoding="async" 则将图片解码任务从主线程剥离，避免在滚动过程中因解码大量高分辨率图片而导致帧率下降。
但首屏 LCP 图片必须反其道而行之。 LCP（Largest Contentful Paint）是 Core Web Vitals 的核心指标，衡量首屏最大可见元素的渲染时间。若首屏主图被错误地标记为 loading="lazy"，浏览器会将其降级为非关键资源，导致 LCP 延迟 1--3 秒。正确的做法是：
jsx
<Image
src="/hero/banner.jpg"
alt="首页主视觉"
width={1920}
height={1080}
priority // 等价于 loading="eager" + fetchpriority="high"
sizes="100vw"
/>priority 属性会触发 Next.js 自动注入 <link rel="preload">，并设置 fetchpriority="high"，确保该图片在浏览器资源队列中享有最高调度优先级。在 Codex 官网的实测中，为 Hero 图添加 priority 后，LCP 从 2.4 秒改善至 0.9 秒。
四、模糊占位图：消除空白与布局跳动
在慢网环境下，图片从请求到完全渲染可能存在数百毫秒的空白期，引发两种负面体验：一是视觉上的"闪白"，二是如果未预设尺寸，图片加载完成后会撑开容器导致 Cumulative Layout Shift（CLS）。
Codex 采用 blur-up（模糊上采样） 技术解决这一问题。在构建阶段，使用 plaiceholder 或 blurhash 从原始图中提取 16×16 像素的低分辨率预览，编码为 Base64 数据 URI（通常仅 20--50 字节），内联在 HTML 中作为占位背景。
jsx
import { getPlaiceholder } from 'plaiceholder';
export async function getImageProps(src: string) {
const buffer = await fetch(src).then(r => r.arrayBuffer());
const { base64, img } = await getPlaiceholder(Buffer.from(buffer));
return {
...img,
blurDataURL: base64, // "data:image/jpeg;base64,/9j/4AAQ..."
};
}
// 组件中使用
<Image
src="/product/photo.jpg"
alt="产品图"
width={800}
height={600}
placeholder="blur"
blurDataURL={blurDataURL}
/>Next.js <Image> 在检测到 placeholder="blur" 时，会先用 blurDataURL 渲染一张模糊的小图，同时后台加载高清原图。原图就绪后，通过 CSS opacity 过渡实现平滑的"模糊变清晰"效果。这一策略不仅消除了 CLS，还将用户的"等待感知"转化为"渐进式期待"，在 3G 网络下的用户满意度提升了显著。
五、图片 CDN 的实时格式转换与质量压缩
自建图片处理流水线在规模扩大后面临 CPU 与存储的双重压力。Codex 官网将图片优化下沉至 CDN 边缘层，利用 Vercel Edge Network 的实时转换能力，将格式协商、尺寸裁剪和质量压缩全部在离用户最近的节点完成。
当浏览器请求 /_next/image?url=/hero.jpg&w=1200&q=75 时，Vercel Edge 会执行以下逻辑：
- 格式协商 ：读取请求头的
Accept，若包含image/avif则输出 AVIF，否则检查 WebP，最后回退 JPEG。 - 尺寸适配 ：根据
w参数将图片等比缩放至目标宽度，避免客户端下载冗余像素。 - 质量压缩 ：应用质量参数
q=75进行有损压缩。该值是视觉质量与体积的平衡点------在绝大多数摄影图上，q=75 与 q=90 的肉眼差异极小，但体积可再缩减 30%--40%。 - 边缘缓存：转换后的图片以内容哈希为键缓存于全球边缘节点，后续相同请求直接命中缓存，响应时间降至 50ms 以内。
对于自托管场景，也可配置自定义 loader 对接 Cloudinary、Imgix 或 Sanity CDN：
ts
// next.config.ts
export default {
images: {
loader: 'custom',
loaderFile: './lib/image-loader.ts',
},
};
// lib/image-loader.ts
export default function customLoader({ src, width, quality }: ImageLoaderProps) {
const params = new URLSearchParams();
params.set('url', src);
params.set('w', width.toString());
params.set('q', (quality || 75).toString());
params.set('f', 'auto'); // 让 CDN 自动选择 AVIF/WebP
return `https://images.codex.dev/cdn-cgi/image?${params.toString()}`;
}六、完整配置示例：Next.js Image 组件实战
以下是一个覆盖全链路优化的生产级 Image 组件封装，适用于 Codex 官网的内容页：
tsx
// components/OptimizedImage.tsx
import Image from 'next/image';
import { getPlaiceholder } from 'plaiceholder';
interface OptimizedImageProps {
src: string;
alt: string;
width: number;
height: number;
priority?: boolean;
className?: string;
sizes?: string;
}
export async function OptimizedImage({
src,
alt,
width,
height,
priority = false,
className,
sizes = '(max-width: 768px) 100vw, 50vw',
}: OptimizedImageProps) {
// 构建时生成模糊占位图（SSG 场景）
let blurDataURL: string | undefined;
if (!priority) {
try {
const buffer = await fetch(src).then(r => r.arrayBuffer());
const { base64 } = await getPlaiceholder(Buffer.from(buffer));
blurDataURL = base64;
} catch {
blurDataURL = undefined;
}
}
return (
<Image
src={src}
alt={alt}
width={width}
height={height}
sizes={sizes}
priority={priority}
loading={priority ? 'eager' : 'lazy'}
decoding={priority ? 'sync' : 'async'}
placeholder={blurDataURL ? 'blur' : 'empty'}
blurDataURL={blurDataURL}
className={className}
quality={75}
/>
);
}使用时的决策逻辑：
tsx
// 首屏 LCP 图片：priority + eager + sync 解码
<OptimizedImage
src="/hero/main-banner.jpg"
alt="首页主视觉"
width={1920}
height={1080}
priority
sizes="100vw"
/>
// 视口外图片：lazy + async + blur 占位
<OptimizedImage
src="/article/diagram.png"
alt="架构图"
width={800}
height={600}
sizes="(max-width: 768px) 100vw, 800px"
/>结语
图片优化是一项从格式选择、响应式适配、加载策略到边缘交付的全链路工程。Codex 官网通过 AVIF 优先的三层降级格式 、精准的 sizes 与自动 srcset 、LCP 感知的懒加载调度 、blur-up 渐进占位 以及 CDN 实时转换 的组合策略，将图片相关的 LCP 指标稳定控制在 1 秒以内，页面总传输体积减少超过 55%。在下一篇文章中，我们将探讨字体加载策略与 font-display 的最佳实践，进一步完善性能优化的最后一块拼图。
转载自：https://blog.csdn.net/sghtgjfhv/article/details/164077129
欢迎 👍点赞✍评论⭐收藏，欢迎指正