前端图片优化全指南从格式选型、响应式 srcset 到 Core Web Vitals 的完整实践Front-End-Checklist 实战解析【免费下载链接】Front-End-Checklist The essential checklist for modern web development, for humans and AI agents项目地址: https://gitcode.com/gh_mirrors/fr/Front-End-Checklist图片通常占据网页总重量的 50% 以上是影响页面加载速度、带宽成本与 Core Web Vitals 评分的最主要因素之一。本文以 Front-End-Checklist 仓库中 image-optimization 规则 及其 详细参考文档 为主体结合仓库内 Next.js 应用的真实配置与组件源码系统讲解图片格式选型、压缩策略、响应式 srcset/sizes、延迟加载、CDN 集成等完整优化链路帮助读者掌握一套可落地、可验证的前端图片交付方案。规则概览为什么图片优化是优先级最高的性能工作在 Front-End-Checklist 的规则体系中image-optimization 被标记为优先级 high、难度 intermediate、预计耗时 20 分钟的规则其核心目标是Optimize all images for web即所有图片都应以合适的格式、压缩级别与现代技术进行交付。这条规则之所以被列为高优先级是因为图片的优化空间和回报都极为显著图片通常占页面总重量的50% 以上未优化的图片会直接拖慢加载时间、浪费带宽、拉低 Core Web Vitals 得分并导致移动网络下的用户流失优化得当的图片可以在几乎无可见质量损失的前提下减少50%–80% 的页面重量图片优化与 LCPLargest Contentful Paint最大内容绘制、CLSCumulative Layout Shift累积布局偏移两项核心指标直接相关是提升用户体验最立竿见影的切入点之一。在仓库配套的 Image Optimization 清单 中这条规则还串联了 webp-format、avif-format、responsive-images、image-compression、lazy-loading、image-cdn、dimensions、critical-images、retina-display、svg-optimization 等十余条相关规则构成一张完整的图片交付策略网。该清单明确给出了使用时机当媒体体积成为明显的性能问题或团队需要在深入调整渲染行为前进行一次结构化的图片交付优化时使用此清单。规则文件的典型结构SKILL.md 采用统一的 Check → Fix → Explain → Code Review 四段式结构这是 Front-End-Checklist 面向人类开发者与 AI Agent 双受众设计的格式Check检查扫描代码库中所有图片资源与img元素逐项验证格式、srcset、width/height、lazy loading 与文件体积Fix修复针对发现的问题给出具体转换、压缩与标记修复步骤Explain解释说明图片优化对 Core Web Vitals 的影响、各格式压缩差异与浏览器支持情况Code Review代码审查审查图片资产、标记与交付配置定位违反规则的文件并给出 DevTools 验证方法。下文将按照这条规则的检查要点展开逐项给出实战方案。第一步检查逐项核对图片资产的五项指标规则要求对代码库中所有图片资产与img元素逐张检查以下五项指标并按严重程度分组、附带文件路径报告问题检查项合格标准格式选择照片用 WebP/AVIF图标用 SVG仅透明场景用 PNG响应式 srcset/sizes宽度 100px 的图片必须提供 srcset 与 sizeswidth/height 属性必须显式声明防止布局偏移layout shift延迟加载首屏以下below-fold图片设置loadinglazy文件体积照片 200KB图形 50KB在检查真实仓库时可以重点留意三类典型问题用 PNG 存照片、单一大图服务所有屏幕、以及缺少 width/height 导致 CLS 波动。格式选型AVIF WebP JPEG/PNGSVG 留给图标规则给出了明确的格式优先级AVIF WebP JPEG/PNGSVG 用于图标与插画。参考文档中的格式对比表是选型的第一手依据格式最佳用途压缩能力浏览器支持AVIF所有图片比 JPEG 小约 50%现代浏览器WebP所有图片比 JPEG 小约 30%95% 浏览器JPEG照片良好全平台PNG透明图、Logo体积较大全平台SVG图标、插画可缩放全平台使用 AVIF 或 WebP 时必须提供回退方案。参考文档特别提醒Safari 直到 16.4 版本2023 年才加入 AVIF 支持部分企业浏览器可能连 WebP 都不支持因此picture元素的逐级回退是安全交付的底线。最稳妥的实现方式是使用picture元素让浏览器自行选择首个支持的格式!-- 现代格式带回退 -- picture source srcsetimage.avif typeimage/avif source srcsetimage.webp typeimage/webp img srcimage.jpg altDescription loadinglazy /picture三类易错场景的对照!-- ❌ 错误常见问题 -- img srcphoto.png altPhoto!-- PNG 存照片 -- img srchero-4000px.jpg!-- 无响应式尺寸 -- img srcicon.jpg width20!-- 小图标用 JPEG -- !-- ✅ 正确优化版本 -- picture source srcsetphoto.avif typeimage/avif source srcsetphoto.webp typeimage/webp img srcphoto.jpg altPhoto loadinglazy /picture img srcicon.svg altIcon width20 height20!-- 图标用 SVG --关于格式的补充要点SVG 不需要格式转换它本身就是为 Web 优化的矢量格式动图 GIF若动画较大改用视频MP4/WebM承载通常更省流量极小图片 1KB可作为 base64 data URI 内联减少一次 HTTP 请求用户上传内容往往需要服务端优化管道而非构建期处理因为上传路径不可控、体积不可预估。压缩策略照片 80% 质量AVIF 60% 质量规则给出的压缩基准是照片压缩到 80% 质量AVIF 压缩到 60% 质量。参考文档同时提醒质量低于 60% 会产生肉眼可见的压缩伪影artifacts属于过度压缩需要避免。这套参数在 Sharp 批处理脚本中体现得最直观参考文档中的scripts/optimize-images.js示例// scripts/optimize-images.js const sharp require(sharp) const fs require(fs).promises const path require(path) const SIZES [400, 800, 1200, 1600] const FORMATS [webp, avif, jpeg] async function optimizeImage(inputPath, outputDir) { const { name } path.parse(inputPath) for (const width of SIZES) { for (const format of FORMATS) { const outputPath path.join(outputDir, ${name}-${width}w.${format}) await sharp(inputPath) .resize(width, null, { withoutEnlargement: true }) .toFormat(format, { quality: format avif ? 60 : 80, effort: 6 }) .toFile(outputPath) } } console.log(✅ Optimized: ${name}) }这段脚本的关键点在于SIZES [400, 800, 1200, 1600]与规则建议的 srcset 变体宽度400w/800w/1200w/1600w一一对应withoutEnlargement: true防止小图被放大避免无意义的体积增长quality: 80 / 60落实了照片 80%、AVIF 60%的压缩基准effort: 6是编码器耗时与压缩率的平衡点值越高压缩效果越好但编码越慢。如果是 Vite 项目可以在构建插件中直接配置同样的质量参数参考文档中的vite.config.js示例// vite.config.js plugins: [ viteImageOptimizer({ jpg: { quality: 80, progressive: true }, png: { quality: 80 }, webp: { quality: 80, effort: 6 }, avif: { quality: 60, effort: 6 } }) ]参考文档还推荐了四类常用优化工具Squoosh浏览器端压缩、SharpNode.js 图像处理、ImageOptim桌面端批量优化、Cloudinary/imgix支持运行时按需优化的 CDN。响应式图片srcset sizes 的配合机制srcset 与 sizes 如何协同工作规则要求宽度超过 100px 的图片必须提供 srcset 与 sizes。两者的分工是srcset提供同一图片的不同宽度变体如 400w、800w、1200w、1600w并附带各自的固有宽度描述sizes告诉浏览器该图片在页面布局中实际占用的宽度如小屏满宽、大屏半宽浏览器据此在 srcset 中选出最合适的变体下载。参考文档中的标准示例!-- ✅ 正确带 srcset 的响应式图片 -- img srcimage-800w.jpg srcset image-400w.jpg 400w, image-800w.jpg 800w, image-1200w.jpg 1200w, image-1600w.jpg 1600w sizes(max-width: 600px) 100vw, (max-width: 1200px) 50vw, 800px altResponsive image loadinglazy !-- ❌ 错误所有屏幕都加载同一张大图 -- img srcimage-1600w.jpg altLarge imagesrcset中的w描述符是图片的固有像素宽度sizes中的100vw、50vw、800px是布局期望宽度两者配合才能让浏览器按屏幕尺寸 × 设备像素比DPR选择最小够用的变体。对 Retina 屏而言还应考虑提供 2x 图这在配套清单的 retina-display 规则中有更详细的展开。Art Direction不同断点用不同裁剪当不同屏幕尺寸需要不同的裁剪或宽高比而非单纯缩放时就要在picture中用media属性做艺术指导art directionpicture !-- 移动端正方形裁剪 -- source media(max-width: 600px) srcsethero-square.webp !-- 平板4:3 比例 -- source media(max-width: 1024px) srcsethero-4x3.webp !-- 桌面宽横幅 -- img srchero-wide.jpg altHero image /picture注意这里的区别srcset负责同一内容、不同分辨率media负责不同断点、不同内容/裁剪两者服务于不同需求可组合使用。为什么 width/height 必须显式声明规则要求所有图片带显式 width/height与宽高比一致。原因在于浏览器需要知道图片的预留空间。如果图片加载完成后才确定高度后续内容会被向下推挤产生 CLS。显式声明尺寸后浏览器可提前预留位置即使图片尚未加载完成页面也不会跳动。加载策略首屏优先级 vs 首屏以下懒加载规则明确规定首屏以下below-fold的图片设置loadinglazy优先级图片首屏关键图不加懒加载。参考文档补充了首屏以上/以下的差异化策略首屏以上Above the Fold预加载关键 hero 图使用fetchpriorityhigh或 preload使用合适的尺寸不大于实际需要极小图片可考虑内联 base64省去额外请求。首屏以下Below the Fold使用loadinglazy实现原生延迟加载使用占位图或 blur-up 渐进加载技术在进入视口时再触发加载懒加载的底层原理。参考文档还给出了 React 中的 blur-up 渐进加载示例先用模糊小图占位待原图加载完成后做透明度/模糊过渡避免空白闪屏// Progressive loading with blur-up function ProgressiveImage({ src, placeholder, alt }) { const [loaded, setLoaded] useState(false) const [currentSrc, setCurrentSrc] useState(placeholder) useEffect(() { const img new Image() img.onload () { setCurrentSrc(src) setLoaded(true) } img.src src }, [src]) return ( img src{currentSrc} alt{alt} className{transition-all duration-300 ${ loaded ? blur-0 : blur-sm }} / ) }懒加载的收益在首屏加载阶段最明显不阻塞页面渲染、按需下载。但要避免一个误区——hero 图首屏大图不能懒加载否则会直接推迟 LCP。框架实战React 与 Vue 中的可复用优化组件React自动生成多尺寸 srcset 的picture封装参考文档提供了一个完整的 React 组件把格式协商AVIF/WebP、多尺寸 srcset 与懒加载封装成单个组件function OptimizedImage({ src, alt, sizes 100vw }) { // Generate srcset for multiple sizes const widths [400, 800, 1200, 1600] const srcset widths .map(w ${src}?w${w} ${w}w) .join(, ) return ( picture {/* Modern formats */} source typeimage/avif srcSet{srcset.replace(/\?w/g, ?formatavifw)} sizes{sizes} / source typeimage/webp srcSet{srcset.replace(/\?w/g, ?formatwebpw)} sizes{sizes} / {/* Fallback */} img src{${src}?w800} srcSet{srcset} sizes{sizes} alt{alt} loadinglazy decodingasync classNamew-full h-auto / /picture ) }该组件把规则中的核心要求——格式回退、400/800/1200/1600 四档宽度、sizes 提示、loadinglazy、decodingasync——全部固化成了默认行为团队成员只需传入src与alt即可获得符合规范的图片输出。这种用组件强制规范的做法是让图片优化不依赖个人自觉的关键。Vue声明式 props 加载过渡参考文档同样给出了 Vue 3 的script setup版本将 src、alt、sizes、widths 作为 props 暴露并内置透明度过渡动画template picture source v-forformat in formats :keyformat :typeimage/${format} :srcsetgenerateSrcset(format) :sizessizes / img :srcfallbackSrc :altalt loadinglazy decodingasync loadonLoad :class{ opacity-0: !loaded, opacity-100: loaded } classtransition-opacity duration-300 / /picture /template script setup const props defineProps({ src: { type: String, required: true }, alt: { type: String, required: true }, sizes: { type: String, default: 100vw }, widths: { type: Array, default: () [400, 800, 1200, 1600] } }) const loaded ref(false) const formats [avif, webp] const generateSrcset (format) { return props.widths .map(w ${props.src}?format${format}w${w} ${w}w) .join(, ) } const fallbackSrc computed(() ${props.src}?w800) const onLoad () { loaded.value true } /script两个版本的实现思路完全一致widths默认[400, 800, 1200, 1600]、formats固定为[avif, webp]、fallbackSrc取 800w 变体与规则中的 srcset 变体规范一一对应。仓库实战Front-End-Checklist 自身的图片交付实现作为一条人类与 AI Agent 通用的前端清单规则Front-End-Checklist 的 Web 应用apps/web本身就是这套规范的最佳落点。从源码结构看它采用了 Next.js 的图像优化管线这正是对规则中构建工具/CDN 集成章节的工程化回应。Next.js images 配置默认开启 AVIF/WebP 自动协商在 apps/web/next.config.js 中图片交付做了三件事images: { formats: [image/avif, image/webp], deviceSizes: [640, 828, 1200, 1920], imageSizes: [32, 64, 128, 256], remotePatterns: [ { protocol: https, hostname: avatars.githubusercontent.com, pathname: /** }, { protocol: https, hostname: images.opencollective.com, pathname: /** } ] }formats: [image/avif, image/webp]让 Next.js 根据请求头中的Accept自动做格式协商浏览器支持时自动返回 AVIF/WebP否则回退原格式——这正是规则要求的格式回退在框架层的实现deviceSizes/imageSizes定义响应式断点集合配合next/image的sizes属性决定生成哪些尺寸变体对应规则中的 srcset 策略remotePatterns白名单模式只允许对 avatars.githubusercontent.com 与 images.opencollective.com 两个外部域名做代理优化防止任意外部图片滥用本地优化服务。值得一提的是 proxy.ts 的 matcher 正则主动排除了_next/image路径与svg|png|jpg|jpeg|gif|webp|ico等静态资源后缀确保图片请求不会被代理中间层二次处理避免优化管线与代理逻辑相互干扰。组件层的落地GuideCard 的响应式封面在 apps/web/components/guides/guide-card.tsx 中指南卡片封面图的写法可以作为next/image的响应式范本Image src{guide.coverImage} alt fill classNameobject-cover transition-transform duration-300 group-hover:scale-[1.02] sizes{ priority featured ? (min-width: 1024px) 50vw, 100vw : (min-width: 1024px) 33vw, 100vw } /这里fill让图片填满由 CSS 定义的容器容器在 Card 中通过aspect-[16/9]或aspect-[16/8]固定了宽高比对应规则的width/height 防布局偏移sizes则区分了推荐位桌面 50vw与普通卡片桌面 33vw的布局宽度。由于外层容器已锁定宽高比页面不会因图片加载产生 CLS。头像组件的容错处理SponsorAvatarapps/web/components/homepage/sponsor-avatar.tsx 演示了远程头像的另一种场景——加载失败降级return ( Image src{sponsor.avatarUrl} alt{displayName} fill unoptimized className{cn(object-cover, className)} sizes{${size}px} onError{() setHasError(true)} / )这里unoptimized是因为头像域名未加入 remotePatterns 白名单且体积极小无需本地压缩而sizes{${size}px}精确声明了渲染尺寸onError触发时回退到初始字母占位块。fill模式配合固定尺寸的容器同样避免了布局偏移。它同时展示了规则边界内的合理例外小尺寸、非核心的图片可以跳过部分优化步骤。静态资源的类型声明apps/web/types/images.d.ts 为*.png、*.jpg、*.jpeg、*.webp提供了StaticImageData类型声明让本地静态图片可以无缝接入next/image的类型系统——这也是仓库在工程层面保证每张图片都走优化管线的细节之一。CDN 与构建管线让格式协商与缩放自动发生参考文档明确指出生产环境中应使用支持自动图片优化的 CDN如 Cloudflare Images、Imgix、Cloudinary它们能根据访问者的浏览器和设备自动完成格式协商、缩放与压缩开发者无需手工维护每个变体文件。对于自有图片管线picture元素配合 CDN 的查询参数即可实现按需交付——上文 React/Vue 组件中的?w、?format参数正是这种模式的雏形CDN 收到参数后动态生成对应格式与宽度的图片并缓存。参考文档还给出了 Next.js 中接入外部图片 CDN 的配置片段// For external images, configure next.config.js module.exports { images: { remotePatterns: [{ hostname: cdn.example.com }] } }选择哪种方案取决于部署环境已有 CDN优先用 CDN 的图片优化能力无 CDN 或纯静态部署则用 Sharp 等工具在构建期生成多格式、多尺寸变体Next.js 项目可完全依赖内置的next/image优化端点本仓库即此方案。常见错误清单与规避要点参考文档集中列举了六个高频错误逐条对应规则的检查项把桌面大图发给移动端—— 必须用 srcset sizes 做响应式交付缺少 width/height—— 导致 CLS 累积布局偏移过度压缩—— 质量低于 60% 会产生可见伪影忽略格式回退—— 不是所有浏览器都支持 AVIF/WebP不启用懒加载—— 所有图片立即加载阻塞页面渲染超大的 hero 图—— 首屏图必须优先处理并优化体积。再补充参考文档中的三条场景性建议SVG 不需要格式转换它本身就是 Web 优化的矢量格式大型动画 GIF更适合改用视频MP4/WebM承载 1KB 的极小小图可直接 base64 内联省去一次 HTTP 请求用户上传内容需要服务端优化管道而不是构建期处理。验证与回归如何确认优化真实生效规则提供了完整的验证路径分为自动与手动两层。自动化检查慢网测试用 Chrome DevTools 的 Network 面板开启Slow 3G限速观察首屏加载与图片到达顺序LCP 度量用 Lighthouse 或 Web Vitals 扩展确认LCP 2.5s。手动检查文件体积图片应普遍小于200KB照片/ 50KB图标格式协商验证打开 Network 面板确认实际响应的是 WebP/AVIF而非原始 JPEG/PNG以验证 CDN 或next/image的格式协商按预期工作按浏览器矩阵核对由于图片格式与交付行为会随浏览器、CDN 与设备特性变化必须对支持的浏览器矩阵逐一核对最终字节数与渲染输出当现代格式或加载行为无法覆盖某个目标浏览器时需补充回退说明。参考文档最后提醒图片格式与交付行为可能因浏览器、CDN 和设备特性而异务必在支持的浏览器矩阵上验证最终字节与渲染输出并在目标浏览器不支持现代格式或加载行为时记录回退说明。总结一套完整可复用的图片交付策略将规则与仓库实现串联起来一套完整的图片交付策略包含五层格式层AVIF/WebP 优先、SVG 用于图标、PNG 仅留透明场景用picture保证回退压缩层照片 80% 质量、AVIF 60% 质量用 Sharp 或构建插件统一执行响应式层srcset 提供 400/800/1200/1600 四档变体sizes 声明布局宽度width/height 锁死宽高比防 CLS加载层首屏关键图预加载首屏以下懒加载 blur-up 占位交付层生产环境交给 CDN 或next/image自动协商格式、按设备缩放同时用工具Lighthouse、DevTools持续验证 LCP 与 CLS。前端开发者可将上述规则固化为可复用组件如参考文档中的OptimizedImage与统一的构建配置评审者则可依据规则中的检查清单逐项核对、按严重程度报告问题。从零散的一次性修复升级为体系化的图片交付策略正是这条规则希望达成的最终状态。仓库中 SKILL.md、规则参考文档 与 Image Optimization 清单 可供随时查阅next.config.js 与 guide-card.tsx 则是上述策略的工程化范本。【免费下载链接】Front-End-Checklist The essential checklist for modern web development, for humans and AI agents项目地址: https://gitcode.com/gh_mirrors/fr/Front-End-Checklist创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考