A preload should make an important resource available early. If it identifies a different file from the eventual image, it can create extra traffic. Similar filenames do not establish that the browser will reuse the request.
Compare complete network addresses, including query strings. /hero.webp?width=1200 and /hero.webp?width=800 are different URLs.
Match the selected image candidate
For responsive images, the browser may choose a candidate different from a fixed preload address. Supported image-candidate and sizing attributes can describe responsive preloads, but they must match actual image output. Adding another generic preload for every image is not a solution.
Record a controlled comparison:
View: narrow product hero
Preload URL: which complete address?
Image currentSrc: which complete address?
Network: a reused request or an additional unused resource?
Inspect request mode, CORS settings and file type too. Removing an unnecessary preload may be preferable when initial HTML already exposes the image early. Choose the change from evidence.
Repeat the same view with a fresh cache after the correction, then test a wider display and another pixel density. Fewer requests are useful only if the intended image still appears correctly and promptly. Record viewport width and pixel density for the comparison.