Largest Contentful Paint in WordPress gets treated like a shopping problem: buy a caching plugin, buy an image optimizer, switch hosts, done. Most of the guides ranking for this query are written by the companies selling those plugins, which is why they skip the step that actually matters. LCP is four delays added together, and until you know which of the four is eating your time, every fix is a guess. Here is how I diagnose it on WordPress sites, why Search Console and PageSpeed Insights keep contradicting each other, and the three culprits that come up in audit after audit.
What is a good LCP score?
2.5 seconds or better, measured at the 75th percentile of real visits. That threshold comes from Google’s Core Web Vitals documentation and it has not moved: good is within 2.5s, poor is over 4s, and the range between needs improvement. The 75th percentile part matters more than people think. Your LCP is not the number from one test run on your office connection; it is the experience of the slower quarter of your real visitors, most of them on phones.
Why does Search Console say poor when PageSpeed Insights looks fine?
Because they are answering different questions. The Core Web Vitals report in Search Console is field data from the Chrome UX Report: real Chrome users, 75th percentile, a rolling 28-day window, grouped into buckets of similar URLs. The score at the top of a PageSpeed Insights run is lab data: one simulated load on throttled hardware, right now. A lab score of 95 with a failing field LCP usually means your real visitors are on slower devices and networks than the lab simulates, or that the tested page is not the one dragging down its URL group.
The 28-day window also explains the most common complaint I get: “I fixed it two weeks ago and Search Console still says poor”. Nothing is broken. The window still contains two weeks of the old, slow experience, and the report only moves once the slow days age out. And if your site is small, whole URL groups will show no data at all; I wrote up why Core Web Vitals shows not enough data separately.
Which part of LCP is actually slow?
Google’s own optimization guide breaks LCP into four subparts, and this is the diagnosis step almost every WordPress guide skips: time to first byte, resource load delay, resource load time, and element render delay. Run PageSpeed Insights, open the LCP audit, and look at the phase breakdown before touching anything.
What causes high LCP in WordPress?
Three culprits come up over and over in the WordPress audits I run, and each lives in a different subpart:
- The hero image is a CSS background. Page builders love styling the hero section with a background image. The browser’s preload scanner cannot see a CSS background early, so the download starts late and the resource load delay swallows the budget. The fix is making the hero a real
<img>withfetchpriority="high", or preloading the background file. Google’s guide is blunt about fetchpriority: use it on the LCP image, not on everything. - The LCP image is lazy-loaded. WordPress adds
loading="lazy"to images by default and skips the first one, but themes and optimization plugins regularly override that and lazy-load everything. Google’s guidance could not be clearer: never lazy-load your LCP image. Check the rendered HTML of the hero image, not the theme settings, because plugins rewrite the markup. - TTFB on cheap shared hosting. When the server takes over a second to send the first byte, no image work can save you, because subparts two through four have not even started. A page cache that actually hits fixes most of it. If TTFB is slow with caching on, the cache is being bypassed, usually by a cookie or a query string, and that is a configuration bug, not a hosting verdict.
Notice what is not on this list: HTTP versions. Protocol upgrades help visitors a little and crawling not at all, which I covered when looking at HTTP/2 and Googlebot.
Does LCP affect rankings?
Core Web Vitals are a ranking signal, and Google’s documentation says to aim for good on all three metrics, while also being consistent that great content outranks a great LCP. My honest reading from client work: fixing LCP rarely produces a visible ranking jump by itself, but it shows up in the numbers that lead to rankings, fewer abandoned loads, better conversion on the slower quarter of visitors, and it is a standard line item in the technical SEO audit checklist I run because it is measurable and fixable.
What I do on a WordPress job, in order: read the field data first in Search Console’s Core Web Vitals report, split mobile from desktop, and pick the failing URL group. Run PageSpeed Insights on one URL from that group and read the LCP phase breakdown. Fix the one subpart that dominates. Then wait out the 28-day window and confirm in the field data, not in a lab re-run. It is slower than installing another plugin. It also works the first time, because the fix was aimed at the delay that was actually there.
Sources
- Google, optimize Largest Contentful Paint, for the four subparts, the lazy-loading warning and the fetchpriority guidance, checked 16 September 2026
- Google, LCP metric definition and Search Central, Core Web Vitals documentation, for the 2.5 second threshold and 75th percentile rule
- Search Console Help, Core Web Vitals report, for field data, URL grouping and the 28-day window
- Google, lab and field data differences, for why the two disagree
- My own WordPress audit work for the three culprits and the diagnosis order