All articles
Perf · 07 09 August 2026 6 min read

Lighthouse is 98. Why does the site still feel slow?

Green scores measure a lab snapshot. Users feel tap delay. Interaction to Next Paint (INP) is the metric that finally matches that complaint — and most “fast” marketing sites still fail it on a mid-range Android.

inp · main thread · 200ms

Lighthouse runs on a quiet tab with a scripted click. Real users tap while your analytics bundle, chatbot, and carousel are still parsing. INP (Interaction to Next Paint) measures how long until the next frame after a tap, click, or keypress. Google's “good” bar is under 200ms at p75. Plenty of pretty sites sit at 300–500ms and wonder why bounce is high on mobile.

The usual INP villains

"Speed is what the next frame does, not what the audit PDF says." — performance review

How we debug it in a day

  1. Chrome Performance + “Web Vitals” overlay on a real Android, not just DevTools throttling.
  2. Field data: CrUX / RUM (p75 INP by page and by interaction name).
  3. Long tasks > 50ms: who owns them? Your code or a vendor?
  4. Break the tap: paint a :active state immediately, then do the expensive work in requestAnimationFrame / idle / a worker.
  5. Delete or defer anything that isn't on the critical path for that click.
Quick win

Highlight on pointer-down, not on click. A 100ms scale on :active makes a 180ms INP feel instant. Apple has been saying this for years. The web still ignores it.

Framework notes (2026)

What “fast enough” looks like for a marketing site

LCP under 1.5s on a mid phone, INP under 200ms on the primary CTA and nav, CLS under 0.1, and no custom cursor eating rAF. If you only have budget for one metric this quarter, fix INP on the tap that makes you money.

· · ·

We treat feel as a product requirement

Audits are a starting point. We ship press states, kill main-thread jank, and measure field INP after launch — because a 98 that feels slow still loses the lead.