【免费下载链接】Front-End-Checklist The essential checklist for modern web development, for humans and AI agents项目地址https://gitcode.com/gh_mirrors/fr/Front-End-Checklist点击查看免费下载未优化的图片是页面臃肿最常见的元凶一张带 EXIF 数据的 DSLR 级 JPEG 可能有 8MB而同一张图片经过 Web 交付优化后不足 200KB肉眼几乎看不出差别。本篇指南以 Front-End Checklist 仓库中的optimized规则SKILL.md 与 reference/rule.md为骨架结合仓库内的规则内容optimized.mdx与 Web 应用的真实配置完整讲解图片优化的检查方法、修复手段、底层原理与构建/CI 集成方案。读完你将掌握如何用 Lighthouse 定位可压缩图片、如何用 Sharp/pngquant/oxipng/SVGO 处理 JPEG/PNG/SVG、如何把优化流程固化进 Vite 构建管线与 CI 检查以及如何用 DevTools 验证优化结果。规则概览优先级别与适用场景Front-End Checklist 将optimizedOptimise images for faster loading规则归类为优先级Priorityhigh难度Difficultyintermediate预估耗时Estimated Time20 分钟分类Categoryimages图片该规则的核心定义见 optimized.mdx是图片优化是在向用户提供文件之前对图片数据进行压缩并剥离多余元数据的过程。它与格式选择JPEG vs WebP和响应式尺寸调整是不同维度的优化——三者各自通过不同方式减小文件体积。这意味着审查图片资产、标记markup以及 CDN 或构建转换build transforms时需要把编码后尺寸encoded size、渲染尺寸rendered size、加载策略loading strategy和首屏above-the-fold影响放在一起检查。为什么图片优化如此重要未优化的图片是页面膨胀最主要的原因。一个典型的对比DSLR 相机直出的 JPEG 含 EXIF 数据体积可达 8MB同一张图片针对 Web 交付优化后通常低于 200KB且无可见的画质差异见 SKILL.md 与 optimized.mdx。Lighthouse 的Efficiently encode images高效编码图片审计会逐张报告每张图片可节省的字节数——凡是可再压缩 4KB 以上的图片都会被标记为优化机会。修复这些问题会直接带来两个收益改善 LCPLargest Contentful PaintLCP 元素通常是首屏大图减少其传输字节数能显著缩短最大内容绘制时间降低带宽成本同一张图片少传几十 KB在大量访问下累计节省的流量非常可观。在 image-optimization.mdx 中仓库还进一步把图片优化与 Core Web Vitals 联系起来未优化图片直接影响 LCP 与 CLSCumulative Layout Shift而优化后的图片通过合理压缩与正确标记可同时改善两者。优化到底移除了什么理解图片优化首先要明白哪些多余的字节藏在图片里。根据 reference/rule.md 与 optimized.mdx一次完整的优化会移除以下几类数据数据类别说明典型体积EXIF 元数据相机嵌入的 GPS 定位、相机型号、镜头信息、时间戳每张 30–60KBIPTC/XMP 元数据图片编辑软件写入的编辑信息数 KBICC 色彩配置文件Web 交付极少需要每张数 KB冗余像素数据以较低质量重新压缩后去除人眼不可见的高频数据视图片而定SVG 编辑器残留Inkscape/Illustrator/Figma 导出时加入的注释、ID、内联样式生产环境毫无用处注意一个关键点元数据剥离与格式选择是两回事。即使不更换格式仅剥离 EXIF/IPTC/ICC 就能让 JPEG/WebP 减少大量字节而换用 WebP/AVIF 则是在压缩层面获得额外收益详见相关规则 modern-format.mdx。底层原理JPEG、PNG 与渐进式编码Explain部分见 optimized.mdx要求从技术层面解释图片优化的原理这也是 Agent/LLM 理解该规则的关键上下文JPEG 压缩先把像素数据转换为频率分量DCT离散余弦变换然后对高频数据进行量化quantisation。质量参数quality控制的正是量化的激进程度——质量越低被丢弃的高频细节越多文件越小PNG 压缩使用无损的 DEFLATE 压缩。但通过颜色量化colour quantisation即 pngquant 所做的工作可以将调色板压缩到更少的颜色数量从而在肉眼几乎无变化的前提下大幅减小文件体积EXIF 元数据GPS、相机型号、时间戳会给每张图片增加数千字节但对 Web 用户毫无价值渐进式 JPEGprogressive JPEG允许浏览器先立即显示一张低分辨率版本再随着完整图片加载逐步变清晰从而显著改善感知性能perceived performance。关于渐进式 JPEG仓库的 progressive-jpeg.mdx 补充了更多细节渐进式 JPEG 比逐行baseline加载的 JPEG 感知更快——用户能立刻看到模糊预览而不是从上到下逐行渲染其文件大小与 baseline 相近有时反而更小在现代格式WebP/AVIF普及的今天它仍然是回退fallback场景下的重要手段。检查如何审计项目中的图片资产按 SKILL.md 的Check指令审计全部图片资产应执行以下五步运行 Lighthouse查看 Efficiently encode images 审计——它会标记所有可再压缩 4KB 及以上的图片检查 JPEG 是否使用渐进式编码渐进式有更好的感知性能检查图片是否残留 EXIF/IPTC 元数据增加了无谓的字节检查 PNG 是否可做颜色量化pngquant以进一步缩小体积检查 SVG 是否包含无用的编辑器元数据、注释或冗余属性。审计结果需要逐张报告每张图片的当前大小与预估可节省量这样后续修复才有明确的优先级依据。自动化检查工具除了 Lighthousereference/rule.md 的Verification章节给出了一组可落地的验证手段Chrome DevTools → Network按Img过滤查看每张图片的Transfer Size传输大小列确认实际下载的字节数exiftool处理后运行exiftool -all output.jpg确认元数据确实已被剥离Squoosh打开每张图片原图与压缩结果并排对比人工确认画质无可见劣化。修复按格式逐类处理根据 SKILL.md 的Fix指令对每张未优化的图片按格式分别处理JPEG用 mozjpeg 以质量 80 重新编码并开启progressivetruePNG有损压缩运行pngquant --quality65-80无损压缩运行oxipngWebP质量 80 编码AVIF质量 60、effort 6 编码SVG通过 SVGO 移除编辑器元数据、注释与冗余属性全部 JPEG/WebP 图片剥离 EXIF 元数据。修复完成后同样要为每张图片给出优化前后的文件大小与百分比缩减作为效果证明。SharpNode.js服务端处理首选reference/rule.md 给出的核心代码示例使用 Sharp 处理 JPEG// Sharp (Node.js) — recommended for server-side processing import sharp from sharp await sharp(input.jpg) .jpeg({ quality: 80, // 80 is the sweet spot: minimal visible loss, 40-60% size reduction progressive: true, // Progressive JPEG shows low-res preview while loading mozjpeg: true, // Use mozjpeg encoder for better compression at same quality }) .toFile(output.jpg) // Note: sharp strips metadata by default参数要点quality: 80是文件体积与画质的甜点区通常可带来 40–60% 的体积缩减progressive: true启用渐进式编码加载时先显示低分辨率预览mozjpeg: true使用 mozjpeg 编码器在相同质量下压缩率更好Sharp默认剥离元数据无需额外配置。PNG有损与无损两条路线reference/rule.md 提供了命令行与 Sharp 两种方式# pngquant: lossy compression, 40-80% size reduction with minimal visible change pngquant --quality65-80 --output output.png input.png # oxipng: lossless compression, 10-20% reduction with zero quality loss oxipng -o 6 input.png两条路线的取舍很清晰pngquant 是有损压缩通过颜色量化实现 40–80% 的缩减肉眼几乎无变化oxipng 是无损压缩只获得 10–20% 的缩减但零质量损失。对应地Sharp 的 PNG 编码选项await sharp(input.png) .png({ compressionLevel: 9, // 0-9, higher smaller but slower effort: 10, // 1-10, higher slower but better compression palette: true, // Enable palette quantisation for PNGs with few colours quality: 80, // Quality when palette is true }) .toFile(output.png)SVGSVGO 清理编辑器残留reference/rule.md 的命令行方式# SVGO: removes editor metadata, comments, redundant attributes npx svgo input.svg -o output.svg # Or process all SVGs in a directory npx svgo --folder public/iconsSVGO 完整插件配置svgo.config.js覆盖了从文档级清理到路径优化的全部环节module.exports { plugins: [ removeDoctype, removeXMLProcInst, removeComments, removeMetadata, removeEditorsNSData, cleanupAttrs, mergeStyles, inlineStyles, minifyStyles, cleanupIds, removeUselessDefs, cleanupNumericValues, convertColors, removeUnknownsAndDefaults, removeNonInheritableGroupAttrs, removeUselessStrokeAndFill, removeViewBox, // Set to false if you need responsive SVGs cleanupEnableBackground, convertShapeToPath, convertEllipseToCircle, moveElemsAttrsToGroup, moveGroupAttrsToElems, collapseGroups, convertPathData, convertTransform, removeEmptyAttrs, removeEmptyContainers, mergePaths, removeUnusedNS, sortDefsChildren, removeTitle, removeDesc, ], }配置中值得特别注意的是removeViewBox如果 SVG 需要响应式缩放必须将其设为 false否则会破坏 viewBox 导致缩放失效同理removeTitle与removeDesc会删除无障碍可读的标题与描述文本在无障碍要求严格的场景下应谨慎开启。构建管线集成让优化自动化手工逐张优化不可持续reference/rule.md 给出了构建期自动优化的 Vite 方案// vite.config.js — automatic optimisation at build time import { defineConfig } from vite import { viteImageOptimizer } from vite-plugin-image-optimizer export default defineConfig({ plugins: [ viteImageOptimizer({ jpg: { quality: 80, progressive: true }, jpeg: { quality: 80, progressive: true }, png: { quality: 80, compressionLevel: 9 }, webp: { quality: 80, effort: 6 }, avif: { quality: 60, effort: 6 }, svg: { plugins: [ { name: removeViewBox, active: false }, { name: removeDimensions, active: true }, ], }, }) ] })各格式参数与前面的手动方案完全对齐JPEG 系列质量 80 渐进式PNG 质量 80 最高压缩级别WebP 质量 80、effort 6AVIF 质量 60、effort 6AVIF 编码更重effort 6 是体积/速度的平衡点SVG 通过插件数组显式控制removeViewBox关闭以保留响应式能力removeDimensions开启以移除固定尺寸。本项目中的真实对照Next.js 图片配置本仓库的 Web 应用apps/web/next.config.js在 Next.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 的Image组件在浏览器支持时自动协商输出 AVIF/WebP与优化规则现代格式优先的思路一致deviceSizes与imageSizes控制响应式尺寸断点配合srcset只下发必要的像素对应相关规则 responsive-size.mdx 的诉求remotePatterns限定可优化的远程图片域名白名单。这印证了规则文档中的结论图片优化与格式选择、响应式尺寸是协同关系——压缩移除字节、现代格式提升压缩率、正确尺寸避免下发永远不会被渲染的像素。自动化 CI 检查守住优化底线优化是一次性动作但防回退需要 CI 把关。reference/rule.md 提供了一个可放入 CI 的检查脚本// scripts/check-image-optimisation.mjs // Fail CI if any image could be reduced by more than 10KB import { execSync } from child_process import { globSync } from glob const images globSync(public/**/*.{jpg,jpeg,png,gif}) let failed false for (const imgPath of images) { try { // Use identify (ImageMagick) to check for metadata const result execSync(identify -verbose ${imgPath} 21 | grep -i exif\\|iptc\\|comment, { encoding: utf8, stdio: [pipe, pipe, pipe], }) if (result.trim()) { console.warn(⚠️ Metadata found in: ${imgPath}) failed true } } catch { // No metadata found — this is good } } if (failed) process.exit(1)该脚本的机制是用globSync扫描public目录下所有位图格式用 ImageMagick 的identify -verbose检查 EXIF/IPTC/comment 元数据一旦发现元数据残留即输出警告并让 CI 失败process.exit(1)。这种元数据即失败信号的策略简单可靠可以作为团队防回退的第一道闸门。代码审查定位违规与验证修复规则的最后一部分是 Code Review 视角SKILL.md审查图片资产、标记markup与交付配置找出格式选择、尺寸或加载行为违反规则的具体文件或组件并说明如何在 DevTools 中确认修复。实际操作时应从三条线索入手格式违规img src指向.jpg/.jpeg/.png且未通过 CDN 自动协商格式或picture缺少image/webp/image/avif的source分支审查要点详见 modern-format.mdx尺寸违规图片渲染尺寸远小于下发尺寸即多余的像素被白白下载对应 responsive-size.mdx加载行为违规首屏关键图被懒加载或非关键图未懒加载对应 critical-images.mdx 与懒加载规则。DevTools 验证方法在 Network 面板按 Img 过滤对比每张图片的 Requested请求尺寸与 Transfer Size传输尺寸再配合 Lighthouse 的 Efficiently encode images 审计确认修复后该图片不再出现在优化机会列表中即可判定修复生效。规则在技能体系中的位置在 Front-End Checklist 仓库中每条规则都被生成器scripts/generate/generate-skills.ts转换为可供 AI Agent 直接调用的技能SkillSKILL.md承载name、description以 Use when 开头以匹配 Agent 意图与check/fix/explain/codeReview四组提示词references/rule.md则承载完整实现细节。optimized技能的定位即是在审查图片资产、标记以及 CDN/构建转换时将编码尺寸、渲染尺寸、加载策略与首屏影响一并检查见 SKILL.md 的 frontmatter 描述。该规则在规则库中还与以下规则形成审查协作网optimized.mdx 中的 relatedRulesmodern-format转换到 WebP/AVIF 在 JPEG/PNG 优化之外提供额外压缩responsive-size下发正确尺寸的图片可消除从未被渲染的像素image-file-size优化是文件体积达到推荐阈值的手段svg-inline与optimized同属images/optimization区域常一起审查。落地清单把本篇指南压缩成一份可直接执行的清单审计对全部图片资产运行 Lighthouse Efficiently encode images逐张记录当前大小与可节省量JPEGSharp/mozjpeg 质量 80 progressive: true并剥离 EXIFPNGpngquant--quality65-80有损或 oxipng-o 6无损WebP/AVIF分别按质量 80 / 质量 60 effort 6 编码SVGSVGO 按上述插件配置清理注意removeViewBox与无障碍元素的取舍固化把参数写进 Vite/Next.js 构建配置让构建期自动优化防回退在 CI 中加入元数据检查脚本任何残留元数据即失败验证DevTools Network 确认 Transfer Size、exiftool 确认元数据已剥离、Squoosh 并排对比确认画质。完成这八步图片将不再拖累 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点击查看免费下载相关推荐Front-End-Checklist 图片 CDN 实战指南从 URL 变换到 Next.js 集成的端到端优化Front End Checklist 图片 CDN 实战指南从 URL 变换到 Next.js 集成的端到端优化 图片往往是网页体积与首屏性能的最大开销来源Front-End-Checklist 图片体积治理实战从文件大小阈值到自动化的完整方案Front End Checklist 图片体积治理实战从文件大小阈值到自动化的完整方案 图片体积是页面体量的头号贡献者直接影响加载时间、LCPLarge图片文件大小优化实战基于 Front-End-Checklist 建立图片体积预算与压缩管线图片文件大小优化实战基于 Front End Checklist 建立图片体积预算与压缩管线 图片体积是网页重量的最大单一来源平均占比超过 50%HTTP创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Front-End Checklist 图片优化实战：从 EXIF 清理到构建管线集成的完整方案
【免费下载链接】Front-End-Checklist The essential checklist for modern web development, for humans and AI agents项目地址https://gitcode.com/gh_mirrors/fr/Front-End-Checklist点击查看免费下载未优化的图片是页面臃肿最常见的元凶一张带 EXIF 数据的 DSLR 级 JPEG 可能有 8MB而同一张图片经过 Web 交付优化后不足 200KB肉眼几乎看不出差别。本篇指南以 Front-End Checklist 仓库中的optimized规则SKILL.md 与 reference/rule.md为骨架结合仓库内的规则内容optimized.mdx与 Web 应用的真实配置完整讲解图片优化的检查方法、修复手段、底层原理与构建/CI 集成方案。读完你将掌握如何用 Lighthouse 定位可压缩图片、如何用 Sharp/pngquant/oxipng/SVGO 处理 JPEG/PNG/SVG、如何把优化流程固化进 Vite 构建管线与 CI 检查以及如何用 DevTools 验证优化结果。规则概览优先级别与适用场景Front-End Checklist 将optimizedOptimise images for faster loading规则归类为优先级Priorityhigh难度Difficultyintermediate预估耗时Estimated Time20 分钟分类Categoryimages图片该规则的核心定义见 optimized.mdx是图片优化是在向用户提供文件之前对图片数据进行压缩并剥离多余元数据的过程。它与格式选择JPEG vs WebP和响应式尺寸调整是不同维度的优化——三者各自通过不同方式减小文件体积。这意味着审查图片资产、标记markup以及 CDN 或构建转换build transforms时需要把编码后尺寸encoded size、渲染尺寸rendered size、加载策略loading strategy和首屏above-the-fold影响放在一起检查。为什么图片优化如此重要未优化的图片是页面膨胀最主要的原因。一个典型的对比DSLR 相机直出的 JPEG 含 EXIF 数据体积可达 8MB同一张图片针对 Web 交付优化后通常低于 200KB且无可见的画质差异见 SKILL.md 与 optimized.mdx。Lighthouse 的Efficiently encode images高效编码图片审计会逐张报告每张图片可节省的字节数——凡是可再压缩 4KB 以上的图片都会被标记为优化机会。修复这些问题会直接带来两个收益改善 LCPLargest Contentful PaintLCP 元素通常是首屏大图减少其传输字节数能显著缩短最大内容绘制时间降低带宽成本同一张图片少传几十 KB在大量访问下累计节省的流量非常可观。在 image-optimization.mdx 中仓库还进一步把图片优化与 Core Web Vitals 联系起来未优化图片直接影响 LCP 与 CLSCumulative Layout Shift而优化后的图片通过合理压缩与正确标记可同时改善两者。优化到底移除了什么理解图片优化首先要明白哪些多余的字节藏在图片里。根据 reference/rule.md 与 optimized.mdx一次完整的优化会移除以下几类数据数据类别说明典型体积EXIF 元数据相机嵌入的 GPS 定位、相机型号、镜头信息、时间戳每张 30–60KBIPTC/XMP 元数据图片编辑软件写入的编辑信息数 KBICC 色彩配置文件Web 交付极少需要每张数 KB冗余像素数据以较低质量重新压缩后去除人眼不可见的高频数据视图片而定SVG 编辑器残留Inkscape/Illustrator/Figma 导出时加入的注释、ID、内联样式生产环境毫无用处注意一个关键点元数据剥离与格式选择是两回事。即使不更换格式仅剥离 EXIF/IPTC/ICC 就能让 JPEG/WebP 减少大量字节而换用 WebP/AVIF 则是在压缩层面获得额外收益详见相关规则 modern-format.mdx。底层原理JPEG、PNG 与渐进式编码Explain部分见 optimized.mdx要求从技术层面解释图片优化的原理这也是 Agent/LLM 理解该规则的关键上下文JPEG 压缩先把像素数据转换为频率分量DCT离散余弦变换然后对高频数据进行量化quantisation。质量参数quality控制的正是量化的激进程度——质量越低被丢弃的高频细节越多文件越小PNG 压缩使用无损的 DEFLATE 压缩。但通过颜色量化colour quantisation即 pngquant 所做的工作可以将调色板压缩到更少的颜色数量从而在肉眼几乎无变化的前提下大幅减小文件体积EXIF 元数据GPS、相机型号、时间戳会给每张图片增加数千字节但对 Web 用户毫无价值渐进式 JPEGprogressive JPEG允许浏览器先立即显示一张低分辨率版本再随着完整图片加载逐步变清晰从而显著改善感知性能perceived performance。关于渐进式 JPEG仓库的 progressive-jpeg.mdx 补充了更多细节渐进式 JPEG 比逐行baseline加载的 JPEG 感知更快——用户能立刻看到模糊预览而不是从上到下逐行渲染其文件大小与 baseline 相近有时反而更小在现代格式WebP/AVIF普及的今天它仍然是回退fallback场景下的重要手段。检查如何审计项目中的图片资产按 SKILL.md 的Check指令审计全部图片资产应执行以下五步运行 Lighthouse查看 Efficiently encode images 审计——它会标记所有可再压缩 4KB 及以上的图片检查 JPEG 是否使用渐进式编码渐进式有更好的感知性能检查图片是否残留 EXIF/IPTC 元数据增加了无谓的字节检查 PNG 是否可做颜色量化pngquant以进一步缩小体积检查 SVG 是否包含无用的编辑器元数据、注释或冗余属性。审计结果需要逐张报告每张图片的当前大小与预估可节省量这样后续修复才有明确的优先级依据。自动化检查工具除了 Lighthousereference/rule.md 的Verification章节给出了一组可落地的验证手段Chrome DevTools → Network按Img过滤查看每张图片的Transfer Size传输大小列确认实际下载的字节数exiftool处理后运行exiftool -all output.jpg确认元数据确实已被剥离Squoosh打开每张图片原图与压缩结果并排对比人工确认画质无可见劣化。修复按格式逐类处理根据 SKILL.md 的Fix指令对每张未优化的图片按格式分别处理JPEG用 mozjpeg 以质量 80 重新编码并开启progressivetruePNG有损压缩运行pngquant --quality65-80无损压缩运行oxipngWebP质量 80 编码AVIF质量 60、effort 6 编码SVG通过 SVGO 移除编辑器元数据、注释与冗余属性全部 JPEG/WebP 图片剥离 EXIF 元数据。修复完成后同样要为每张图片给出优化前后的文件大小与百分比缩减作为效果证明。SharpNode.js服务端处理首选reference/rule.md 给出的核心代码示例使用 Sharp 处理 JPEG// Sharp (Node.js) — recommended for server-side processing import sharp from sharp await sharp(input.jpg) .jpeg({ quality: 80, // 80 is the sweet spot: minimal visible loss, 40-60% size reduction progressive: true, // Progressive JPEG shows low-res preview while loading mozjpeg: true, // Use mozjpeg encoder for better compression at same quality }) .toFile(output.jpg) // Note: sharp strips metadata by default参数要点quality: 80是文件体积与画质的甜点区通常可带来 40–60% 的体积缩减progressive: true启用渐进式编码加载时先显示低分辨率预览mozjpeg: true使用 mozjpeg 编码器在相同质量下压缩率更好Sharp默认剥离元数据无需额外配置。PNG有损与无损两条路线reference/rule.md 提供了命令行与 Sharp 两种方式# pngquant: lossy compression, 40-80% size reduction with minimal visible change pngquant --quality65-80 --output output.png input.png # oxipng: lossless compression, 10-20% reduction with zero quality loss oxipng -o 6 input.png两条路线的取舍很清晰pngquant 是有损压缩通过颜色量化实现 40–80% 的缩减肉眼几乎无变化oxipng 是无损压缩只获得 10–20% 的缩减但零质量损失。对应地Sharp 的 PNG 编码选项await sharp(input.png) .png({ compressionLevel: 9, // 0-9, higher smaller but slower effort: 10, // 1-10, higher slower but better compression palette: true, // Enable palette quantisation for PNGs with few colours quality: 80, // Quality when palette is true }) .toFile(output.png)SVGSVGO 清理编辑器残留reference/rule.md 的命令行方式# SVGO: removes editor metadata, comments, redundant attributes npx svgo input.svg -o output.svg # Or process all SVGs in a directory npx svgo --folder public/iconsSVGO 完整插件配置svgo.config.js覆盖了从文档级清理到路径优化的全部环节module.exports { plugins: [ removeDoctype, removeXMLProcInst, removeComments, removeMetadata, removeEditorsNSData, cleanupAttrs, mergeStyles, inlineStyles, minifyStyles, cleanupIds, removeUselessDefs, cleanupNumericValues, convertColors, removeUnknownsAndDefaults, removeNonInheritableGroupAttrs, removeUselessStrokeAndFill, removeViewBox, // Set to false if you need responsive SVGs cleanupEnableBackground, convertShapeToPath, convertEllipseToCircle, moveElemsAttrsToGroup, moveGroupAttrsToElems, collapseGroups, convertPathData, convertTransform, removeEmptyAttrs, removeEmptyContainers, mergePaths, removeUnusedNS, sortDefsChildren, removeTitle, removeDesc, ], }配置中值得特别注意的是removeViewBox如果 SVG 需要响应式缩放必须将其设为 false否则会破坏 viewBox 导致缩放失效同理removeTitle与removeDesc会删除无障碍可读的标题与描述文本在无障碍要求严格的场景下应谨慎开启。构建管线集成让优化自动化手工逐张优化不可持续reference/rule.md 给出了构建期自动优化的 Vite 方案// vite.config.js — automatic optimisation at build time import { defineConfig } from vite import { viteImageOptimizer } from vite-plugin-image-optimizer export default defineConfig({ plugins: [ viteImageOptimizer({ jpg: { quality: 80, progressive: true }, jpeg: { quality: 80, progressive: true }, png: { quality: 80, compressionLevel: 9 }, webp: { quality: 80, effort: 6 }, avif: { quality: 60, effort: 6 }, svg: { plugins: [ { name: removeViewBox, active: false }, { name: removeDimensions, active: true }, ], }, }) ] })各格式参数与前面的手动方案完全对齐JPEG 系列质量 80 渐进式PNG 质量 80 最高压缩级别WebP 质量 80、effort 6AVIF 质量 60、effort 6AVIF 编码更重effort 6 是体积/速度的平衡点SVG 通过插件数组显式控制removeViewBox关闭以保留响应式能力removeDimensions开启以移除固定尺寸。本项目中的真实对照Next.js 图片配置本仓库的 Web 应用apps/web/next.config.js在 Next.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 的Image组件在浏览器支持时自动协商输出 AVIF/WebP与优化规则现代格式优先的思路一致deviceSizes与imageSizes控制响应式尺寸断点配合srcset只下发必要的像素对应相关规则 responsive-size.mdx 的诉求remotePatterns限定可优化的远程图片域名白名单。这印证了规则文档中的结论图片优化与格式选择、响应式尺寸是协同关系——压缩移除字节、现代格式提升压缩率、正确尺寸避免下发永远不会被渲染的像素。自动化 CI 检查守住优化底线优化是一次性动作但防回退需要 CI 把关。reference/rule.md 提供了一个可放入 CI 的检查脚本// scripts/check-image-optimisation.mjs // Fail CI if any image could be reduced by more than 10KB import { execSync } from child_process import { globSync } from glob const images globSync(public/**/*.{jpg,jpeg,png,gif}) let failed false for (const imgPath of images) { try { // Use identify (ImageMagick) to check for metadata const result execSync(identify -verbose ${imgPath} 21 | grep -i exif\\|iptc\\|comment, { encoding: utf8, stdio: [pipe, pipe, pipe], }) if (result.trim()) { console.warn(⚠️ Metadata found in: ${imgPath}) failed true } } catch { // No metadata found — this is good } } if (failed) process.exit(1)该脚本的机制是用globSync扫描public目录下所有位图格式用 ImageMagick 的identify -verbose检查 EXIF/IPTC/comment 元数据一旦发现元数据残留即输出警告并让 CI 失败process.exit(1)。这种元数据即失败信号的策略简单可靠可以作为团队防回退的第一道闸门。代码审查定位违规与验证修复规则的最后一部分是 Code Review 视角SKILL.md审查图片资产、标记markup与交付配置找出格式选择、尺寸或加载行为违反规则的具体文件或组件并说明如何在 DevTools 中确认修复。实际操作时应从三条线索入手格式违规img src指向.jpg/.jpeg/.png且未通过 CDN 自动协商格式或picture缺少image/webp/image/avif的source分支审查要点详见 modern-format.mdx尺寸违规图片渲染尺寸远小于下发尺寸即多余的像素被白白下载对应 responsive-size.mdx加载行为违规首屏关键图被懒加载或非关键图未懒加载对应 critical-images.mdx 与懒加载规则。DevTools 验证方法在 Network 面板按 Img 过滤对比每张图片的 Requested请求尺寸与 Transfer Size传输尺寸再配合 Lighthouse 的 Efficiently encode images 审计确认修复后该图片不再出现在优化机会列表中即可判定修复生效。规则在技能体系中的位置在 Front-End Checklist 仓库中每条规则都被生成器scripts/generate/generate-skills.ts转换为可供 AI Agent 直接调用的技能SkillSKILL.md承载name、description以 Use when 开头以匹配 Agent 意图与check/fix/explain/codeReview四组提示词references/rule.md则承载完整实现细节。optimized技能的定位即是在审查图片资产、标记以及 CDN/构建转换时将编码尺寸、渲染尺寸、加载策略与首屏影响一并检查见 SKILL.md 的 frontmatter 描述。该规则在规则库中还与以下规则形成审查协作网optimized.mdx 中的 relatedRulesmodern-format转换到 WebP/AVIF 在 JPEG/PNG 优化之外提供额外压缩responsive-size下发正确尺寸的图片可消除从未被渲染的像素image-file-size优化是文件体积达到推荐阈值的手段svg-inline与optimized同属images/optimization区域常一起审查。落地清单把本篇指南压缩成一份可直接执行的清单审计对全部图片资产运行 Lighthouse Efficiently encode images逐张记录当前大小与可节省量JPEGSharp/mozjpeg 质量 80 progressive: true并剥离 EXIFPNGpngquant--quality65-80有损或 oxipng-o 6无损WebP/AVIF分别按质量 80 / 质量 60 effort 6 编码SVGSVGO 按上述插件配置清理注意removeViewBox与无障碍元素的取舍固化把参数写进 Vite/Next.js 构建配置让构建期自动优化防回退在 CI 中加入元数据检查脚本任何残留元数据即失败验证DevTools Network 确认 Transfer Size、exiftool 确认元数据已剥离、Squoosh 并排对比确认画质。完成这八步图片将不再拖累 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点击查看免费下载相关推荐Front-End-Checklist 图片 CDN 实战指南从 URL 变换到 Next.js 集成的端到端优化Front End Checklist 图片 CDN 实战指南从 URL 变换到 Next.js 集成的端到端优化 图片往往是网页体积与首屏性能的最大开销来源Front-End-Checklist 图片体积治理实战从文件大小阈值到自动化的完整方案Front End Checklist 图片体积治理实战从文件大小阈值到自动化的完整方案 图片体积是页面体量的头号贡献者直接影响加载时间、LCPLarge图片文件大小优化实战基于 Front-End-Checklist 建立图片体积预算与压缩管线图片文件大小优化实战基于 Front End Checklist 建立图片体积预算与压缩管线 图片体积是网页重量的最大单一来源平均占比超过 50%HTTP创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考