Large image files in Next.js
A single unoptimized hero image can be heavier than all your JavaScript combined, and it usually sits right in the critical path as the LCP element — so a fat image directly slows the metric Google measures your loading speed on. On mobile data it’s money out of the user’s pocket. AI-built pages routinely embed full-resolution PNGs and un-compressed exports.
Framework fixes
Symptoms
How VibeCheck catches it
In your widget · Problems
Large image: 512KB
To your coding agent · MCP
agent › get_detected_issues
→ { detector: "large-images", issue: "Large image: 512KB", threshold: "≥ 500KB transferred (warning), ≥ 1,024KB (error) — measured via Resource Timing" }
The same string in your widget and in your agent’s context — no screenshot, no copy-paste.
Root causes
The fix for Next.js
next/image compresses and converts to AVIF/WebP automatically and serves per-device sizes — pointing it at a large source and letting it optimize is usually the whole fix.
import Image from 'next/image'
// Next generates optimized AVIF/WebP variants at request time.
<Image src="/hero-original.png" width={800} height={450} alt="Hero" />Steps
- Resize the source to at most 2× the size it’s displayed at
- Re-encode to AVIF/WebP with a quality around 75–80
- Serve via
<picture>with fallbacks, or through an image CDN
FAQ
- What image size is acceptable?
- Aim to keep individual images well under 200KB where you can. VibeCheck warns at 500KB and errors at 1MB — past that you’re almost certainly serving an un-resized or un-compressed original.
- AVIF or WebP?
- AVIF compresses better but encodes slower and has slightly less universal support; WebP is faster and near-universal. Offer AVIF first with a WebP (then JPEG) fallback via
<picture>, and you get the best of both. - Does this affect SEO?
- Yes, indirectly — a heavy hero image usually is your LCP element, and LCP is a Core Web Vital Google uses in ranking. Lighter images mean a faster LCP and a better page-experience signal.