Preload and fetchpriority solve related but different problems. Preload makes a resource discoverable earlier; fetchpriority hints at relative priority when it is fetched. Either can be unnecessary or harmful when used broadly. Start from a trace that shows a specific delay.
Reduce a confirmed LCP image discovery or priority delay without creating duplicate requests or starving other critical resources.
Repeatable method
1. Identify the LCP element
Use multiple runs and viewport sizes. The image must be a consistent candidate before adding special handling.
2. Separate discovery from priority
If an img is already early in server-rendered HTML, discovery may be fine. If a CSS background or script inserts it, preload may address discovery.
3. Test one hint at a time
First test fetchpriority=”high” on the likely LCP img. If discovery is still late, test a matching preload. Keep URLs, srcset, and types aligned to avoid duplicates.
<img src="hero.webp" width="1600" height="900" fetchpriority="high" alt="Image encoding comparison">4. Compare several traces
Use the same device, network profile, cache state, and test harness. Examine request start, priority, LCP subparts, and competing resources rather than one overall score.
Single-variable LCP hint fixture
Prepare three illustrative variants that reference the same 1600 × 900 hero URL and identical responsive candidates. Variant A is the baseline. Variant B adds only fetchpriority="high" to the image. Variant C returns to the baseline image and adds one matching preload in the document head. These variants are a protocol, not evidence that either hint improves the page.
Trace record for each variant
- Baseline: capture the discovery source, request start, initial priority, LCP load delay, and any duplicate request.
- fetchpriority variant: keep the image bytes and markup unchanged, add only
fetchpriority="high", and capture the same fields. - preload variant: remove the priority change, preload the exact delivered candidate, and verify that responsive selection does not cause a second download.
- Decision rule: keep a hint only when repeated traces reduce the specific delay without delaying other critical requests.
Run each variant several times with the same viewport, cache state, server response, and network profile. Verify in Network that the preload URL, type, and responsive selection do not trigger a second download. Record medians and the competing CSS, font, or script requests. Keep only the smallest intervention that consistently addresses the specific discovery or priority delay shown by the traces.
What to record
Record browser version, viewport, network and CPU settings, cache state, LCP element, request discovery time, priority, load duration, LCP subparts, applied markup, and at least three runs per state.
A result belongs to the source file, encoder, settings, browser, viewport, cache state, and date that produced it. Repeat the test on representative files before changing a production workflow.
Common mistakes
- Using preload and fetchpriority everywhere
- Preloading a URL different from the responsive candidate
- Combining a lazy LCP image with high priority
- Publishing a single PageSpeed screenshot as proof
Verification checklist
Check for duplicate image requests, confirm the desired currentSrc, compare median traces, test a second viewport, and verify CSS and font loading did not regress. Keep the change only if the evidence is consistent.
Primary references
Related lab notes
About this guide
We distinguish documented platform behavior from our workflow recommendations. See the testing methodology, editorial policy, and corrections log.