Four things a scan finds wrong with the images on your homepage

Images are usually the heaviest thing on a homepage, and the hero is often the single largest file the browser fetches. When a scan reads your homepage, the image checks are where findings pile up.

The four problems below show up on site after site. None of them need a redesign. Each one is an attribute, a wrapper element, or a file conversion, and each one changes something your visitor can feel.

How the image checks work

A scan fetches your homepage HTML and reads every <img> tag: the src, the loading attribute, the width and height attributes, and whether the tag sits inside a <picture> element. It also pulls Core Web Vitals through Google's PageSpeed Insights, so each markup finding can be tied to what happened on a timed load.

That is why image findings arrive in pairs. The markup check says "these images have no width or height." The field data says "the layout shifted." Same cause, seen from two sides.

One: images with no width and height

Open your homepage source and look at the <img> tags. If most carry only a src and an alt, you have the most common image finding there is.

What the visitor experiences: the page paints, text appears, and then the images arrive and shove everything down. A headline moves. A button moves. On a phone, the thing the visitor was about to tap is no longer under their thumb. That jump is Cumulative Layout Shift, one of the three Core Web Vitals.

Without dimensions, the browser has no idea how tall an image will be until the file arrives, so it reserves zero space. With width and height set, the browser computes the aspect ratio before the download starts and holds the box open. Google's guidance on optimizing CLS lists this as the first fix for a reason.

What to do:

• Add width and height to every <img>, using the image's real pixel dimensions. CSS can still scale it. The attributes only set the ratio.
• Keep height: auto in your CSS so the image stays responsive.

A scan flags this when more than two images on the page are missing either attribute. On most homepages the fix is one pass through a template, because the tags come from a theme or component that renders them all the same way.

Two: nothing below the fold is lazy loaded

Scroll your homepage to the bottom and count the images: team photos, logos, testimonial headshots, a footer banner. Your visitor saw none of them in the first second. Yet by default the browser downloads all of them the moment the page starts loading.

What the visitor experiences: on a fast desktop connection, not much. On a phone on a cellular network, every off-screen image competes with the hero, the fonts, and the stylesheet for the same narrow pipe. The top of the page settles later because the bottom is being fetched at the same time.

The fix is a single attribute. loading="lazy" tells the browser to defer the download until the image is near the viewport. The MDN reference for the img element covers the exact behavior.

What to do:

• Add loading="lazy" to every image that is not visible on first load: below-the-fold content, carousel slides past the first, footer graphics.
• Pair it with the width and height fix above. A lazy image with no dimensions still shifts the layout when it loads.
• On a content management system, check whether the platform already does this. Older themes and page builders often override it.

A scan flags this when a page has more than three images and not one uses lazy loading. That pattern almost always means no one has ever set it.

Three: the hero image is treated like everything else

This is the mirror of the previous problem, and just as common. Once a team learns about lazy loading, the next mistake is to apply it everywhere, including the one image that must show up first.

What the visitor experiences: the page frame appears, the navigation appears, and the hero area sits empty. The largest thing on the screen is the last thing to arrive. That delay is Largest Contentful Paint, the second Core Web Vital, and on most homepages the LCP element is the hero image.

Lazy loading the hero makes it worse. The browser waits to discover the image, waits to confirm it is near the viewport, and only then starts the download. A scan that pulls PageSpeed data shows which element took longest to paint. If it names your hero, these are the fixes.

What to do:

• Remove loading="lazy" from the hero. Eager is the default when the attribute is absent.
• Add fetchpriority="high" so the browser moves the hero ahead of other images. Google's explainer on fetch priority shows the measured LCP gains from this one attribute.
• If the hero is a CSS background image, preload it with a <link rel="preload" as="image"> tag, since the browser cannot discover a CSS background until the stylesheet is parsed.

The rule in one line: eager and high priority above the fold, lazy below it. Most homepages get one half right.

Four: JPG and PNG with no modern alternative

Look at the file extensions on your homepage images. If they are all .jpg and .png, you are sending more bytes than you need to. WebP and AVIF encode the same picture at the same visual quality in a noticeably smaller file, and every current browser supports both.

What the visitor experiences: nothing they can point to, which is exactly the problem. Every image takes a little longer than it should, on every visit. On a weak signal that adds up to a page that feels sluggish with no single obvious cause.

What to do:

• Convert with a build step or an image pipeline. Most frameworks and content management systems have a plugin or image component that outputs WebP automatically.
• If you serve from a CDN, check for an automatic format option. Many serve WebP or AVIF to browsers that accept it without touching your source files.
• For hand-managed sites, wrap the image in a <picture> element with a WebP <source> first and the original JPG as the fallback <img>.

That last pattern matters for how the check behaves. A careful scan does not flag a JPG simply because its src ends in .jpg. It looks at the parent element first. If the <img> sits inside a <picture> that offers a source of type image/webp or image/avif, the browser will pick the modern file and the JPG is only a fallback. Flagging that would be a false positive, so the scan skips it. The finding fires only when more than two images have an old format and no modern alternative, and it lists the specific file paths so you know which ones to convert.

So you can clear the finding without touching your source images. Keep the JPG, add the WebP alongside it, and wrap both in a <picture>.

Where to check next

Images rarely travel alone. The same theme that renders an <img> with no dimensions is often the one loading a synchronous script in the head, covered in the post on render-blocking scripts. Alt text, the accessibility side of images, is a separate set of checks.

You can run all four checks by hand: view source, search for <img, and inspect each tag for the attributes above. On a homepage with forty images that takes a while, and you still need PageSpeed data to see which element delayed your LCP.

The AcuityScan performance tool does the pass for you. It counts images missing dimensions, reports whether any use lazy loading, lists the files still in JPG or PNG with no modern source, and pulls desktop and mobile Core Web Vitals so the markup findings sit next to measured LCP and CLS. The accessibility check handles alt text.

For the full picture, run a complete scan at acuityscan.com. It runs 350+ checks across 8 modules and returns findings with the specific image paths and plain-English fixes, so you know which tags to change and why.

TL;DR

• Missing width and height attributes cause layout shift. Add the real pixel dimensions to every <img>.
• Images below the fold should carry loading="lazy" so they stop competing with the hero on first load.
• The hero itself should be eager, with fetchpriority="high". Lazy loading the LCP element makes it arrive last.
• JPG and PNG with no WebP or AVIF alternative cost bytes on every visit. Convert, or wrap in a <picture> with a modern <source>, the pattern a careful scan recognizes and skips.