Your AI Images Are Fine. Your Image Audit Isn't.

What NN/g actually found, and why it's not the real risk

Nielsen Norman Group ran the test everyone assumed would go the other way: show people AI-generated images next to stock photography and see if they can tell the difference, and whether it changes how much they trust the page. They couldn't tell. Even when they guessed correctly, it barely affected their trust in the surrounding content.

That result is often read as permission. If users can't spot an AI image and don't punish it when they do, the worry about "will this look fake" quietly drops off the priority list. Fair enough. But I run audits for a living, and the moment I saw that study, my first thought wasn't about trust. It was about the fact that nobody in that study was asked to wait for the page to load.

Users failing to penalize an image's origin says nothing about whether that file is dragging your Largest Contentful Paint past four seconds, or whether it lacks alt text and is invisible to a screen reader. Those technical failures don't care if DALL-E created the picture or a photographer shot it in a studio. The audit question was never "is this AI." It was always "is this file doing its job."

The real audit doesn't care where the image came from

Here is what I actually check when an image gets flagged in a Lighthouse report. None of it involves asking where the pixels originated.

Payload: the first number that matters

Open DevTools, go to the Network tab, filter by Img, and sort by size. Any single image over 200 KB on a typical content page is a candidate for compression, and a hero or LCP image over 300 KB almost guarantees a performance penalty. I have seen AI-generated hero images saved straight from a generator at 4 to 6 MB because nobody thought to run them through a compressor before uploading them. Stock photos get this wrong just as often. The file size is the problem, not the origin.

Format: are you still shipping JPEG in 2026

AVIF typically cuts file size by 50% compared to a JPEG of equivalent visual quality. WebP gets you 25% to 35% savings over JPEG, with near-universal browser support today. If your audit shows images served as .png or .jpg at full resolution, you have an immediate, low-effort fix: re-export in WebP or AVIF with a JPEG fallback, and the payload problem often resolves itself before you touch anything else.

Lazy loading: priority where it counts, deferred everywhere else

Every image below the fold should carry `loading="lazy"`. Every image that serves as your LCP element, almost always the hero image, should never be lazy-loaded; it needs `fetchpriority="high"` so the browser fetches it immediately instead of discovering it late in the render cycle. I verify this by checking the Network waterfall: if your hero image loads after six other requests, your priorities are backwards.

Dimensions: the layout shift nobody notices until it's measured

Missing `width` and `height` attributes are the single most common cause of Cumulative Layout Shift I find in client audits. Because the browser does not know how much space to reserve, it paints the surrounding text first, then reflows the layout once the image arrives. A CLS score above 0.1 is the threshold where Google starts penalizing your site, and I can usually trace that shift back to two or three images missing explicit dimensions.

Alt text: the thing no generator writes for you

This is where AI images genuinely create a distinct failure mode, just not the one people worry about. A photographer captions what they shot. A generator gives you a filename like `generated-image-4f2a.png` and nothing else. If you have been dropping AI images into a CMS without writing alt text manually, you have introduced a real accessibility barrier: not because the image is artificial, but because nobody described it. WCAG 2.1 requires meaningful alt text for every non-decorative image, and screen reader users should never be skipped simply because an asset came from an AI prompt.

How to actually run this check on your own site

Pick your five highest-traffic pages. For each one: open DevTools, filter images by size, and flag anything over 200 KB. Check whether the LCP image, visible in the Lighthouse Performance panel, is lazy-loaded (it shouldn't be) or missing explicit dimensions (it needs them). Then open your CMS and spot-check the alt text across those same five pages. You will usually find the same two or three issues repeating across the entire site. Fixing them at the source, in your image pipeline or your CMS template, resolves the problem across dozens of pages at once.

The takeaway for whoever owns the image pipeline

The NN/g findings are good news if you were losing sleep over whether AI images would make your site look cheap or untrustworthy. They won't, at least not for that reason. But that data does not let anyone off the hook for a technical audit. This is the exact pass theuxbites runs on every image across a site: payload, format, loading strategy, dimensions, and alt text, aggregated into a prioritized list instead of a raw Lighthouse score nobody has time to decode. Whether an asset came from a camera or a prompt, the file still has to earn its place on the page.