Image optimization
Making images cheap to load and legible as text — the two independent jobs, why only the second one survives into an AI answer, and where each fails.
Karl-Gustav Kallasmaa, Founder & CEOLast updated Image optimization is the practice of making the images on a page cheap to load and legible to a machine — two jobs that share a name and almost nothing else. The first is a bytes-and-timing problem measured in milliseconds. The second is a text problem, and it is the one that decides whether an image contributes anything to an answer written about your page.
Conflating them is why sites compress diligently for years and still have images that no retrieval system can say anything about.
Job one: the bytes
Images are usually the largest single contributor to page weight, which makes them the usual cause of a slow first render. Google's own framing is that images "are often the largest contributor to overall page size, which can make pages slow and expensive to load."
The metric that judges this is Largest Contentful Paint, and when the biggest element in the initial viewport is an image — a hero, a product shot, a diagram — LCP is that image's load time. Google's published target is an LCP of 2.5 seconds or less, assessed at the 75th percentile of page loads and segmented across mobile and desktop. The percentile is the part people skip: a fast median with a slow tail fails, because the 75th percentile is where the tail is being read.
Practically this means: serve a modern format, size the file to the box it renders in, give the element explicit dimensions so layout does not shift, and do not lazy-load the image that is the LCP element — deferring it defers the metric. See Core Web Vitals.
Job two: the text
An image that loads instantly and describes nothing is invisible to everything downstream of retrieval.
A retrieval-and-generation system selects passages of text, embeds them, and writes from them. The parts of an image that participate in that are its alt text, its filename, its caption, and the prose immediately around it. Google's guidance on alt text is to "focus on creating useful, information-rich content that uses keywords appropriately and is in context of the content of the page," and it warns that stuffing keywords into alt attributes "results in a negative user experience and may cause your site to be seen as spam." Its filename guidance is equally plain: "Use filenames that are short, but descriptive. For example, my-new-black-kitten.jpg is better than IMG00023.JPG."
Two mechanical constraints sit underneath.
Discoverability. Google supports images referenced in the src attribute of an img element, in seven formats — BMP, GIF, JPEG, PNG, WebP, SVG and AVIF. CSS background images are not indexed. If you use <picture> or srcset, Google's guidance is to always specify a fallback URL in src. Anything a crawler must execute JavaScript to reach is at best a maybe, which is why Google offers an image sitemap extension for images "we might not have otherwise discovered (such as images your site reaches with JavaScript code)" — up to 1,000 <image:image> entries per URL.
Stability. Google asks you to "consistently reference the image with the same URL, so that Google can cache and reuse the image without needing to request it multiple times." Build pipelines that hash every asset on every deploy quietly break this.
Why an agent cares about your images
It mostly does not — and that is the point worth internalising.
A model answering a question about your product is working from text it retrieved. A chart is the most information-dense object on many pages and contributes zero to that answer unless its content also exists as words. The fix is not more alt text; it is writing the finding the chart shows into a sentence next to the chart. If a diagram is the only place a number appears, that number does not exist for citation purposes.
The same logic applies to screenshots of pricing, of configuration, of code. An image of text is not text.
Failure modes
- Optimising bytes and stopping. A perfectly compressed, perfectly nameless image is fast and mute.
- Lazy-loading the LCP image. Deferring the largest above-the-fold image makes the metric it defines worse, not better.
- CSS background images for content. Decorative backgrounds are fine; a content image placed as a background is not indexed.
- Alt text written for a keyword. Google names stuffed alt attributes as a spam signal, and a stuffed attribute also fails the accessibility job it exists for.
- Text that lives only in a picture. Numbers, quotes and steps trapped in a screenshot are unreachable by retrieval, uncopyable by a reader, and unreadable by a screen reader.
- Hashing every URL on every build. No cache reuse, no stable reference, no accumulated history for the asset.
- Missing dimensions. Width and height on the element prevent layout shift; omitting them turns a fast image into a janky one.
Terms related to Image optimization
Google's three published field metrics for loading, responsiveness and visual stability, with the exact thresholds and the percentile they are judged at.
The two separate stages that decide whether a page can be retrieved at all, and the reason a serving rule on a blocked page is never read.
A machine-readable list of the URLs you want discovered, bounded by the protocol at 50,000 URLs and 50MB per file, and a hint rather than an instruction.
The Schema.org vocabulary and the JSON-LD you embed with it, what it is genuinely good for, and the limits of what it can make happen.