vibecheck0.3.0
Performancelarge-imageserror

Large image files in Vanilla 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
GeneralNext.jsVueVanilla JS

Symptoms

  • One image is several hundred KB to multiple MB in the Network panel
  • Slow LCP (Largest Contentful Paint), especially on mobile
  • A PNG used where a compressed WebP/AVIF would be a fraction of the size
  • The hero takes a visible beat to appear on a throttled connection

How VibeCheck catches it

In your widget · Problems

errorlarge-imagesLarge 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

  • Uncompressed PNG/JPEG exported straight from a design tool
  • A full-resolution original served where a resized copy would do
  • No modern format (WebP/AVIF), which compress far better than PNG/JPEG
  • No image CDN doing on-the-fly compression and format negotiation

The fix for Vanilla JS

Pre-compress with sharp/squoosh in your build, then serve AVIF/WebP with a <picture> fallback. Or put an image CDN in front and pass width/format query params.

bash
# one-off or in your build step
npx @squoosh/cli --avif '{"quality":75}' hero.png

Steps

  1. Resize the source to at most 2× the size it’s displayed at
  2. Re-encode to AVIF/WebP with a quality around 75–80
  3. Serve via <picture> with fallbacks, or through an image CDN

See the general, framework-agnostic fix →

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.