Front-End-Checklist 图片优化指南：从 Sharp/SVGO 压缩到构建管线与 CI 落地

Front-End-Checklist 图片优化指南从 Sharp/SVGO 压缩到构建管线与 CI 落地【免费下载链接】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 数据的单反 JPEG 可能高达 8MB而面向 Web 交付的同图经过压缩后可低于 200KB 且无肉眼可见的画质损失。本文以 Front-End-Checklist 开源仓库中optimized规则规则参考文档为核心系统讲解 JPEG/PNG/SVG 的压缩原理、Sharp 与 pngquant/oxipng/SVGO 的完整参数配置、构建期自动优化、CI 元数据巡检以及验证方法并引入本仓库的源码与配置作为落地佐证。读完你可以在任何项目中复刻一套部署前压缩 元数据剥离 自动化巡检的图片优化流水线。一、什么是图片优化与格式选择和响应式尺寸的边界图片优化image optimisation的核心动作是压缩图像数据、剥离多余元数据再把这些文件交付给用户。它和另外两类常见手段是三个独立维度各自以不同方式减小文件体积手段削减对象典型工具图片优化本文主题冗余像素数据、EXIF/IPTC/XMP/ICC 等元数据、编辑器残留Sharp、pngquant、oxipng、SVGO、exiftool格式选择编码方式本身JPEG vs WebP vs AVIFSquoosh、cwebp、avifenc响应式尺寸永远渲染不出来的多余像素按视口尺寸裁剪缩放srcset/sizes、Next.js ImageFront-End-Checklist 仓库把这条规则放在images/optimization分类下见 规则元数据并与modern-format、responsive-size、image-file-size、svg-inline互为相关规则格式转换提供超越 JPEG/PNG 优化之上的额外压缩正确尺寸消除了从未被渲染的像素而优化正是让文件体积达到推荐阈值的手段。底层原理压缩发生在哪里要无感地压缩图片需要理解三类文件各自的压缩机制规则技能文档 Explain 提示词 对此有完整阐述JPEG把像素数据变换为频率分量DCT然后对高频分量做量化quantisation。quality 参数控制的正是量化的激进程度——高频细节是人眼难以察觉的激进量化可以大幅减重而几乎无损。PNG使用无损的 DEFLATE 压缩但通过颜色量化pngquant 的调色板缩减可以取得看起来几乎一样、体积锐减的有损效果。渐进式 JPEG浏览器可以先显示低分辨率预览、再逐渐变清晰改善的是感知性能而非最终体积progressive-jpeg 规则 中优先级为 low说明它在现代格式下仍作为回退方案有价值。二、为什么重要页面膨胀、LCP 与带宽成本未优化的图片是页面臃肿page bloat最常见的原因。规则文档给出的量化对比单反质量 JPEG 携带 EXIF 数据可达8MB同一张图面向 Web 优化后低于 200KB肉眼无差异。Lighthouse 的 Efficiently encode images 审计会逐图报告可节省的字节数能缩减 4KB 及以上的图片会被标记为机会项。修复这些机会将直接改善 LCPLargest Contentful Paint因为首屏最大内容元素通常是图片同时降低带宽成本——在移动网络下这直接决定页面能否在合理时间内加载。三、优化到底移除了什么规则文档明确列出优化会剥离的五类冗余内容EXIF 元数据— 相机写入的 GPS 定位、相机型号、镜头信息、时间戳等单张可增加 30-60KBIPTC/XMP 元数据— 照片编辑软件附加的编辑信息ICC 色彩配置文件— Web 交付极少需要每份几 KB冗余像素数据— 低质量重编码移除了人眼不可见的高频数据SVG 编辑器残留— Inkscape/Illustrator/Figma 导出时会写入注释、ID、内联样式等生产环境毫无用途的内容。四、JPEG 优化Sharp mozjpeg 的标准做法服务端处理推荐 SharpNode.js。规则文档给出的核心代码原文档// Sharp (Node.js) — recommended for server-side processing 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参数解读参数推荐值作用quality80甜点区间肉眼几乎无损体积减少 40-60%更低会引入可见伪影progressivetrue渐进式编码加载时先显示低清预览提升感知性能mozjpegtrue使用 mozjpeg 编码器同等质量下压缩率更好元数据默认剥离Sharp 默认移除 EXIF 等元数据无需额外处理五、PNG 优化有损量化与无损压缩双路线PNG 有两条互补的优化路线原文档完整给出# 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.pngpngquant有损颜色量化体积可减少 40-80%视觉变化极小适合照片级或色彩丰富的 PNGoxipng无损压缩零画质损失体积减少 10-20%适合需要严格保持像素的场合。Sharp 也内置了完整的 PNG 压缩参数// Sharp PNG compression 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)参数速查compressionLevel0-9越大越慢越小、effort1-10越大压缩效果越好但耗时越长、palette: true对颜色数少的 PNG 启用调色板量化、quality仅在palette开启时生效。六、SVG 优化SVGO 全量配置SVG 的膨胀来自编辑器Inkscape/Illustrator/Figma导出的元数据、注释和冗余属性。规则文档给出了命令行与完整配置两种用法# 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/icons完整配置svgo.config.js// SVGO configuration (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移除title/desc会降低无障碍可用性若 SVG 承担语义角色需谨慎权衡可参考仓库中 svg-inline 规则 的取舍建议。仓库中 svg-optimization 规则 给出的数据表明SVGO 通常可将 SVG 体积减少 50-80%且应保留 viewBox 与无障碍相关属性并将优化集成进构建流程实现自动处理。七、构建管线集成构建期自动优化手工优化难以长期坚持规则文档推荐把优化挂进构建流程。Vite 生态的vite-plugin-image-optimizer可在构建时自动处理全部图片// vite.config.js — automatic optimisation at build time 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/PNG/WebP 用 quality 80而 AVIF 用 quality 60AVIF 编码效率更高更低的 quality 即可获得同等视觉质量SVG 部分显式关闭removeViewBox以保证响应式能力并开启removeDimensions。仓库实践对照本仓库的应用端Next.js在 apps/web/next.config.js 中配置了与上述策略一致的图片交付管道images: { formats: [image/avif, image/webp], deviceSizes: [640, 828, 1200, 1920], imageSizes: [32, 64, 128, 256], remotePatterns: [...] }formats明确声明优先输出 AVIF/WebP 现代格式对应 modern-format 规则deviceSizes/imageSizes生成多档响应式尺寸对应responsive-size规则——优化、格式、尺寸三条线在本项目中正是协同工作的。八、自动化 CI 检查让未优化图片阻断发布规则文档提供了一个开箱即用的 CI 巡检脚本任何图片若仍携带元数据可再缩减CI 直接失败// scripts/check-image-optimisation.mjs // Fail CI if any image could be reduced by more than 10KB 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)工作原理遍历public目录下所有 jpg/jpeg/png/gif用 ImageMagick 的identify -verbose检查 EXIF/IPTC/comment 元数据捕获到任何元数据即置失败标志并最终以非零退出码结束从而阻断 CI 流水线。你可以在自己的项目中把该脚本挂到 pre-commit 或 CI job 里作为部署前压缩的最后一道闸门。九、验证如何确认优化生效自动化检查原文档完整给出运行 Lighthouse —— Efficiently encode images 会逐图显示可节省的字节数Chrome DevTools → Network → 按 Img 过滤 → 查看每张图的Transfer Size传输大小列处理后运行exiftool -all output.jpg确认元数据确已剥离。手动检查在 Squoosh 中逐张打开图片并排对比原图与压缩图肉眼确认画质无损。仓库中的审查流程本仓库为这条规则内置了结构化的 Agent 审查流程见 skills/optimized/SKILL.md可作为团队 Code Review 的检查清单Check运行 Lighthouse 找出可缩减 4KB 的图片检查 JPEG 是否渐进式检查是否残留 EXIF/IPTC检查 PNG 是否可量化检查 SVG 是否含编辑器元数据与冗余属性——逐图报告当前大小与预计节省量FixJPEG 用 mozjpeg 以 quality 80 progressive: true重编码PNG 用 pngquantquality 65-80或 oxipngWebP 用 quality 80AVIF 用 quality 60 effort 6SVG 过 SVGO所有 JPEG/WebP 剥离 EXIF并给出前后体积与百分比对比Explain向团队解释 DCT 量化、DEFLATE、颜色量化、元数据开销与渐进式加载的感知性能原理Code Review定位到具体文件标注格式、尺寸或加载行为违反规则的组件并描述如何在 DevTools 中确认修复。该技能的分类为images、优先级high、难度intermediate、预估耗时 20 分钟元数据见 skills/optimized/SKILL.md与规则库中的 optimized.mdx 保持同一口径——适合作为一次图片优化专项排期的参照标准。十、实操清单把规则落到自己的项目综合本文全部内容落地一份可执行的图片优化流程资产盘点运行 Lighthouse记录 Efficiently encode images 列出的全部图片及其可节省字节JPEGSharp 以quality: 80progressive: truemozjpeg: true批量重编码PNG颜色少的用 pngquantquality 65-80需无损的用 oxipng-o 6SVGnpx svgo --folder批量清理保留 viewBox 与必要的无障碍元素元数据确认 EXIF/IPTC/ICC 全部剥离Sharp 默认剥离其他工具链用 exiftool 复核构建集成将viteImageOptimizer或等价构建插件接入构建管线格式质量档参照 AVIF 60 / 其余 80CI 门禁部署scripts/check-image-optimisation.mjs类脚本元数据残留即阻断发布持续验证将 Lighthouse 的图片审计纳入性能回归防止新资产带病上线。由此形成压缩 剥离 自动构建 CI 巡检 定期复核的完整闭环与 Front-End-Checklist 仓库中optimized规则的设计意图完全一致。【免费下载链接】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），仅供参考