Front-End-Checklist 响应式尺寸Responsive Size实践指南用 srcset 与 sizes 根治图片过度下载【免费下载链接】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 仓库中的 responsive-size 规则文档 为核心系统讲解响应式尺寸Responsive Size这一图片性能规则的原理、实现与验证方法。你将掌握为什么给 400px 容器下发 2000px 图片会浪费约 25 倍流量、如何用srcsetsizes让浏览器按视口与设备像素比自动选择最优候选图、如何用 Sharp 批量生成多尺寸变体、如何用 DevTools 脚本审计页面中的超大图片以及 React / Next.js 框架下的落地写法。什么是响应式尺寸响应式尺寸Responsive Size指的是图片文件的像素尺寸与它在浏览器中实际渲染的尺寸相匹配。规则原文将其表述为 Images are not significantly larger than their display dimensions即图片不应显著大于其显示尺寸。该规则在本仓库中属于images分类下的性能子类优先级为high高、难度为intermediate中级、预估耗时20 分钟见 规则元数据 与 SKILL 定义。一个典型反例为 300px 的缩略图下发 2000px 的图片浏览器实际会下载约 44 倍的无关数据。由于带宽成本与像素数量成正比而非与线性尺寸成正比尺寸翻倍意味着约 4 倍的下载量——这种浪费远比表面看起来严重。为什么它如此重要带宽与 LCP 双重代价一张超大的 Hero 图片可能让页面白白增加数 MB 的下载量。在 375px 宽的移动设备上下发 1600px 的图片意味着下载了用户实际所需数据量的 4 倍。Lighthouse 的Properly size images图片尺寸是否恰当审计持续将这一项列为大多数网站中影响最高的性能优化机会之一——它会对每张超大图片给出可节省的 KB 估算值是衡量优化收益的最直接信号。数据对比场景图片固有宽度渲染宽度多余数据倍数缩略图2000px300px~44x普通示例2000px400px~25x移动端1600px375px~4x带宽成本与像素数量成正比即宽度与高度的乘积而非线性尺寸。2000px 渲染成 400px理论上浪费了 25 倍的像素数据。错误示范一个img引发的流量灾难!-- ❌ Bad: 2000px image rendered at 400px — 25x too much data -- img srcphoto-2000w.jpg altProduct photo stylewidth: 400px;这段代码的问题在于浏览器会完整下载 2000×1500px 的源文件却只展示 400×300px。假如photo-2000w.jpg有 800KB而按需裁切的photo-400w.jpg仅约 50KB一次渲染就多花了约 750KB。解决方案srcset sizes 组合拳正确的做法是为同一张图片准备多个宽度变体并用srcset列出各候选、用sizes描述各断点下的实际渲染宽度让浏览器自行决策!-- ✅ Good: Browser picks the appropriate size based on viewport and display density -- img srcphoto-800w.jpg srcset photo-400w.jpg 400w, photo-800w.jpg 800w, photo-1200w.jpg 1200w, photo-1600w.jpg 1600w sizes(max-width: 480px) 100vw, (max-width: 900px) 50vw, 400px altProduct photo width1600 height1200 loadinglazy 要点拆解src作为兜底地址建议使用中等尺寸如 800w规则文档明确推荐src fallback 用中等尺寸详见 SKILL 的 Fix 步骤srcset宽度描述符w以实际像素宽度标注每个候选如photo-400w.jpg 400wsizes描述图片在各断点下的渲染宽度浏览器结合视口宽度与devicePixelRatioDPR选出最优候选width/height声明固有尺寸避免 CLS布局偏移loadinglazy延迟加载视口外图片降低首屏开销。深入理解 sizes 属性sizes是整个机制精度的关键它告诉浏览器图片在每个断点处实际会渲染多宽。浏览器用渲染宽度 × DPR去匹配srcset中最近的候选。以下是规则文档给出的常见布局模式写法!-- sizes examples for common layout patterns -- !-- Full-width image -- img sizes100vw ... !-- Half-width grid on desktop, full-width on mobile -- img sizes(max-width: 768px) 100vw, 50vw ... !-- Card in a 3-column grid with 24px gap, max 1200px container -- img sizes(max-width: 768px) 100vw, (max-width: 1200px) calc(33vw - 24px), 376px ... !-- Sidebar image: fixed 300px on desktop, full-width on mobile -- img sizes(max-width: 768px) 100vw, 300px ...关键警告如果省略sizes浏览器会假定图片占视口宽度的 100%即100vw即使在窄屏移动设备上也会下载srcset中最大的候选图。因此只要使用srcset就必须提供sizes。这一无 sizes 即假设 100vw的行为在仓库的多个规则文档中反复强调例如 image-optimization 规则 同样要求 Responsive srcset and sizes attributes existimage-file-size 规则 也指出要通过 multiple srcset sizes 让移动用户下载更小文件。批量生成多尺寸变体Sharp 脚本手工裁图不现实规则文档给出了一段基于 Sharp 的生成脚本按目标宽度列表输出name-400w.ext、name-800w.ext等变体// scripts/generate-sizes.mjs import sharp from sharp import path from path const WIDTHS [400, 800, 1200, 1600] async function generateSizes(inputPath) { const { dir, name, ext } path.parse(inputPath) for (const width of WIDTHS) { const outputPath path.join(dir, ${name}-${width}w${ext}) await sharp(inputPath) .resize(width, null, { withoutEnlargement: true, // Dont upscale images smaller than the target width fit: inside, }) .toFile(outputPath) console.log(Generated: ${outputPath}) } } // Usage await generateSizes(public/images/hero.jpg)两个关键配置项withoutEnlargement: true不放大比目标宽度更小的源图避免为小图生成更大的无效文件fit: inside等比缩放保持宽高比对应于max-width/max-height语义。若不想引入脚本规则元数据中也列了替代工具 Squoosh见 规则 frontmatter 的 tools 字段可手工完成同样的多尺寸导出。用 DevTools 脚本审计超大图片规则文档提供了一段可直接粘贴到 DevTools 控制台的脚本扫描当前页面所有已加载的img比较固有宽度与实际渲染宽度考虑 DPR标记超过 2 倍超出的图片// Paste in DevTools console to find oversized images on the page const oversized Array.from(document.querySelectorAll(img)) .filter(img img.complete img.naturalWidth 0) .map(img { const rendered img.getBoundingClientRect() const dpr window.devicePixelRatio || 1 const renderedPx rendered.width * dpr return { src: img.src.split(/).pop(), intrinsic: img.naturalWidth, rendered: Math.round(renderedPx), ratio: Math.round(img.naturalWidth / renderedPx), } }) .filter(img img.ratio 2) // Flag anything more than 2x oversized console.table(oversized)脚本逻辑拆解img.complete img.naturalWidth 0只统计已加载完成、能拿到固有宽度的图片getBoundingClientRect().width × DPR换算成设备像素下的实际渲染宽度ratio 2固有宽度超过渲染宽度 2 倍即标记输出console.table便于一眼定位问题图。框架落地React 与 Next.jsReact封装一个 ResponsiveImage 组件规则文档给出了一个可复用的 React 组件把srcset的拼装逻辑收敛到一处interface ResponsiveImageProps { baseSrc: string // e.g., /images/photo ext?: string // e.g., jpg (default) alt: string sizes: string aspectRatio?: string // e.g., 16/9 widths?: number[] priority?: boolean } function ResponsiveImage({ baseSrc, ext jpg, alt, sizes, widths [400, 800, 1200, 1600], priority false, }: ResponsiveImageProps) { const srcset widths.map(w ${baseSrc}-${w}w.${ext} ${w}w).join(, ) const [maxWidth, maxHeight] [widths[widths.length - 1], undefined] return ( img src{${baseSrc}-${widths[1]}w.${ext}} srcSet{srcset} sizes{sizes} alt{alt} width{maxWidth} loading{priority ? eager : lazy} fetchPriority{priority ? high : auto} decodingasync style{{ maxWidth: 100%, height: auto }} / ) } // Usage ResponsiveImage baseSrc/images/hero extwebp altHero image sizes(max-width: 768px) 100vw, 50vw priority /组件要点默认widths [400, 800, 1200, 1600]与 Sharp 脚本的WIDTHS保持一致src兜底用widths[1]800w呼应中等尺寸兜底的建议priority控制loadingeager/lazy与fetchPriorityhigh/auto首屏图如 Hero应设priority渲染时用 CSSmax-width: 100%; height: auto自适应容器。Next.js交给 next/image在 Next.js 项目中next/image 会基于sizes自动生成并选择srcset候选开发者只需声明布局语义import Image from next/image // next/image handles srcset and sizes automatically function ProductCard({ product }) { return ( Image src{product.imageUrl} alt{product.name} width{800} height{600} // sizes tells next/image which breakpoint variants to generate sizes(max-width: 640px) 100vw, (max-width: 1280px) 50vw, 400px loadinglazy classNamew-full h-auto / ) }本仓库自身的 Next.js 应用就是这套机制的活案例apps/web/next.config.js 中配置了图片优化管线输出格式[image/avif, image/webp]、deviceSizes: [640, 828, 1200, 1920]、imageSizes: [32, 64, 128, 256]这些数组决定了next/image可生成的srcset候选集合赞助商头像组件 使用next/image的fill模式渲染固定尺寸头像并通过sizes{${size}px}精确声明渲染宽度避免100vw假设导致下载过大的候选图——这正是本规则在真实业务组件中的落地范式。与相邻规则的协同响应式尺寸并非孤立规则仓库的 relatedRules 元数据 列出了四组协同关系srcset提供多尺寸候选的机制本体picture-element需要不同裁切Art Direction时用picture的media属性按断点切换不同图源规则 Fix 步骤第 4 条即指向它image-file-size超大图片是文件体积过大的首要驱动因素dimensions两者同属images/performance区域通常一起审查——注意为响应式图片设置与最大固有尺寸匹配的width/height浏览器缩放时按比例预留空间、避免 CLS。审查与验证清单自动化检查运行 Lighthouse查看Properly size images审计给出的每张图片的潜在节省量单位 KiB在 Chrome DevTools → Elements 中悬停图片源直接查看固有尺寸intrinsic与渲染尺寸rendered的对比运行上文 DevTools 控制台脚本一次性找出当前页所有超大图片用 375px 移动端视口测试并在 Network 面板确认浏览器选择了较小的srcset候选。手动检查在具有代表性的浏览器或运行流程中手动验证渲染后的用户可见行为是否正常图片清晰度、裁切效果、懒加载表现。审查口径来自 SKILL 与规则 prompts对代码库中的每个img按以下口径逐项过检见 SKILL.md 的 Check 步骤将图片文件固有宽度与元素渲染 CSS 宽度含容器约束对比在任何常见视口下固有宽度超过渲染宽度 2 倍即标记宽度超过 200px 的图片应有srcset变体检查sizes是否如实反映实际 CSS 布局宽度。修复顺序则遵循规则文档的 Fix 五步生成 400w/800w/1200w/1600w 变体 → 添加带宽度描述符的srcset→ 添加逐断点sizes→ 需要不同裁切时改用picture→src兜底取中等尺寸800w。总结响应式尺寸是性价比极高的前端性能优化点一次srcsetsizes的改造就能让移动端用户从下载 1600px 大图降到只取所需同时改善 LCP 与带宽消耗。核心行动只有四条按需生成400/800/1200/1600w 变体Sharp 脚本或 Squoosh必写sizes否则浏览器假设100vw会前功尽弃src兜底用中等尺寸800w用 Lighthouse 与 DevTools 脚本持续审计把超大图片拦截在上线之前。【免费下载链接】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），仅供参考