Skip to main content
Your largest image — the hero — should load the instant the page parses, before any script runs. Autorender Native measures and requests images from JavaScript, so it always starts a fraction later than the browser’s own preload scanner. For the single Largest Contentful Paint element, hand-build the delivery URL instead of marking it, so the browser fetches it during HTML parsing.

​
Why can’t Native preload the hero?

The browser’s preload scanner reads the raw HTML and starts fetching images before scripts execute. It looks at src and srcset, not data-ar-src. An element marked with data-ar-src has no source at parse time, so the scanner skips it and the fetch waits for the runtime. data-ar-eager skips lazy loading, but it does not fix this — the source still appears only after the script runs. With debug=1 an eager image with no parse-time source logs:
So for the LCP image, and only that image, skip Native and set a real source the scanner can see.

​
Build and preload the hero

The runtime ignores any <img> without data-ar-src, so a hand-built hero coexists with marked images on the same page — no double fetch.
1

Pick a delivery width.

Multiply the hero’s rendered CSS width by the device pixel ratio you want to serve, then cap the result at the image’s real source width. You are building this URL by hand, so the runtime’s max-dpr does not apply. A hero rendered at 1600 px and served at 2× asks for 3200 px; if the source is only 2400 px wide, cap it there and request w_2400.
2

Build the delivery URL by hand.

Use the standard URL anatomy — delivery domain, workspace ID, transforms, source path:
3

Preload it in the head with high priority.

4

Use the same URL as a real src — no data-ar-src.

Because there is no data-ar-src, the runtime leaves this element alone. The browser reuses the preloaded fetch only when the <link> and the <img> match exactly — identical href, and crossorigin set on neither or on both. Any mismatch downloads your largest image twice, the exact failure this page exists to prevent.
Do not put both data-ar-src and a real src on the hero. The browser fetches the real src in full during parsing, then the runtime overwrites it with its own variant — two downloads of your largest image. Either hand-build the hero (this page) or mark it and accept the later, script-driven fetch.

​
Mark the rest of the page normally

Every image below the fold stays on the data-ar-src path. Only the LCP element needs the hand-built treatment.

​
What if JavaScript is disabled?

A marked <img> has no source until the runtime runs, so it shows nothing when JavaScript is off. Give any image you cannot afford to lose a <noscript> fallback with a hand-built URL:
The hand-built hero needs no <noscript> — it already has a real src that works without the runtime.

​
Next steps

Attributes

Mark the rest of your images, backgrounds, and galleries.

Transformations

Every token you can put in a hand-built hero URL.

Troubleshooting

Diagnose a slow hero and other load problems from the console.

Configuration

Set max-dpr, width step, and the lazy-load lookahead from the script URL.