Installing an image-compression plugin is not an LCP method. The LCP element may be text, and a compressed hero can still start late because JavaScript or CSS hides it from the preload scanner.
The reliable route is not the longest checklist; establish the failing boundary, keep one clean reproduction, and change one layer at a time until the evidence lets you identify the page’s real LCP element and reduce TTFB, discovery delay, transfer duration, and render delay in that order.
Read the failure at the right layer
- High TTFB delays the initial HTML and every resource discovered from it.
- The hero image or font is discoverable only after CSS or JavaScript executes.
- Large transfer size, lazy-loading of the LCP image, or main-thread work delays render.
The branches are ordered to protect the strongest evidence around this possibility: high TTFB delays the initial HTML and every resource discovered from it. The observed scope and logs—not a familiar-looking error screen—decide which one applies.
Performance work needs a measured bottleneck and a comparable before/after trace; a faster test after warming a cache or changing network conditions is not proof that the code improved; in this guide, the practical goal is to identify the page’s real LCP element and reduce TTFB, discovery delay, transfer duration, and render delay in that order.
Build a clean diagnostic record
- Use PageSpeed Insights field data when available, then record a DevTools performance trace.
- Identify the LCP element and split time into TTFB, resource load delay, load duration, and element render delay.
- Inspect the initial HTML for the image URL/srcset and fetch priority.
- Compare templates because each may have a different LCP element.
The sequence moves from observation toward intervention. Preserve the result of the final check—compare templates because each may have a different LCP element—because it provides a useful comparison after the repair.
Worked diagnostic: evidence before action
Treat “High TTFB delays the initial HTML and every resource discovered from it” as a working hypothesis, not a conclusion. Establish a baseline first: use PageSpeed Insights field data when available, then record a DevTools performance trace. Record both the result you expected and the result you actually saw.
A supporting result justifies a staging test of the narrowest repair: improve origin/cache response when TTFB dominates. A result that contradicts “High TTFB delays the initial HTML and every resource discovered from it” is useful too: it rules out one layer without disturbing production and gives the next operator a clean starting point.
Repair the cause—not the message
- Improve origin/cache response when TTFB dominates.
- Make the LCP resource discoverable in initial HTML; do not lazy-load it, and use priority hints selectively.
- Serve an appropriately sized modern image and remove render-blocking/main-thread work that delays display.
Before applying “Improve origin/cache response when TTFB dominates,” name its rollback point and the evidence that will count as success. Afterward, repeat the original request and specifically check whether you can repeat lab traces with consistent conditions and then watch 75th-percentile field data; a changed symptom at that point is new evidence, not permission to make several more changes at once.
Verification checklist
- Repeat lab traces with consistent conditions and then watch 75th-percentile field data.
- Check mobile and desktop separately.
- Confirm other metrics and image quality did not regress.
One successful refresh is not closure. Keep the incident open until you can also check mobile and desktop separately, adjacent paths have not regressed, temporary diagnostics are gone, and another operator can explain what changed.
Prepare a useful escalation if the boundary is outside your control
Record URL/template, device and network profile, cache state, geographic test point, trace or waterfall, field-data window, and deployed version; report medians or percentiles across repeated observations rather than the best run; include the result of this first observation: use PageSpeed Insights field data when available, then record a DevTools performance trace.
State what was tested, including the result of “Use PageSpeed Insights field data when available, then record a DevTools performance trace,” and what changed between attempts; evidence tied to that observation is safer and more actionable than granting broad access or sending an unnecessary full database export.
Make the real hero image discoverable in initial HTML
When a measured hero image is the LCP element, emit it directly with dimensions, responsive candidates, and high priority. Do not lazy-load it.
<img
src="/images/hero-960.webp"
srcset="/images/hero-640.webp 640w, /images/hero-960.webp 960w"
sizes="(max-width: 700px) 100vw, 960px"
width="960" height="540"
fetchpriority="high"
alt="WordPress request waterfall with the LCP resource highlighted">Interpretation and safety: Use this only for the measured LCP image. Preloading or prioritizing several competing images can make the waterfall worse.
Tempting moves to avoid
- Do not preload several competing images; priority loses meaning.
- Do not optimize a lab-selected element that differs from real-user LCP.
Evidence log
Primary references
- web.dev Optimize LCP — official reference consulted for this guide.
- WordPress performance — official reference consulted for this guide.
Editorial note: The scenario above illustrates how to approach “Improve origin/cache response when TTFB dominates”; it is a documented example, not a claim about a reader’s server, so verify the cited documentation, take the appropriate backup, and follow the real environment’s access and change-control rules.