图片文件大小优化实战基于 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%HTTP Archive 数据。本指南以 Front-End-Checklist 仓库中的image-file-size规则为核心讲解如何为照片、图形、图标、缩略图建立可执行的体积阈值使用 Sharp、Squoosh 等工具构建压缩与格式转换管线并通过picturesrcset实现响应式交付。读完本文你将掌握一套检查 → 修复 → 自动化验证的图片体积治理流程直接用于优化 LCPLargest Contentful Paint与移动端带宽成本。关联文档skills/image-file-size/SKILL.md 与完整实现细节 skills/image-file-size/references/rule.md同一规则在内容库中还有一份可渲染版本 packages/content/rules/en/images/image-file-size.mdx。为什么图片文件大小至关重要图片通常是页面上最重的资源。据 HTTP Archive 数据图片平均占页面总重量的 40%–60%是带宽与加载时间的首要贡献者。超大图片会带来三重代价浪费用户带宽——在移动数据套餐下成本直接可见延迟 LCP——LCP 是 Core Web Vitals 的核心指标而最大图片往往主导该指标提高跳出率——据 Google 研究移动端页面加载每延迟 1 秒转化率最高可降低 20%。此外Google 的 Lighthouse 审计会将任何可减少超过4KB的图片标记为优化机会opportunity。这意味着即使单张图片只超了一点点也值得处理。本规则定级Priority: high · Difficulty: intermediate · Time: 20 min属于images/performance性能子域。快速参考体积预算一览先记住这组目标值作为日常审计的及格线资源类型目标体积推荐格式照片JPEG/WebP/AVIF低于 200KBWebP 80% 质量全宽 Hero / 横幅图低于 400KBWebP 或 AVIF图形 / 图标PNG/SVG低于 50KBSKILL 阈值或 100KB规则表阈值SVG矢量优先缩略图宽度 200px低于 30KBWebP 或 AVIF格式压缩红利依据 web.dev 的公开数据WebP比同等质量的 JPEG 小约25%–35%AVIF比同等质量的 JPEG 小约40%–50%。这两个百分比是选择格式时最重要的换算系数一张 300KB 的 JPEG转 WebP 后约 195–225KB转 AVIF 后约 150–180KB往往单凭格式转换就能跨过 200KB 红线。推荐体积阈值表完整版references/rule.md给出了按使用场景细分的阈值表注意区分内容图与电商商品图的差异图片类型最大推荐体积格式Hero / 全宽横幅图400KBWebP 或 AVIF内容照片文章、博客200KBWebP 或 AVIF商品图电商150KBWebP 或 AVIF缩略图30KBWebP 或 AVIF图标 / Logo10KBSVG 或 WebP带透明通道的 PNG100KBWebP含 alpha或 PNG这些是目标值而非硬性上限——例如一张面向 40% 桌面用户以 1600px 宽度展示的图在已正确优化的情况下合理超过 200KB。判断时结合实际展示尺寸与格式不要机械执行。Check如何审计项目中的图片体积按以下 5 步审计项目内所有图片资源对应 SKILL 的 Check 提示词逐个检查图片文件的实际字节数标记任何超过200KB的照片JPEG/WebP/AVIF标记任何超过100KB的图形/图标PNG/SVG标记任何超过400KB的 Hero 或全宽图标记任何超过30KB的缩略图宽度低于 200px。同时检查 Lighthouse 是否将Properly size images图片尺寸不当或Efficiently encode images图片编码低效列为优化机会。最终报告应包含每张超限图片的路径、当前体积、估算目标体积。执行场景包括图片管线审计、public/下的静态资源、CMS 托管的媒体、图片 CDN 转换参数。关键是要把文件体积问题与尺寸不匹配问题分开才能判断症结是压缩不足、格式选错还是响应式交付缺失这正是 SKILL 元数据中aiContext的核心提示。Fix压缩与格式转换的标准操作对每张超限图片按优先级执行以下 6 步对应 SKILL 的 Fix 提示词用 Squoosh、Sharp 或 ImageOptim 将 JPEG/PNG 转为WebP 80% 质量——相对已优化的 JPEG 通常再省 25%–35%进一步尝试AVIF 60% 质量——相对 JPEG 通常再省 40%–50%剥离对外提供的图片中的EXIF/IPTC 元数据PNG 用oxipng或pngquant做无损/近无损压缩SVG 用SVGO压缩实现多档srcset尺寸让移动端只下载更小的文件。Sharp 推荐参数Node.js# 使用 Sharp (Node.js) —— 推荐设置 # WebP照片 sharp(input.jpg).webp({ quality: 80 }).toFile(output.webp) # AVIF照片压缩率最高 sharp(input.jpg).avif({ quality: 60, effort: 6 }).toFile(output.avif) # JPEG旧浏览器兜底 sharp(input.jpg).jpeg({ quality: 80, progressive: true, mozjpeg: true }).toFile(output.jpg) # PNG无损 剥离元数据 sharp(input.png).png({ compressionLevel: 9, effort: 10 }).toFile(output.png)参数要点WebPquality: 80是照片在体积与观感之间的平衡点SKILL 与规则文档一致推荐AVIFquality: 60配合effort: 6在压缩率与编码耗时之间取折中——AVIF 编码比 JPEG/WebP 慢生产环境应构建期预生成而非运行时实时转换见 packages/content/rules/en/images/avif-format.mdx 中的 Warning 提示JPEG 的progressive: true与mozjpeg: true提供渐进式解码与更强的编码优化作为旧浏览器兜底PNG 的compressionLevel: 9effort: 10面向无损场景透明、截图。用picture按格式协商交付转换出多格式文件后用picture让浏览器自动选择支持的最小编码格式!-- 使用 picture 提供最小体积的受支持格式 -- picture source typeimage/avif srcsetphoto-400.avif 400w, photo-800.avif 800w sizes(max-width: 600px) 100vw, 50vw source typeimage/webp srcsetphoto-400.webp 400w, photo-800.webp 800w sizes(max-width: 600px) 100vw, 50vw img srcphoto-800.jpg srcsetphoto-400.jpg 400w, photo-800.jpg 800w sizes(max-width: 600px) 100vw, 50vw altPhoto description width800 height600 loadinglazy /picture这段标记同时体现了两个原则格式协商AVIF → WebP → JPEG 逐级兜底与响应式尺寸400w/800wsizes。注意img上始终保留width/height以避免布局偏移CLS这与仓库中 packages/content/rules/en/images/dimensions.mdx 的要求一致。批处理优化脚本把预算写进 CI手工处理容易遗漏references/rule.md提供了一个可直接落地的批处理脚本遍历图片目录、按扩展名对照阈值、自动生成 WebP 变体并报告节省比例// scripts/optimise-images.mjs import sharp from sharp import { globSync } from glob import { statSync } from fs import path from path const THRESHOLDS { .jpg: 200 * 1024, // 200KB .jpeg: 200 * 1024, .png: 100 * 1024, .webp: 200 * 1024, } const images globSync(public/images/**/*.{jpg,jpeg,png,webp}) for (const imgPath of images) { const ext path.extname(imgPath).toLowerCase() const threshold THRESHOLDS[ext] const size statSync(imgPath).size if (size threshold) { console.warn(Oversized: ${imgPath} (${Math.round(size / 1024)}KB, threshold ${Math.round(threshold / 1024)}KB)) // 生成 WebP 版本 const webpPath imgPath.replace(ext, .webp) await sharp(imgPath) .webp({ quality: 80 }) .toFile(webpPath) const webpSize statSync(webpPath).size const saving Math.round((1 - webpSize / size) * 100) console.log( → WebP: ${Math.round(webpSize / 1024)}KB (${saving}% smaller)) } }注意import sharp from sharp、import { globSync } from glob、import { statSync } from fs、import path from path四行需要按你的运行环境补齐脚本顶部依赖glob、sharp、Node 内置模块仓库规则文档中的完整版本即包含这些导入。Lighthouse CI 集成让回归在合并前失败在 CI 中通过 Lighthouse CI 的assert配置把图片预算固化为门禁。以下配置将两个关键审计设为 error 级且最低得分 0.9// lighthouserc.js module.exports { ci: { assert: { assertions: { // 任何图片可减少超过 4KB 即失败 uses-optimized-images: [error, { minScore: 0.9 }], // 任何图片显著大于其展示尺寸即失败 uses-responsive-images: [error, { minScore: 0.9 }], } } } }两个断言分别对应体积与尺寸两条防线uses-optimized-images检测高效编码图片机会即文件体积可以更小uses-responsive-images检测合理调整图片尺寸机会即像素尺寸远超渲染尺寸。这与 SKILL Check 步骤中要求关注的Properly size images尺寸与Efficiently encode images编码两个 Lighthouse 机会一一对应。剥离 EXIF/IPTC 元数据相机直出的图片通常嵌入 EXIF 元数据GPS 位置、相机型号、时间戳等这些字节对网页毫无价值却真实增加体积。Sharp 在转换格式时默认剥离元数据JPEG 到 JPEG 的转换也无需显式处理// Sharp 默认在格式转换时剥离元数据 // JPEG-to-JPEG 场景使用 withMetadata(false) 控制 await sharp(input.jpg) .jpeg({ quality: 80 }) // 元数据默认被剥离如需保留请显式调用 .withMetadata() .toFile(output.jpg)测试与验证确保优化真实生效规则文档给出了 4 步测试流程与双向验证清单测试步骤Chrome DevTools → Network 面板 → 按 Img 过滤 → 查看 Transfer Size 列运行 Lighthouse——关注 Properly size images 与 Efficiently encode images 两个机会项使用 WebPageTest 的水fall视图waterfall view定位大体积图片请求在 CI 中运行上述批处理脚本标记体积回归。自动化检查对比 DevTools 或 CDN 日志中优化前后的传输体积确认生产环境实际提供的是优化后的资源防止本地优化、线上仍发原图在真实设备上目测抽查几张图片避免为了省字节引入可见伪影artefacts。人工检查确认照片保持在约 200KB 以下、Hero 图 400KB 以下、缩略图 30KB 以下除非有文档化的例外压缩工作完成后复测 LCP——最大图片往往主导该指标压缩前后数值对比是优化是否有效的直接证据。仓库实践Front-End-Checklist 项目中的图片优化落地Front-End-Checklist 自身的 Web 应用apps/web就是该规则的活样本可作为参考实现Next.js 图片配置apps/web/next.config.js 中配置了完整的内置图片优化管线images: { formats: [image/avif, image/webp], // 允许的优化格式AVIF 优先 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 在浏览器支持时自动输出 AVIF/WebP对应规则格式转换省 25%–50%的策略无需手写picture框架自动做Accept协商deviceSizes/imageSizes决定自动生成的响应式尺寸档位对应规则第 6 步实现多档 srcsetremotePatterns限定可优化代理的远程图片来源是安全与性能并重的边界配置。组件层面的next/image用法仓库中大量组件使用next/image并显式声明sizes例如 apps/web/components/guides/guide-card.tsxImage 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 } /这里的sizes属性精确描述了卡片在不同断点下的渲染宽度featured 卡片占 50vw、普通卡片占 33vw配合fill模式让 Next.js 只生成并下发对应宽度的图片——这正是规则中用sizes反映真实 CSS 布局的最佳实践相关规则见 packages/content/rules/en/images/responsive-size.mdx。与其他规则的联动image-file-size在内容库中与以下规则互为关联审计时可打包执行packages/content/rules/en/images/modern-format.mdx转 WebP/AVIF 通常比 JPEG/PNG 小 25%–50%packages/content/rules/en/images/responsive-size.mdx按展示尺寸下发避免下载永不显示的像素packages/content/rules/en/images/optimized.mdx不换格式的纯压缩与优化packages/content/rules/en/images/dimensions.mdx与image-file-size同属images/performance区域常一起评审packages/content/rules/en/images/avif-format.mdxAVIF 的完整实现指南质量对照表、编码耗时警告。结语把图片体积变成可持续的工程约束图片文件大小的治理不是一次性动作而是一套可循环的工程闭环用阈值表建立预算 → 用 Check 清单定位超限资源 → 用 Sharp/Squoosh 压缩与格式转换 → 用picture/srcset/next/image响应式交付 → 用 Lighthouse CI 与批处理脚本防回归。Front-End-Checklist 的image-file-size规则及其在 apps/web/next.config.js 与组件中的落地实践为这套流程提供了完整的参考模板——从单张图片的 KB 级节约到 LCP 与转化率的整体改善都始于对图片体积这条红线的持续坚守。【免费下载链接】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），仅供参考 图片文件大小优化实战：基于 Front-End-Checklist 建立图片体积预算与压缩管线
图片文件大小优化实战基于 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%HTTP Archive 数据。本指南以 Front-End-Checklist 仓库中的image-file-size规则为核心讲解如何为照片、图形、图标、缩略图建立可执行的体积阈值使用 Sharp、Squoosh 等工具构建压缩与格式转换管线并通过picturesrcset实现响应式交付。读完本文你将掌握一套检查 → 修复 → 自动化验证的图片体积治理流程直接用于优化 LCPLargest Contentful Paint与移动端带宽成本。关联文档skills/image-file-size/SKILL.md 与完整实现细节 skills/image-file-size/references/rule.md同一规则在内容库中还有一份可渲染版本 packages/content/rules/en/images/image-file-size.mdx。为什么图片文件大小至关重要图片通常是页面上最重的资源。据 HTTP Archive 数据图片平均占页面总重量的 40%–60%是带宽与加载时间的首要贡献者。超大图片会带来三重代价浪费用户带宽——在移动数据套餐下成本直接可见延迟 LCP——LCP 是 Core Web Vitals 的核心指标而最大图片往往主导该指标提高跳出率——据 Google 研究移动端页面加载每延迟 1 秒转化率最高可降低 20%。此外Google 的 Lighthouse 审计会将任何可减少超过4KB的图片标记为优化机会opportunity。这意味着即使单张图片只超了一点点也值得处理。本规则定级Priority: high · Difficulty: intermediate · Time: 20 min属于images/performance性能子域。快速参考体积预算一览先记住这组目标值作为日常审计的及格线资源类型目标体积推荐格式照片JPEG/WebP/AVIF低于 200KBWebP 80% 质量全宽 Hero / 横幅图低于 400KBWebP 或 AVIF图形 / 图标PNG/SVG低于 50KBSKILL 阈值或 100KB规则表阈值SVG矢量优先缩略图宽度 200px低于 30KBWebP 或 AVIF格式压缩红利依据 web.dev 的公开数据WebP比同等质量的 JPEG 小约25%–35%AVIF比同等质量的 JPEG 小约40%–50%。这两个百分比是选择格式时最重要的换算系数一张 300KB 的 JPEG转 WebP 后约 195–225KB转 AVIF 后约 150–180KB往往单凭格式转换就能跨过 200KB 红线。推荐体积阈值表完整版references/rule.md给出了按使用场景细分的阈值表注意区分内容图与电商商品图的差异图片类型最大推荐体积格式Hero / 全宽横幅图400KBWebP 或 AVIF内容照片文章、博客200KBWebP 或 AVIF商品图电商150KBWebP 或 AVIF缩略图30KBWebP 或 AVIF图标 / Logo10KBSVG 或 WebP带透明通道的 PNG100KBWebP含 alpha或 PNG这些是目标值而非硬性上限——例如一张面向 40% 桌面用户以 1600px 宽度展示的图在已正确优化的情况下合理超过 200KB。判断时结合实际展示尺寸与格式不要机械执行。Check如何审计项目中的图片体积按以下 5 步审计项目内所有图片资源对应 SKILL 的 Check 提示词逐个检查图片文件的实际字节数标记任何超过200KB的照片JPEG/WebP/AVIF标记任何超过100KB的图形/图标PNG/SVG标记任何超过400KB的 Hero 或全宽图标记任何超过30KB的缩略图宽度低于 200px。同时检查 Lighthouse 是否将Properly size images图片尺寸不当或Efficiently encode images图片编码低效列为优化机会。最终报告应包含每张超限图片的路径、当前体积、估算目标体积。执行场景包括图片管线审计、public/下的静态资源、CMS 托管的媒体、图片 CDN 转换参数。关键是要把文件体积问题与尺寸不匹配问题分开才能判断症结是压缩不足、格式选错还是响应式交付缺失这正是 SKILL 元数据中aiContext的核心提示。Fix压缩与格式转换的标准操作对每张超限图片按优先级执行以下 6 步对应 SKILL 的 Fix 提示词用 Squoosh、Sharp 或 ImageOptim 将 JPEG/PNG 转为WebP 80% 质量——相对已优化的 JPEG 通常再省 25%–35%进一步尝试AVIF 60% 质量——相对 JPEG 通常再省 40%–50%剥离对外提供的图片中的EXIF/IPTC 元数据PNG 用oxipng或pngquant做无损/近无损压缩SVG 用SVGO压缩实现多档srcset尺寸让移动端只下载更小的文件。Sharp 推荐参数Node.js# 使用 Sharp (Node.js) —— 推荐设置 # WebP照片 sharp(input.jpg).webp({ quality: 80 }).toFile(output.webp) # AVIF照片压缩率最高 sharp(input.jpg).avif({ quality: 60, effort: 6 }).toFile(output.avif) # JPEG旧浏览器兜底 sharp(input.jpg).jpeg({ quality: 80, progressive: true, mozjpeg: true }).toFile(output.jpg) # PNG无损 剥离元数据 sharp(input.png).png({ compressionLevel: 9, effort: 10 }).toFile(output.png)参数要点WebPquality: 80是照片在体积与观感之间的平衡点SKILL 与规则文档一致推荐AVIFquality: 60配合effort: 6在压缩率与编码耗时之间取折中——AVIF 编码比 JPEG/WebP 慢生产环境应构建期预生成而非运行时实时转换见 packages/content/rules/en/images/avif-format.mdx 中的 Warning 提示JPEG 的progressive: true与mozjpeg: true提供渐进式解码与更强的编码优化作为旧浏览器兜底PNG 的compressionLevel: 9effort: 10面向无损场景透明、截图。用picture按格式协商交付转换出多格式文件后用picture让浏览器自动选择支持的最小编码格式!-- 使用 picture 提供最小体积的受支持格式 -- picture source typeimage/avif srcsetphoto-400.avif 400w, photo-800.avif 800w sizes(max-width: 600px) 100vw, 50vw source typeimage/webp srcsetphoto-400.webp 400w, photo-800.webp 800w sizes(max-width: 600px) 100vw, 50vw img srcphoto-800.jpg srcsetphoto-400.jpg 400w, photo-800.jpg 800w sizes(max-width: 600px) 100vw, 50vw altPhoto description width800 height600 loadinglazy /picture这段标记同时体现了两个原则格式协商AVIF → WebP → JPEG 逐级兜底与响应式尺寸400w/800wsizes。注意img上始终保留width/height以避免布局偏移CLS这与仓库中 packages/content/rules/en/images/dimensions.mdx 的要求一致。批处理优化脚本把预算写进 CI手工处理容易遗漏references/rule.md提供了一个可直接落地的批处理脚本遍历图片目录、按扩展名对照阈值、自动生成 WebP 变体并报告节省比例// scripts/optimise-images.mjs import sharp from sharp import { globSync } from glob import { statSync } from fs import path from path const THRESHOLDS { .jpg: 200 * 1024, // 200KB .jpeg: 200 * 1024, .png: 100 * 1024, .webp: 200 * 1024, } const images globSync(public/images/**/*.{jpg,jpeg,png,webp}) for (const imgPath of images) { const ext path.extname(imgPath).toLowerCase() const threshold THRESHOLDS[ext] const size statSync(imgPath).size if (size threshold) { console.warn(Oversized: ${imgPath} (${Math.round(size / 1024)}KB, threshold ${Math.round(threshold / 1024)}KB)) // 生成 WebP 版本 const webpPath imgPath.replace(ext, .webp) await sharp(imgPath) .webp({ quality: 80 }) .toFile(webpPath) const webpSize statSync(webpPath).size const saving Math.round((1 - webpSize / size) * 100) console.log( → WebP: ${Math.round(webpSize / 1024)}KB (${saving}% smaller)) } }注意import sharp from sharp、import { globSync } from glob、import { statSync } from fs、import path from path四行需要按你的运行环境补齐脚本顶部依赖glob、sharp、Node 内置模块仓库规则文档中的完整版本即包含这些导入。Lighthouse CI 集成让回归在合并前失败在 CI 中通过 Lighthouse CI 的assert配置把图片预算固化为门禁。以下配置将两个关键审计设为 error 级且最低得分 0.9// lighthouserc.js module.exports { ci: { assert: { assertions: { // 任何图片可减少超过 4KB 即失败 uses-optimized-images: [error, { minScore: 0.9 }], // 任何图片显著大于其展示尺寸即失败 uses-responsive-images: [error, { minScore: 0.9 }], } } } }两个断言分别对应体积与尺寸两条防线uses-optimized-images检测高效编码图片机会即文件体积可以更小uses-responsive-images检测合理调整图片尺寸机会即像素尺寸远超渲染尺寸。这与 SKILL Check 步骤中要求关注的Properly size images尺寸与Efficiently encode images编码两个 Lighthouse 机会一一对应。剥离 EXIF/IPTC 元数据相机直出的图片通常嵌入 EXIF 元数据GPS 位置、相机型号、时间戳等这些字节对网页毫无价值却真实增加体积。Sharp 在转换格式时默认剥离元数据JPEG 到 JPEG 的转换也无需显式处理// Sharp 默认在格式转换时剥离元数据 // JPEG-to-JPEG 场景使用 withMetadata(false) 控制 await sharp(input.jpg) .jpeg({ quality: 80 }) // 元数据默认被剥离如需保留请显式调用 .withMetadata() .toFile(output.jpg)测试与验证确保优化真实生效规则文档给出了 4 步测试流程与双向验证清单测试步骤Chrome DevTools → Network 面板 → 按 Img 过滤 → 查看 Transfer Size 列运行 Lighthouse——关注 Properly size images 与 Efficiently encode images 两个机会项使用 WebPageTest 的水fall视图waterfall view定位大体积图片请求在 CI 中运行上述批处理脚本标记体积回归。自动化检查对比 DevTools 或 CDN 日志中优化前后的传输体积确认生产环境实际提供的是优化后的资源防止本地优化、线上仍发原图在真实设备上目测抽查几张图片避免为了省字节引入可见伪影artefacts。人工检查确认照片保持在约 200KB 以下、Hero 图 400KB 以下、缩略图 30KB 以下除非有文档化的例外压缩工作完成后复测 LCP——最大图片往往主导该指标压缩前后数值对比是优化是否有效的直接证据。仓库实践Front-End-Checklist 项目中的图片优化落地Front-End-Checklist 自身的 Web 应用apps/web就是该规则的活样本可作为参考实现Next.js 图片配置apps/web/next.config.js 中配置了完整的内置图片优化管线images: { formats: [image/avif, image/webp], // 允许的优化格式AVIF 优先 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 在浏览器支持时自动输出 AVIF/WebP对应规则格式转换省 25%–50%的策略无需手写picture框架自动做Accept协商deviceSizes/imageSizes决定自动生成的响应式尺寸档位对应规则第 6 步实现多档 srcsetremotePatterns限定可优化代理的远程图片来源是安全与性能并重的边界配置。组件层面的next/image用法仓库中大量组件使用next/image并显式声明sizes例如 apps/web/components/guides/guide-card.tsxImage 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 } /这里的sizes属性精确描述了卡片在不同断点下的渲染宽度featured 卡片占 50vw、普通卡片占 33vw配合fill模式让 Next.js 只生成并下发对应宽度的图片——这正是规则中用sizes反映真实 CSS 布局的最佳实践相关规则见 packages/content/rules/en/images/responsive-size.mdx。与其他规则的联动image-file-size在内容库中与以下规则互为关联审计时可打包执行packages/content/rules/en/images/modern-format.mdx转 WebP/AVIF 通常比 JPEG/PNG 小 25%–50%packages/content/rules/en/images/responsive-size.mdx按展示尺寸下发避免下载永不显示的像素packages/content/rules/en/images/optimized.mdx不换格式的纯压缩与优化packages/content/rules/en/images/dimensions.mdx与image-file-size同属images/performance区域常一起评审packages/content/rules/en/images/avif-format.mdxAVIF 的完整实现指南质量对照表、编码耗时警告。结语把图片体积变成可持续的工程约束图片文件大小的治理不是一次性动作而是一套可循环的工程闭环用阈值表建立预算 → 用 Check 清单定位超限资源 → 用 Sharp/Squoosh 压缩与格式转换 → 用picture/srcset/next/image响应式交付 → 用 Lighthouse CI 与批处理脚本防回归。Front-End-Checklist 的image-file-size规则及其在 apps/web/next.config.js 与组件中的落地实践为这套流程提供了完整的参考模板——从单张图片的 KB 级节约到 LCP 与转化率的整体改善都始于对图片体积这条红线的持续坚守。【免费下载链接】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），仅供参考