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.
Use the sequence below as a diagnostic method, not as a promise that one setting fits every host; verify its example paths, privileges, and backup assumptions while working to identify the page’s real LCP element and reduce TTFB, discovery delay, transfer duration, and render delay in that order.
Likely failure paths
- 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.
A controlled investigation
- 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
The opening hypothesis is high TTFB delays the initial HTML and every resource discovered from it. Test it with the least invasive observation available: use PageSpeed Insights field data when available, then record a DevTools performance trace. Do not change configuration until the observation has been saved with a timestamp.
When that evidence is consistent with the hypothesis, stage this repair: improve origin/cache response when TTFB dominates. Otherwise, preserve the current state and advance to the next branch. This keeps rollback simple and prevents a second change from masking the first.
Make the smallest durable change
- 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.
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.
Close the incident with evidence
- 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.
Do not trade visibility for a green screen
- Do not preload several competing images; priority loses meaning.
- Do not optimize a lab-selected element that differs from real-user LCP.
Change record
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.