Slow LCP

The page is loaded three times in a real browser (each time in a fresh, empty context, so with a cold cache) and LCP (Largest Contentful Paint) is measured: the time it takes to render the largest visible element, typically the hero image or a heading. The median of those three values is used. The finding is raised when the median exceeds 2,500 ms. The threshold lives in config/seo.json under web_vitals.lcp_ms_threshold and the report gives the measured value.

This threshold is not our estimate: 2.5 s is the official boundary between “good” and “needs improvement” in the Core Web Vitals methodology.

Limitations you must know before acting on that number:

• It is a lab measurement, not data from your visitors. Three loads from a single location, from our server, over our connection, at one moment in time. Google grades on field data from real users over 28 days. Our number and theirs can differ substantially.
• Only a sample is measured: at most 10 pages (web_vitals.max_sample_pages), not the whole site.
• Median of three measurements, not the 75th percentile. Google takes the 75th percentile of thousands of loads from real users; we get three attempts from one machine. Three samples reliably remove a single outlier (hence the change on 2026-09-19: one measurement reported 2,604 ms on torumata.com/en where the median of five measurements was 112 ms), but they do not replace the spread of your real visitors. The number of samples lives in config/seo.json under web_vitals.samples_per_page.
• We do not measure INP (interaction responsiveness), the third Core Web Vitals metric; it would need real user interaction.

And what the check does not judge at all: the cause. It measures that the largest element rendered late, but it will not say whether your server, a large image or a third-party script is responsible. That part is yours to find.

Treat our value as a hint where to look, not a verdict. The finding is page-level; severity is warning.

Two things need separating here, because one is firmly documented and the other not at all.

For classic search, Core Web Vitals are a confirmed ranking signal, and Google states it in its own documentation: Core Web Vitals are used by its ranking systems. But it is one component of a broader “page experience” assessment and works more like a tie-breaker than a main criterion; relevance and content quality weigh more.

For visibility in AI assistants' answers we have no documented effect and do not claim one. None of the primary sources addresses it, the same discipline as with structured data and llms.txt. Hence “effect not demonstrated”, even though for classic search this is one of the few signals Google has confirmed in writing.

And one open uncertainty we would rather state than hide: during 2026 reports circulated about a possible tightening of the LCP threshold to 2.0 s. One source claimed it, another denied it, and neither was Google. The primary source (web.dev) still states 2.5 s with no mention of a change, so we follow it. If anyone quotes you 2.0 s, ask where they got it.

Start with real data, not ours. If your site is in Search Console, the Core Web Vitals report there shows measurements from your visitors over 28 days, and that is the number Google grades you on.

LCP nearly always breaks in one of four places, in this order of frequency:

1. The hero image is fetched late. It carries loading="lazy" (counter-productive above the fold, the inverse of SEO-38), or it loads after a script. Fix: fetchpriority="high" and no lazy loading on the first image.
2. The image is needlessly large. A 4000 px photograph displayed at 800 px. Fix: a modern format (SEO-37) and responsive variants via srcset.
3. Render-blocking resources in the head. Fonts and stylesheets that must arrive before anything is painted. Fix: preload for the critical ones, defer the rest.
4. A slow server response. When the HTML itself takes a second, LCP under 2.5 s is out of reach. Fix: caching, a CDN, faster page generation.

And something often overlooked with performance: measure after every change, not at the end. An optimisation that makes sense on paper can make LCP worse: typically preload on ten files at once, which then compete for the same connection.