Use when auditing the image pipeline, static assets in `public/`, CMS-managed media, or image CDN transforms. Separate file-size problems from dimension mismatches so you can tell whether the issue is compression, format choice, or responsive delivery.
インストールする前に、エージェントに与えられる指示の中身を確認できます。
Images account for over 50% of average page weight according to HTTP Archive data. Oversized images waste user bandwidth (costly on mobile data plans), delay Largest Contentful Paint (LCP), and increase bounce rates. A 1-second delay in mobile page load can reduce conversions by up to 20% according to Google research.
Audit all image assets in this project. For each image: 1) Check the file size in bytes. 2) Flag any photo (JPEG/WebP/AVIF) over 200KB. 3) Flag any graphic/icon (PNG/SVG) over 100KB. 4) Flag any hero or full-width image over 400KB. 5) Flag any thumbnail (under 200px wide) over 30KB. Also check if Lighthouse reports 'Properly size images' or 'Efficiently encode images' as opportunities. Report each oversized image with its path, current size, and an estimated target size.
For each oversized image: 1) Convert JPEG/PNG to WebP at 80% quality using Squoosh, Sharp, or ImageOptim—this typically yields 25-35% size reduction over optimised JPEG. 2) Try AVIF at 60% quality for further reduction (often 40-50% smaller than JPEG). 3) Strip metadata (EXIF/IPTC) from images served on the web. 4) For PNGs, run through oxipng or pngquant for lossless or near-lossless compression. 5) For SVGs, run through SVGO. 6) Implement multiple srcset sizes so mobile users download smaller files.
Explain how oversized images impact web performance. Images are typically the largest assets on a page—HTTP Archive data consistently shows images account for 40-60% of total page weight. Each KB saved reduces transfer time, especially on mobile networks (4G averages 20Mbps, with significant latency). Large images also delay Largest Contentful Paint (LCP), the primary Core Web Vitals metric. Google's Lighthouse flags images that could be reduced by more than 4KB as an opportunity.
Inspect image assets, build transforms, CMS output, and rendered markup. Flag photos above the documented file-size thresholds, hero images that exceed budget without justification, and image pipelines that ship original uploads instead of compressed responsive variants.
For full implementation details, code examples, and framework-specific guidance,
see references/rule.md.
Rule page: https://frontendchecklist.io/rules/images/image-file-size
まだレビューはありません。使ってみた感想をお寄せください。
概要と使いどころ
Use when reviewing templates, rendered HTML, or shared components related to Create a custom 404 error page. Validate the final browser-facing markup, not just the source framework abstraction.
日本語の概要は準備中です。原文の説明を表示しています。
Use when auditing metadata, crawlability, structured data, or indexability related to Create a dedicated About page. Verify the rendered HTML and HTTP response rather than relying only on source files.
日本語の概要は準備中です。原文の説明を表示しています。
Use when reviewing component libraries, page flows, or CI pipelines that need repeatable accessibility checks. Automated testing is strongest at catching structural and attribute-level issues; it does not replace keyboard, screen reader, and manual UX testing.
日本語の概要は準備中です。原文の説明を表示しています。
Use when reviewing sign-in, sign-up, MFA, CAPTCHA, recovery, and re-auth flows. Evaluate the full authentication path, including error handling and backup methods, not just the primary login form.
日本語の概要は準備中です。原文の説明を表示しています。
Use when reviewing templates, rendered HTML, or shared components related to Make notifications accessible. Validate the final browser-facing markup, not just the source framework abstraction.
日本語の概要は準備中です。原文の説明を表示しています。
Use when reviewing rendered HTML, interactive components, or design-system patterns related to Use semantic table markup for screen readers. Check native semantics first, then inspect keyboard behavior, focus flow, accessible names, and screen-reader output where relevant.
日本語の概要は準備中です。原文の説明を表示しています。