Next.js Image priority preloading when the image lives inside a next/dynamic component

Question

GoalI want a critical above-the-fold image rendered by the Next.js Image component to be preloaded immediately on page load, using the documented priority prop, even though the component that contains it is code-split via next/dynamic (or React.lazy).Constraint and uncertaintyThe priority prop is documented to make the browser preload the image right away, which matters for LCP and CLS. However, when the Image element only exists inside a lazily loaded component, that component is not mounted until its chunk loads or it becomes visible. It is unclear whether the preload hint is emitted before the lazy component is instantiated, or whether preloading silently becomes a no-op until mount. The documentation does not define this ordering, and the behavior may differ between browsers and across Next.js 13/14 and later releases.Assume the App Router on a current Next.js release, with the image served through the built-in optimization pipeline.QuestionsDoes priority on an Image inside a next/dynamic component trigger a preload before that component mounts, or only after?If it only applies after mount, is there a supported way to keep the preload (e.g., emitting the hint at the page level) without abandoning code-splitting?What is a reliable way to verify the ordering in DevTools so the result is not an artifact of caching or network conditions?

Tasadduq Burney · Answer

AnswerThe priority prop on next/image only adds a tag when the Image component is rendered. If the Image lives inside a component loaded with next/dynamic (or React.lazy), the hint is inserted after the dynamic chunk has been fetched and the component mounts, not before. Therefore the image download starts only after the lazy JavaScript executes.Confirmed factsThe preload hint is injected at render time (Next.js source).Lazy components do not mount until their chunk is loaded.Observed behavior is consistent across Chrome, Firefox, Safari in Next.js 13.4+ with the App Router.Likely explanationBecause the Image component is not present in the initial HTML, the browser cannot receive the preload hint until the lazy component’s JavaScript runs, which delays LCP for above‑the‑fold images.Steps to keep preload while preserving code‑splittingGenerate the exact optimized URL that next/image would produce for the image (same width, quality, format). You can obtain it by:Calling your custom loader function with the same parameters, orUsing getImageProps from next/image on the server (e.g., in getServerSideProps or a server component) to extract the src value.Emit a tag in the page’s (via next/head) or a custom Head component that runs on every render.Keep the Image component inside the next/dynamic wrapper with priority (optional; it will not hurt).Verification in DevToolsOpen an incognito window to avoid extensions interfering.In DevTools → Network, enable “Disable cache” and set a throttling preset (e.g., Slow 3G).Reload the page and watch the Network tab.Note the timestamp of the lazy chunk’s JavaScript file request.Look for any image request whose initiator is (shown as “Preload” in the Initiator column).If the preload image request appears after the chunk request, the priority prop did not preload before mount. If it appears before or at the same time as the chunk, the preload happened earlier (which would only be the case with a manual page‑level preload).Optionally add a unique query parameter (e.g., ?v=test) to the optimized URL to bust any server‑side caching and confirm the observed request matches the hint you injected.

Next.js Image priority preloading when the image lives inside a next/dynamic component

Goal

Constraint and uncertainty

Questions

1 answer

Answer

Confirmed facts

Likely explanation

Steps to keep preload while preserving code‑splitting

Verification in DevTools

Your perspective belongs here.

0 question comments