# Search Console Flagged Your LCP the Week You Turned On Caching, and Its Window Is 28 Days Wide

> Search Console's LCP figure covers the previous 28 days, so a cache enabled last week is rarely the cause. How to date the window and find the real change.

- Published: 2026-10-15
- Author: xSpeed Cache Team
- Tags: Core Web Vitals, PageSpeed, Caching, Performance, WordPress, fix:lcp-regression, platform:wordpress
- Canonical: https://xspeedcache.com/blog/search-console-lcp-after-caching/

---

Updated October 2026

Google's help page for the Core Web Vitals report, fetched on 15 October 2026, defines the number on your screen as "75% of page requests took this amount of time or less to reach largest contentful paint in the last 28 days". Our own archive of 2,030 WordPress sites, measured on 3 October 2026, found a cache hit moved median mobile LCP by 136ms, which a rank-sum test cannot separate from zero. So the alert describes four weeks of visitors and your cache is four days old. The comparison people make is before the cache against after. The more useful one is the alert's window against your deploy log.

## Quick Summary: Which Part of the Alert to Read First

| If you want… | Do this | Why |
|:---|:---|:---|
| To know when it started | Subtract 28 days from the alert date | The figure covers the previous 28 days |
| To know which page regressed | Read every URL in the row, not the example | Each row is a group of similar pages |
| To know whether the cache did it | Measure your own first byte and paint | A hit moved first byte 481ms, LCP 136ms |

Caching is a first-byte change. This metric is mostly paint work, and the two have separate budgets.

## The Window Is 28 Days Wide and Your Deploy Was Four Days Ago

The misattribution here is arithmetic.

The Chrome UX Report feeds that panel, and its [API documentation](https://developer.chrome.com/docs/crux/api), fetched on 15 October 2026, states that "the data in the Chrome UX Report is a 28-day rolling average of aggregated metrics". The same page adds the line that settles it: "the collectionPeriod is the period of time that the CrUX data was aggregated over, not necessarily the period of time that the data represents."

An alert on 15 October reports 17 September to 15 October, so where your deploy sits in that range decides whether it can be the cause at all.

![A 28-day timeline: a deploy on 20 September leaves 89% of the window after it, one on 11 October leaves 14%.](https://xspeedcache.com/images/blog/lcp-alert-28-day-window.webp)

Four days of traffic cannot move a 28-day 75th percentile across the 2.5 second threshold [web.dev's Largest Contentful Paint reference](https://web.dev/articles/lcp) sets. The September deploy is a genuine candidate; the October one is not.

## The Row You Clicked Is a Group of Pages, Not Your Page

The report is often not addressing the URL you think. Google's [report documentation](https://support.google.com/webmasters/answer/9205520) states that "each row in the table represents a group of similar URLs", and that once a group has enough data "the URL group's status is its most poorly performing metric".

| What you assume | What the report says | Matches your deploy? |
|:---|:---:|:---:|
| The named URL is the slow page | One representative of a group | ❌ |
| The group is what you changed | Pages with a similar experience | ❌ |
| The status describes LCP alone | The group's worst metric | ❌ |

![Three cards: a row is a group of similar URLs, its status is the group's worst metric, and a thin group becomes an origin group.](https://xspeedcache.com/images/blog/search-console-url-group-status.webp)

Small sites hit a third case. Where a group lacks the data to appear, the same page says "Search Console creates a higher-level origin group", so the subject can be your whole origin rather than any page you shipped.

## Why the Cache Is the Weakest Suspect in That Window

Our own measurements point the same way three times.

| Dataset | Median first byte | Median LCP | Verdict on LCP |
|:---|:---|:---|:---|
| 2,030 sites, hit against miss | 193ms against 674ms | 6,615ms against 6,751ms | Rank-sum z of 0.7 |
| 958 sites, cached against not | 121ms against 442ms | 5.35s against 5.05s | No gain at all |
| 413 sites, server time removed | Subtracted entirely | Unchanged | 93.4% still fail |

Numbers and limitations are in [the 2,030-site cache hit study](https://xspeedcache.com/blog/cache-hit-lift-study/), [the 958-site scan study](https://xspeedcache.com/blog/wordpress-core-web-vitals-scan-data/) and [the cache ceiling analysis](https://xspeedcache.com/blog/caching-did-not-fix-slow-wordpress/). A cache is a large win on the first byte and close to nothing on paint, an unlikely cause of a paint regression either way. What does move paint is set out in [LCP has four parts and the server is only the first](https://xspeedcache.com/blog/good-ttfb-slow-page/).

Look for what else shipped in that window. A hero image, a font swap, a slider, a consent banner or a theme update all land in the parts of LCP a cache never touches.

## The 28-Day Attribution Test: Four Questions, One Field Each

Run this before changing a cache setting. Every answer is on your screen.

1. **When does the window open?** Alert date minus 28 days. Everything inside is a candidate, and the cache is one line on that list.
2. **Page group or origin?** Read the row's URL list. An origin group means the alert is about the site.
3. **Which metric carries the status?** Check LCP, CLS and INP separately, because the status reports the worst.
4. **Did your own timings move?** Measure first byte and paint on the flagged URLs.

What it cannot tell you: CrUX reports a percentile, not a cause, so a clean result narrows the suspects rather than naming one. It also cannot see browsers that do not report to CrUX.

## Reading This Across Every Site You Publish

Start with the scan, not the dashboard. Run the free [xSpeed Scan](https://xspeedcache.com/scan/) on a flagged URL: no account, no plugin, and it reports the first byte and the paint from outside your network. That separates a first-byte problem from a paint problem in one request, the split the alert does not give you.

[Reading a PageSpeed report](https://xspeedcache.com/blog/read-pagespeed-report-wordpress/) covers why lab and field answer different questions, and [passing Lighthouse while failing Core Web Vitals](https://xspeedcache.com/blog/pass-lighthouse-fail-core-web-vitals/) reports how often the two disagree on one site.

We build xSpeed Cache at WPDeveloper, and its job here is narrow: it owns the first byte, which this alert is usually not about. The scan and auto purge are in the free plugin, per [Free vs Pro](https://xspeedcache.com/free-vs-pro/), so every step above is free. Across a client list, [xSpeed Hub](https://xspeedcache.com/xspeed-hub/) finds the site whose paint budget drifted. Stores feel it first: [the WooCommerce use-case page](https://xspeedcache.com/use-cases/woocommerce/) and [the troubleshooting docs](https://xspeedcache.com/docs/common-problems-and-troubleshooting/) carry those settings.

## Common Mistakes After an LCP Alert

- 📅 **Reading the alert date as the change date.** It is the end of a window.
- 🔁 **Turning the cache off to test.** That moves the first byte, not the graded metric.
- 🔍 **Fixing only the example URL.** The row is a group, so the fix must reach it.
- ⏱️ **Expecting confirmation in days.** Validation restarts a four-week period.

## Frequently Asked Questions

### I enabled caching on Monday and Search Console flagged LCP on Friday. Did the cache cause it?

Almost certainly not. The figure reports the previous 28 days, so four days of traffic is a small part of the sample. Our 2,030-site measurement puts the cache's effect at 136ms.

### I turned the cache back off and the alert did not clear. Why?

The window has to roll. A correct fix needs most of 28 days of new visits before the 75th percentile moves.

### My report shows one URL but I have hundreds of posts. Which one is slow?

Possibly none specifically. The URL displayed represents a group of similar pages, so read the group's list before optimising.

### I have no data in the report at all. Is something broken?

No. A group needs a minimum amount of data to appear, for user privacy, and Search Console reports an origin-level group where it is missing.

### I fixed a hero image and my first byte got slower. Did I break the cache?

Check the first byte separately, because the two budgets are independent. A scan reports whether the response still comes from cache.

## Conclusion: Date the Window Before You Blame the Deploy

The alert is a 28-day percentile attached to a group of pages, and its status is that group's worst metric. Read it that way and the cache falls off the suspect list before you touch anything.

**What to do this week:**

1. Subtract 28 days from the alert date and list every change inside it.
2. Read the flagged row's URL list: a group, or your whole origin?
3. Check LCP, CLS and INP separately for that group.
4. Run the free scan on two flagged URLs, first byte against paint.
5. Fix the paint work, then start validation and wait out the window.

If the first byte is the problem after all, that is the part a cache fixes. xSpeed Cache is free on the plugin directory, and Pro runs from $29/yr at the founding price with a 14-day money-back guarantee.