Match image delivery to the places the images actually occupy. A full-resolution master is useful for future editing, but serving that master for every small card can waste transfer work. First identify display sizes, then verify the browser's chosen resource and the page's main-image loading behavior.
Label the image slots before exporting
List the hero, content image and thumbnail placements separately. Record their expected display widths on phone and desktop layouts, whether they crop the image and which subject details must remain visible. One image may need different crops as well as different resolutions.
Keep the original master out of the routine page package unless a placement genuinely requires it. Do not repeatedly compress the same derivative until it develops artifacts; create delivery candidates from the approved master and retain that source independently.
Supply variants with an implementation note
web.dev's responsive-image guide explains how srcset and sizes help browsers choose resources. The website owner must configure those declarations correctly; merely uploading three different file sizes does not make the browser select among them.
As an invented planning calculation, a hero displayed at 600 CSS pixels on a screen with a device-pixel ratio of two may benefit from a candidate around 1200 pixels wide. This is not a universal requirement or proof that the larger candidate will always be selected. The layout, browser and available resources must be checked in practice.
Worked example: an invented portfolio page
This fictional portfolio uses one 4000-pixel image for a hero and for six small project cards. The designer creates separate hero and card derivatives, then gives the developer their intended placements and crop notes. The master remains in the archive rather than becoming the default response for every card.
During review, the team records the actual image requests at two viewport widths. If the phone still downloads the 4000-pixel master for each card, the delivery setup has not changed the browser's behavior. That observation points to implementation or configuration, not to another AI generation. No speed improvement is claimed until it is measured.
Check the main image's loading path
Use the browser's network and performance tools, or a suitable external performance report, to identify the actual LCP element. Do not assume it is always the hero photograph; the measured page may identify a text block or another element.
web.dev's LCP guidance addresses early discovery and loading priority and advises against lazy-loading the LCP image. Ask the implementation owner to inspect this path. Shrinking an image helps only part of the problem if the browser discovers it late or waits for other work before requesting it.
Accept the page with observed evidence
Compare the same page under similar viewport, network and cache conditions. Record which resource was selected, how it looks at display size and what the performance tool observed. Keep dimensional layout checks separate from LCP: reserving image space can reduce layout movement, but it does not prove that the image loaded earlier.
Create artwork through Image Prompt, then export variants and configure responsive delivery externally. Hand over the image package, slot descriptions and measured review notes. The useful outcome is a clear image at an appropriate delivery cost for the actual page, without a fabricated promise of faster rankings or guaranteed traffic.