Next.js

Verified against Claude Code · 2026-07-29

Audit a page for next/image misuse before Lighthouse catches it

Scans a page's images for missing priority hints, wrong fill/dimension usage, and un-allow-listed remote domains — the specific mistakes that quietly tank LCP and CLS without erroring at build time.

Claude CodeCursorGitHub Copilot3 fillable variables

The prompt

Ready to copy — highlighted parts are example details you can swap.

You are auditing every image on a specific page for next/image correctness, checking for the mistakes that hurt Core Web Vitals or fail silently in production without ever showing up as a build error.

PAGE OR COMPONENT CODE
app/blog/[slug]/page.tsx — a hero image plus several inline images inside the post body

EXTERNAL IMAGE DOMAINS
images.ctfassets.net (Contentful), cdn.example-cms.com

LAYOUT BREAKPOINTS
Hero image is full-width on mobile, roughly 60% width on tablet, and capped at 800px on desktop

CHECKLIST
Flag every plain img tag used for a content image, recommending conversion to next/image, unless there's a specific reason not to — an SVG icon, or an image whose dimensions genuinely can't be known ahead of time — and name that reason explicitly if you're leaving one as-is rather than silently skipping it. Identify the largest above-the-fold image, the likely LCP element, and confirm it has priority set to disable lazy loading; if it's currently lazy-loaded by default because priority is missing, flag that as a direct LCP regression at high severity, not a minor style note. Confirm every other next/image usage on the page does NOT have priority set — marking every image priority defeats the entire point of lazy loading and front-loads bandwidth for images the user may never actually scroll down to see. For any image using the fill prop, confirm its parent element has a defined position (relative or similar) and defined dimensions; fill combined with an unsized or statically-positioned parent causes the image to collapse to zero height or overflow its container unpredictably. For any image using explicit width and height instead of fill, confirm those values match, or are proportional to, the actual source image's real aspect ratio — mismatched dimensions cause either a distorted image or a layout shift the moment the real image loads and the browser reserves space based on values that don't match what actually renders. For any image sourced from an external domain, confirm that domain is listed in next.config's images.remotePatterns; flag any that aren't, since an un-allow-listed domain fails at request time in production, not at build time, meaning this specific mistake passes every local check and every CI build cleanly and only surfaces after deploy when a real request to that image actually gets made. For any image that resizes significantly across the breakpoints given above, confirm a sizes attribute is set so the browser downloads an appropriately sized file at each breakpoint rather than the largest variant everywhere regardless of how small the image actually renders on a given screen.

OUTPUT FORMAT
A findings table: Image or location | Issue | Severity — LCP-impacting, CLS-impacting, will-fail-in-prod, or minor | Fix.

Customize

Optional — swap in your own details for the highlighted parts above.

Why this works

Most next/image mistakes are invisible in local development and only show up in a Lighthouse report or a production error weeks later, which is exactly why a targeted checklist beats a general "optimize my images" request: the priority-on-the-LCP-image rule catches a lazy-loaded hero image that's actively hurting the LCP score in a way that renders correctly and looks fine to the eye, the fill-needs-a-sized-relative-parent rule catches a collapse bug that only appears at certain viewport widths rather than in the specific one the developer happened to test in, and the remotePatterns check catches a failure mode that genuinely doesn't exist at build time at all — an un-allow-listed external domain builds and deploys successfully, and only fails the first time a real request actually hits that specific image URL in production, which can be days after deploy if that image happens to sit below the fold on a low-traffic page. Distinguishing "every image should have priority" from "exactly the LCP image should" matters because the naive, well-intentioned fix — add priority everywhere, on the theory that faster-loading images are always better — removes the lazy-loading benefit for every image below the fold simultaneously, trading one measurable performance problem for a different and often worse one: a page that now front-loads bandwidth for images most visitors will never scroll far enough to see, which shows up as a slower initial load rather than a faster one. Checking the sizes attribute against actual layout breakpoints, rather than treating it as an optional detail, closes a gap that's easy to miss because the image still displays correctly without it — without sizes, the browser has no signal about how large the image will actually render at each breakpoint, so it downloads the largest configured variant even on a narrow mobile viewport where a much smaller file would have looked identical, a waste that never shows up as a visible bug, only as unnecessary bytes on every mobile page load.

What you get back

Hero image at app/blog/[slug]/page.tsx line 14: plain <img> tag, no priority equivalent, and it's the likely LCP element for this page — convert to next/image with priority set. Severity: LCP-impacting. Inline post-body images: correctly using next/image, but sourced from cdn.example-cms.com, which is not listed in images.remotePatterns — will build and deploy successfully but fail at request time in production the first time a real image request hits that domain. Severity: will-fail-in-prod. Hero image sizing: no sizes attribute set despite resizing from full-width on mobile to 800px on desktop — currently downloads the desktop-sized file even on mobile viewports. Severity: minor (bandwidth waste, not a layout or LCP break).

Verified against

Claude Code Sonnet 4.6 · 2026-07-29

Cursor Cursor 2.1 · 2026-08-05

Changelog

  • 2026-07-29 Initial publish, verified against Claude Code (Sonnet 4.6) and Cursor 2.1 on a Next.js 16 blog with a CMS-hosted image domain.
Pairs with our free Website Speed Test — no signup, runs in your browser.

Need this built into your business?

If a prompt isn't enough — custom software, built and maintained for you — that's Scult's day job.

EXPLORE CUSTOM SOFTWARE
All Next.js prompts

Check your AI visibility

One URL in, a 0–100 score and the exact fixes out.

RUN THE CHECK

Browse all the tools

15 tools across six categories
13 of them never send your data anywhere

Free · No signup · No trial clock

SEE THE DIRECTORY