Image Weight Audit

What it does

The Image Weight Audit fetches a URL, extracts every <img> element, and reports each image’s source URL, format (PNG, JPG, WebP, AVIF, etc.), declared width and height attributes, the loading attribute (lazy or eager), and HTTP status from a HEAD check. Summary counts highlight the issues that matter — images without explicit dimensions (CLS risk), images not lazy-loaded (above the fold may be intentional, below isn’t), legacy formats (PNG/JPG instead of WebP/AVIF), and broken image references.

Common situations

A page is loading slowly and you suspect heavy images are the bottleneck. The audit lists every image with format and dimensions so you can identify the candidates for compression or format conversion. JPEGs over 200KB and PNGs of photographs are the usual suspects.

A site is failing Core Web Vitals on Largest Contentful Paint (LCP) and the LCP element is the hero image. The audit shows the hero’s format and whether it has dimensions declared (which prevents layout shift). Format conversion to WebP plus dimension attributes is often the quickest LCP win.

You have inherited a content site and want to audit which pages have images without alt-text, missing dimensions, or running on legacy formats. The audit gives a per-page snapshot; combined with the Alt Text Audit, it covers the most common image-SEO issues.

A WordPress migration moved images to a new CDN but you’re not sure if all references updated. The audit’s HTTP status column flags 404s — images still pointing at the old location.

You suspect a page-builder is not lazy-loading below-fold images. The audit shows every image’s loading attribute; pages where everything is eager (or unset) are loading content the user may never see.

What you need to know

Images are the single biggest contributor to page weight on most sites — typically 60-80% of total page bytes. Image optimisation is the single highest-leverage performance optimisation, with knock-on benefits for Core Web Vitals (LCP), bandwidth costs, and mobile UX.

The audit reports four image properties that drive both performance and SEO:

Format: modern formats (WebP, AVIF) compress 30-80% better than legacy formats (JPG, PNG) at equivalent visual quality. JPEGs are still appropriate for photography on older browsers; PNGs for graphics with transparency. AVIF and WebP cover both cases more efficiently and have universal browser support in 2026.

Dimensions (width and height attributes): these prevent Cumulative Layout Shift (CLS). Without dimensions, the browser doesn’t know how much vertical space to reserve for the image until it loads, and content below shifts when the image arrives. CLS is a Core Web Vital; pages with poor CLS rank worse. Always declare width and height even when CSS is what controls actual rendering — the attributes give the browser the aspect ratio for layout reservation.

Lazy loading (loading="lazy"): tells the browser to defer loading the image until it nears the viewport. Below-fold images especially benefit — there’s no point downloading an image the user may never scroll to. Above-fold images (especially the LCP element) should NOT be lazy-loaded — they need to start loading immediately. The pragmatic rule: hero/header images get loading="eager" (or unset, which defaults to eager); everything else gets loading="lazy".

HTTP status: 404s and other non-200 responses on images are broken references. They affect user experience (broken image icon) and SEO (Google’s image search depends on images being reachable).

What the audit doesn’t show: actual file sizes (HEAD requests don’t include the body), transfer-encoded sizes after compression, or visual quality comparisons. For exact file sizes, browser DevTools’ Network panel is the canonical source.

The 50-image cap mirrors the broken-link checker — pages with hundreds of images push past acceptable fetch volumes. For comprehensive image audits across many pages, the WP Beacon Plugin is the better tool.

Frequently asked questions

What’s the best image format for SEO?

WebP is the practical default for 2026 — universal browser support, 30%+ smaller than JPEG at equivalent quality. AVIF compresses even better (40-50% smaller than JPEG) but is slightly newer; modern browsers support it but very old browsers don’t. Use AVIF with WebP fallback for best results, or just WebP for simplicity.

Should every image have width and height attributes?

Yes — it prevents Cumulative Layout Shift. Even if CSS controls the rendered size, declaring the intrinsic dimensions in HTML lets the browser reserve space correctly. Modern frameworks usually handle this automatically; for hand-written HTML, always include width and height.

What’s the right balance between lazy loading and eager loading?

Above-fold images: eager (default). Below-fold images: lazy. The LCP element specifically should always be eager — it’s the page’s main visual and lazy-loading delays it. Below the fold, lazy is universally beneficial.

Why do I need width/height attributes if I use CSS sizing?

CSS sizing is applied after the browser has parsed and laid out the page; the layout reserves space based on attributes (or no space at all without them). Without attributes, the browser doesn’t know how tall the image will be until it loads, causing layout shift when content shifts down.

What’s a “good” image size?

Depends on use. Hero images at 1200×630 are usually 80-150KB as WebP. Inline content images at 800px wide should be 30-80KB. Anything over 200KB for a single image deserves scrutiny. Modern approaches use <picture> with multiple sources at different resolutions for responsive serving.

What’s the srcset attribute?

Tells the browser to choose between multiple image sources based on viewport size or device pixel density. srcset="hero-800.jpg 800w, hero-1600.jpg 1600w" lets the browser pick the right resolution rather than always loading the largest. Improves both performance and visual quality on high-DPI displays.

Should I optimise images on upload or on serve?

Both, ideally. Upload-time compression sets a baseline; serve-time format conversion (e.g. WordPress’s WebP plugins, or CDN-based image transforms) handles per-request format choice. The combination gets the best of both.

Are CSS background images audited too?

No — the audit reads <img> tags only. CSS background-image is invisible to the audit; for background images, browser DevTools or a Lighthouse audit is the right tool.

Common problems

Problem: Every image is reported without width/height.

The CMS isn’t declaring image dimensions. WordPress should do this automatically; if it isn’t, a plugin or theme is stripping them. Most modern frameworks (Next.js, Gatsby) have explicit image components that handle this; for vanilla setups, manual or plugin-driven dimension addition is the fix.

Problem: Hero image has loading=”lazy” and Core Web Vitals are bad.

The LCP element should never be lazy. Lazy loading delays its fetch until it’s “near the viewport” — but it IS the viewport. Set the hero to loading="eager" or fetchpriority="high" to prioritise it.

Problem: Format column shows JPEG even though I uploaded WebP.

Your CMS or CDN is serving the older format despite the upload format. Check whether image-conversion plugins are active; check the CDN’s image rewriting rules. Often the upload format is preserved but a different format is generated on serve based on browser capability.

Problem: Images are missing alt attributes everywhere.

Run the Alt Text Audit for the alt-specific report. The image-weight audit shows alt presence in passing; the alt-text audit goes deeper on classification.

Problem: Image audit shows 404 for images that work in browser.

The audit checks the image URLs as found in the page source. If your CDN is rewriting URLs at the browser level (via JavaScript) but the source HTML still has old paths, the audit reports 404s. The page works for users but bots see broken links — a real SEO issue.

Tips

• WebP for everything that doesn’t need transparency; PNG for transparency-required graphics; AVIF where you want maximum compression and can drop very old browser support.
• Declare width and height attributes on every image. CLS prevention is essentially free SEO equity.
• Lazy-load everything below the fold. Eager-load the hero / LCP element. The default loading attribute is eager — changing nothing means everything loads immediately, which is the wrong default for long pages.
• Aim for under 200KB per inline content image, under 150KB for the hero. Larger isn’t always wrong but always deserves scrutiny.
• Use srcset for responsive serving. A 1600px hero served at 1600px on mobile is 4x the bytes needed.

Related tools in this suite

The Alt Text Audit covers the alt-attribute side that this audit only reports in passing. The Page SEO Audit summarises image counts and missing-attribute counts as part of its overall report.

What this looks like at scale

For a single page, the audit is fine. For a content site, image optimisation should be a publish-time discipline — uploads compressed automatically, dimensions declared in templates, lazy loading default. The WP Beacon Plugin audits image weight, format, and lazy-loading status across an entire site over time, surfacing pages where defaults have been overridden.

Take it further

If a content site has widespread image-weight issues — large unoptimised JPEGs, missing dimensions, eager-loading defaults — the fix is at the upload pipeline plus the template layer. Talk through the audit and we can scope what site-wide image optimisation looks like.