28 October 2026 · wevisualise

Image SEO & Alt Text: The Fix Most Sites Skip

Images are the heaviest thing on a typical web page and the part nobody owns. They slow your site, they carry an accessibility obligation, and they are the one asset most teams upload straight from a phone without looking. This covers alt text, file naming, formats, sizing and lazy loading, with measured before and after file sizes.

Why images are the largest thing on your page

The HTTP Archive Web Almanac measured page composition across the web in July 2025 and published the breakdown. For the median desktop home page, images accounted for 1,058 KB out of a total 2,862 KB. JavaScript came second at 697 KB, then fonts at 139 KB, CSS at 82 KB and HTML at 22 KB. On mobile the pattern held: 911 KB of images inside a 2,559 KB median page.

The Almanac states it plainly: "Images accounted for the most bytes on both mobile and desktop, followed by JavaScript and fonts." It also records that the median home page grew 7.8 per cent year on year to 2.7 MB.

So images are roughly a third of the weight of a normal page, and the weight is going up. They are also, unlike JavaScript, something a marketing team can fix without a developer. That combination is why this is the highest return per hour of technical work available to most businesses.

Writing alt text that does its job

Alt text serves two masters and the guidance from each is compatible.

Google's image SEO documentation calls the alt attribute "the most important attribute when it comes to providing more metadata for an image", and gives graded examples. It labels alt="puppy" as better and alt="Dalmatian puppy playing fetch" as best. It labels a missing alt attribute and keyword-stuffed alt text as bad, warning that stuffing "results in a negative user experience and may cause your site to be seen as spam."

The accessibility requirement is a legal standard rather than a preference. WCAG Success Criterion 1.1.1, Non-text Content, is a Level A criterion and states: "All non-text content that is presented to the user has a text alternative that serves the equivalent purpose, except for the situations listed below."

The W3C's Web Accessibility Initiative publishes a decision tree that resolves nearly every real case:

Informative images, a photograph or graphic that carries meaning. Use "a brief description of the image in a way that conveys that meaning in the alt attribute."
Functional images, an image inside a link or button. Use the alt attribute "to communicate the destination of the link or action taken", not to describe the picture.
Images of text, where the words appear nowhere else. Include the text of the image in the alt attribute.
Complex images, charts and diagrams. Do not compress the whole thing into alt text. Include the information "elsewhere on the page."
Decorative images, covered below.

The most common mistake in practice is category two. A logo linking to the homepage takes alt="wevisualise home", not alt="company logo". Describe the job, not the artwork.

The decorative image case

This is where most sites get it exactly backwards, filling every attribute with keywords because a plugin flagged them empty.

The W3C decision tree is unambiguous for decorative images: "Use an empty alt attribute." That means alt="", present and deliberately blank. WCAG's understanding document explains why: "If non-text content is pure decoration, is used only for visual formatting, or is not presented to users, then it is implemented in a way that it can be ignored by assistive technology."

A background texture, a divider flourish, a stock photo repeating what the adjacent heading already says: all of these take alt="". A screen reader then skips them silently instead of reading out a keyword list. An empty alt is a correct answer, not a missing one.

File names, captions & the context around the image

Google's image documentation is specific about filenames: "my-new-black-kitten.jpg is better than IMG00023.JPG." Generic names such as image1.jpg carry nothing.

It also states that "Google extracts information about the subject matter of the image from the content of the page, including captions and image titles", and advises placing images near relevant text on pages relevant to the subject. Practically, an image dropped into a gallery grid with no surrounding prose has less to work with than the same image sat beside a paragraph that explains it.

Google Search supports BMP, GIF, JPEG, PNG, WebP, SVG and AVIF in the src attribute of an img element. If you publish a lot of images, an image sitemap helps, and Google notes you can include URLs from other domains in the image:loc elements, which matters if you serve from a content delivery network.

Formats & compression, in that order

Two levers reduce file size, and the order matters because the first is worth far more than the second.

The first is dimensions. Most sites serve a 4,000 pixel wide photograph into a container 800 pixels wide. Resizing to the size actually needed does most of the work.

The second is format. web.dev's image performance guidance describes WebP as "a widely supported format that works on all modern browsers" that "often has better compression than JPEG, PNG, or GIF." On AVIF it notes that "tests have shown greater than 50% savings when compared to JPEG in some cases."

Do them in that order. Compressing a 4,000 pixel image into AVIF still ships four times more pixels than the layout can display.

A worked example, before & after

Measured on a 4,032 by 3,024 photograph encoded at JPEG quality 95, which is what a current phone camera produces:

Stage	Dimensions	Format & quality	File size	Reduction from original
As uploaded	4032 x 3024	JPEG q95	4,791 KB	none
Resized only	1600 x 1200	JPEG q80	346 KB	93 per cent
Resized and converted	1600 x 1200	WebP q80	257 KB	95 per cent
Resized and converted	1600 x 1200	AVIF	162 KB	97 per cent
Mobile variant	800 x 600	AVIF	51 KB	99 per cent

Read the second row before anything else. Resizing alone took 4,791 KB down to 346 KB. That single step, which any team can do before upload, accounts for the overwhelming majority of the saving. Moving from JPEG to AVIF then halved what was left, from 346 KB to 162 KB, which matches the direction web.dev describes.

Now scale it. A page carrying eight images at camera resolution is shipping roughly 38 MB. The same page with the resized AVIF versions ships around 1.3 MB. That is the difference between a page that fails on a mobile connection and one that does not, and it took no development work at all.

Responsive images & stated dimensions

Serving one file to every device wastes bandwidth on phones and looks soft on retina displays. The srcset attribute solves it by offering the browser several candidates with width descriptors, alongside a sizes attribute that, in web.dev's words, "expresses which candidate specified in an img element's srcset should be loaded, given the dimensions of the user's current viewport."

Google's guidance adds one requirement: "make sure that you provide an img element as a fallback with a src attribute." The srcset is an enhancement, not a replacement.

Account for device pixel ratio when you pick sizes. web.dev's example is direct: an image displayed in a 500 by 500 container on a device with a pixel ratio of 2 needs to be "a square 1000 pixel image" to look sharp.

Then state dimensions on every image. web.dev recommends "adding width and height attributes to all <img> tags" so the browser can reserve space before the file arrives. Omitting them is the single most common cause of a failing Cumulative Layout Shift score, where the threshold published on web.dev is 0.1 or less.

Lazy loading & the Largest Contentful Paint trap

Browser level lazy loading is one attribute, loading="lazy", supported in Chrome from version 77, Edge from 79, Firefox from 75 and Safari from 15.4. It defers off-screen images until the user scrolls near them.

It is also the most reliably misapplied performance tactic in the field, because it usually gets switched on site wide.

web.dev's warning is explicit: "Don't lazy-load images that are likely to be in-viewport when the page loads, especially LCP images." And: "Use loading=lazy only for images outside the initial viewport. The browser can't lazy-load an image until it knows where the image should be on the page, which causes them to load more slowly."

This matters because of what Largest Contentful Paint measures. web.dev defines it as reporting "the render time of the largest image, text block, or video visible in the viewport, relative to when the user first navigated to the page." On most marketing pages that largest element is the hero image. Lazy load it and you have delayed the exact thing the metric is timing.

The thresholds are worth having in front of you. web.dev states that sites "should strive to have Largest Contentful Paint of 2.5 seconds or less", an Interaction to Next Paint of 200 milliseconds or less, and a Cumulative Layout Shift of 0.1 or less, assessed at the 75th percentile of page loads and segmented across mobile and desktop.

The rule reduces to one sentence. Everything below the fold gets loading="lazy". The hero does not.

What to do next

Run your homepage and two top service pages through a page weight check and note the image bytes. If images are over 1 MB per page, you have found your fastest win.
Inspect the hero image on your most important page and confirm it does not carry loading="lazy". Fix it today if it does.
Set an upload standard for whoever adds images: maximum 1,600 pixels wide for full-width use, exported as WebP or AVIF, named descriptively before upload.
Audit alt text on your top ten pages against the four categories. Give decorative images alt="" and give linked images text describing where the link goes.
Check that every image tag carries width and height attributes, then re-measure Cumulative Layout Shift a fortnight later.

Points two, three and four cost an afternoon and need no developer. When the work runs into templates, a content delivery network configuration or a Core Web Vitals score that will not move, our SEO work takes it from there.