When Lighthouse Is Green but Search Console's Core Web Vitals Are Red — Field Notes on Naming the Slow Interaction with Real-User Data

Read the breakdown to confirm it's "heavy processing"

Once I could name it, the next step was the breakdown of that 410ms. The RUM aggregation looked like this.

Processing was 360ms. So the cause was neither loading nor rendering, but synchronous work inside the event handler. The moment a tag was clicked, thousands of articles were being filtered on the main thread every time.

At this point the instruction to Antigravity becomes concrete. Not "make the site faster," but "the article-list tag filter handler has a p75 processingDuration of 360ms; please split this synchronous filter to lower INP." When you can name the cause, the agent's suggestions get sharply better.

Fix only the one named spot with Antigravity

I handed Antigravity's chat the specific information from RUM as-is. What came back was a fix that decouples the filtering from input responsiveness.

// Before: synchronous filter of all items on every click (inflates processingDuration)
function TagFilter({ articles }: { articles: Article[] }) {
  const [tag, setTag] = useState('');
  const filtered = articles.filter((a) => a.tags.includes(tag));
  return (
    <>
      <TagButtons onSelect={setTag} />
      <ArticleGrid items={filtered} />
    </>
  );
}
 
// After: useTransition marks filtering non-urgent and returns the input response first
import { useState, useTransition, useMemo } from 'react';
 
function TagFilter({ articles }: { articles: Article[] }) {
  const [tag, setTag] = useState('');
  const [isPending, startTransition] = useTransition();
 
  // keep the heavy compute, but take the selection out of urgent rendering
  const filtered = useMemo(
    () => articles.filter((a) => a.tags.includes(tag)),
    [articles, tag],
  );
 
  const handleSelect = (next: string) => {
    // don't block the click's paint; apply the filter afterward
    startTransition(() => setTag(next));
  };
 
  return (
    <>
      <TagButtons onSelect={handleSelect} pending={isPending} />
      <ArticleGrid items={filtered} />
    </>
  );
}

The point of useTransition is to return the visual response to the click (the pressed state) immediately, and push the reflection of the heavy filter result into a non-urgent lane. I did not make the computation itself faster; INP drops because the "next paint" after the user's interaction is delivered first. Finding handlers that hurt INP shares its logic with Troubleshooting slow behavior in Antigravity.

In the RUM measurement, this screen's INP p75 dropped from 410ms to 90ms, about a 78% improvement. The lab score barely changed. Of course — the lab was never measuring this interaction to begin with.

Protect the field improvement with a regression test

Finally, I put in a mechanism to protect the number I had just lowered.

Field data takes weeks to update, so you cannot use it as a CI pass/fail signal. Instead, I built a synthetic test in the lab that actually fires that interaction. It reproduces the interaction real users touch and regression-monitors a metric close to INP.

# .github/workflows/inp-regression.yml — reproduce the real interaction and regression-monitor INP
name: INP Regression
on:
  pull_request:
    branches: [main]
jobs:
  interaction:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: 22 }
      - run: npm ci && npm run build && npm run start &
      # Playwright actually clicks the "tag filter" identified by RUM,
      # measures the event's processingDuration, and gates on a threshold
      - run: node scripts/measure-interaction.mjs --path=/articles --action=tag-filter --budget-ms=200

What matters is matching the interaction you measure in CI to "the interaction that was red in RUM." No matter how well you guard a screen no one touches, the field will not move. A concrete example of wiring Lighthouse CI into a regression pipeline is in Stopping Lighthouse CI performance regressions in Antigravity.

Wrap-up — find "whose, which interaction" before you fix

After a two-week detour, the lesson is a single one. If lab is green and field is red, the thing deciding what to fix is the field.

Lighthouse is excellent as an entrance checkup. But only RUM could name a real user's INP. Once you capture the source element and the breakdown of the event with web-vitals attribution, your instruction to Antigravity changes from "make it faster" to "lower this breakdown of this interaction." Agents respond far better to a specific symptom than a vague wish.

The next time my Core Web Vitals go red, I will stop poking at a real device and open the RUM aggregation first. The slow interaction usually lives on a screen I have not been polishing. I hope this helps anyone stalled at the same divergence.