Core Web Vitals Explained: Measuring & Fixing LCP, INP and CLS

Three Metrics, Three Measurement Models

「The site feels slow」 is where every performance problem starts — unmeasurable and unfixable. Google splits that feeling into three quantifiable metrics — LCP (Largest Contentful Paint, loading), INP (Interaction to Next Paint, responsiveness), CLS (Cumulative Layout Shift, visual stability) — with pass lines of 2.5 s / 200 ms / 0.1.

This article focuses on the three things that go wrong most often: how lab and field data differ, the ranked causes for each metric, and a copy-paste measurement command (demonstrated against this site's production environment).

---

All three are judged at the P75 percentile (75% of visits pass), not the average — averages get inflated by good devices and hide the bad-user experience.

Lab vs Field: The Division of Work

The correct flow: field data shows 「INP P75 is over」 → reproduce that interaction in the lab → find the long task → fix → verify in the lab → wait for CrUX to refresh (28-day rolling window) to confirm. Declaring victory after a single Lighthouse run grades 「the easiest device」 instead of 「the worst scenario」.

---

LCP: The Full Chain from TTFB to Render

LCP is the moment the largest content element (image/video/text block) finishes rendering. It is not a single bottleneck but a chain of four stages — fix the stage that dominates:

Measured: production TTFB for four pages of this site (median of 3 runs each) —

curl -s -o /dev/null -w '%{time_starttransfer}\n' https://oltool.net/json-formatter.html
# median of 3 runs → 0.075s

TTFB sits at 64–83 ms (EdgeOne edge node) — SSR first byte is far below the 800 ms warning line ⇒ the LCP bottleneck is not the server; the remaining budget goes to the hero image and fonts.

---

INP: Not Just 「Make Clicks Fast」

INP tracks all interactions (click/keyboard/touch) across the page lifetime, from input to the next paint, taking a near-worst value. Interaction delay decomposes as:

input → [event handler JS] → [style/layout/paint] → next frame
        ↑ main source of delay            ↑ long tasks also drag this

Ranked causes:

1. Long tasks (synchronous JS >50 ms) block the main thread, queuing the 「next interaction」;
2. Handlers that do too much: one click synchronously computing, updating DOM and calling third parties;
3. Forced synchronous layout: interleaved reads (offsetHeight) and writes trigger layout repeatedly;
4. Large DOM: more nodes, slower style recalculation.

Three fixes:

• Split long tasks: yield the main thread with scheduler.yield() / setTimeout for non-urgent work;
• Immediate feedback: optimistic UI first (highlight/expand instantly), heavy work after requestAnimationFrame or in a Web Worker;
• Trim third-party scripts: analytics/chat/ads are long tasks you do not control — load on demand.

---

CLS: Three Sources of Unexpected Shifts

CLS accumulates layout-shift scores within windows without user input. The three most common sources, by fix ROI:

1. Unsized images/videos: <img> without width/height (or CSS aspect-ratio) pushes content down on load — a one-line fix with the biggest payoff;
2. Dynamically injected content: ad slots, cookie banners, infinite scroll pushing content away — reserve fixed height or min-height;
3. Web font swap (FOUT): text reflows when the font loads — mitigate with size-adjust / font-display: optional.

Animate with transform (no layout) instead of top/left (layout) — also the direction to check when 「CLS = 0 but animations feel janky」: smoothness is a frame-rate problem, belonging to INP's response chain.

---

Reproducible Results

Production TTFB (median of 3 runs each, direct connection):

for i in 1 2 3; do
  curl -s -o /dev/null -w '%{time_starttransfer}\n' https://oltool.net/json-formatter.html
done | sort -n | sed -n 2p
# → 0.075

Performance API full chain (paste into DevTools Console on any page):

const t = performance.getEntriesByType('navigation')[0];
const fcp = performance.getEntriesByType('paint').at(-1)?.startTime ?? 0;
console.log({
  ttfb: Math.round(t.responseStart - t.startTime),
  fcp: Math.round(fcp),
  domContentLoaded: Math.round(t.domContentLoadedEventEnd - t.startTime),
  load: Math.round(t.loadEventEnd - t.startTime),
});
// This site, production: { ttfb: 64, … } (TTFB far under the 800ms warning line)

CLS/INP need the web-vitals library (Performance API does not expose INP):

import { onLCP, onINP, onCLS } from 'web-vitals';
onLCP(console.log); onINP(console.log); onCLS(console.log);
// report to your analytics endpoint; aggregate to P75 for CrUX-comparable data

---

The Optimization Checklist (Ranked by ROI)

---

Takeaways

• Measure before optimizing: field data locates impact, lab data locates causes — reversed, you optimize air;
• Three metrics, three models: LCP follows the resource chain, INP follows the main thread, CLS follows layout reservation;
• P75 is the real standard: averages and medians both hide the bad-user experience;
• This site's production baseline: TTFB 64–83 ms, page totals <150 ms (edge rendering + CDN) — a healthy baseline, with remaining headroom in front-end assets.

The systematic optimization panorama is in the web performance guide; the measurement commands above can be re-run against any site.