News
fetchpriority vs loading=lazy for Public Sites
November 22, 2023
fetchpriority vs loading=lazy for public sites is a competing-hints decision: loading=lazy defers offscreen images, while fetchpriority=high asks the browser to fetch a resource sooner — usually the LCP hero. Do not lazy-load the hero and do not mark every thumbnail high. RoastMyOpsec does not score these attributes as standalone Fs; they are performance hints, not browser security headers.
The practical difference
loading=lazy is a native hint that below-the-fold images can wait. fetchpriority (HTML fetchpriority / Fetch Priority API) is a relative hint: high, low, or auto compared with other requests. They stack. A lazy image with fetchpriority=high is a contradiction. A hero with loading=lazy is a common Core Web Vitals own-goal.
Neither attribute sanitizes URLs. A lazy image still requested from a tracker CDN is still a tracker. fetchpriority=high on a third-party script is how you volunteer to run ads before content. CSP and first-party hosting remain the controls.
iframe loading=lazy exists too. Same rule: do not lazy the thing the user came to see; do lazy decorative embeds that sit below the fold.
How to choose based on what you shipped
Set fetchpriority=high (and skip lazy) on the single LCP image. Leave loading=lazy on galleries and below-fold photos. Leave fetchpriority off for everything else. If a marketing pixel is in an img, removing it beats prioritizing it.
| Option | When it wins | Watch-out | Takeaway |
|---|---|---|---|
| fetchpriority=high | The one LCP image or a critical early fetch | Marking every asset high | Relative boost, not a lock |
| loading=lazy | Offscreen images and below-fold embeds | Lazy-loading the hero | Defer what the user cannot see yet |
| loading=eager (default) | Above-the-fold content you will paint immediately | Eager-loading a huge carousel | Fine for the first screen |
| Priority on third-party scripts | Almost never on a brochure page | Paying for trackers first | Host first-party; delay the rest |
When loading=lazy still wins
loading=lazy still wins for long articles with many images the user may never scroll to. fetchpriority=high still wins for the single hero. Missing both attributes is normal. Contradicting them on the LCP image is a performance miss, not a roast F.
Common mistakes
The first mistake is putting loading=lazy on the LCP hero.
The second mistake is setting fetchpriority=high on every thumbnail and tracker pixel.
The third mistake is treating missing fetchpriority as a security finding.
What a URL roast can prove
The free roast does not grade fetchpriority, loading=lazy, preload, Open Graph, or JSON-LD. It does grade CSP, HSTS, framing, cookies, TLS, exposed .git/HEAD and .env, package.json signatures, and js-secrets. Image hints are speed knobs; tracker-shaped hosts in HTML may still show up as tracker findings.
Free audit the URL you own
RoastMyOpsec is a defensive public-surface roast: headers, cookies, sensitive paths, and more — no exploit payloads. Start with the free audit, then open the vault if the blurred findings look expensive.
Free audit nowFAQ
- Should the hero image be lazy?
- No. Lazy-loading the LCP image delays the largest paint. Keep it eager and consider fetchpriority=high.
- Does fetchpriority replace CSP?
- No. It only hints scheduling. Script and image sources still follow CSP.
- Does RoastMyOpsec score loading=lazy?
- No. These attributes are not standalone Fs.