Beyond Code & Karma · Web Performance
Five numbers Google uses to score the felt experience of your page — how fast it appears, how fast it answers, and how steady it stays. Explained through the Performance APIs that measure them, the one fix that moves each, and a live checker you can run right now.
Chapter 01 — The Foundation
Core Web Vitals are Google's attempt to measure the felt experience of a page, not just its byte count. Three are the headline vitals — LCP (how fast the main content appears), INP (how fast the page answers an interaction), and CLS (how much the layout jumps). Two more — TTFB and FCP — are diagnostic foundations that explain why the headline numbers land where they do. Google uses real-user field data on these for ranking, which is why a green badge is worth money.
The Cosmic Connection
To serve a visitor's time and attention without making them wait, stumble, or lose their place is seva — selfless service — and dharma toward the one who came to you. The three headline vitals map cleanly onto three duties you owe every visitor.
And measuring your own vitals honestly — not flattering lab numbers, but the truth of a real session — is svadhyaya, self-study. You cannot serve what you refuse to see.
Chapter 02 — The Five Metrics
Thresholds below are the 2026 Google bands — Good, needs work, then Poor. For each metric there is one fix that moves the needle more than the rest.
Chapter 03 — Show Me The Code
No library needed. The browser already exposes every vital through
PerformanceObserver. Reading LCP is five lines:
// Read this page's Largest Contentful Paint, live. new PerformanceObserver((list) => { const entries = list.getEntries(); const lcp = entries[entries.length - 1]; // last entry wins console.log('LCP', Math.round(lcp.startTime), 'ms'); }).observe({ type: 'largest-contentful-paint', buffered: true });
buffered: true: LCP candidates fire
before your script runs. The buffered flag replays entries that
already happened, so you never miss the real largest paint.
The single biggest source of layout shift is media that loads with no reserved space. Give the browser the dimensions and the shift disappears:
// CLS killer: reserve the box BEFORE the image loads. // The browser infers the ratio from width/height attrs… <img src="hero.jpg" width="1200" height="630" alt="…" /> // …and one CSS rule keeps it fluid without ever shifting: img { height: auto; } // aspect-ratio inferred → zero layout shift
Navigation starts; the server responds. The first byte arrives. Everything downstream waits on this.
First pixels (FCP), then the largest element finishes rendering (LCP). The visitor now sees your content.
The user clicks or taps. INP records how long until the next frame paints the response. Long tasks hurt here.
Across the whole lifetime, every unexpected shift accumulates into CLS. A late font or image can spike it at any moment.
| Metric | Measures | Good / Poor | Top fix |
|---|---|---|---|
| LCP | Largest element render time | ≤ 2.5s / > 4s | Preload hero, kill render-blockers |
| INP | Interaction → next paint | ≤ 200ms / > 500ms | Break long tasks, yield to main |
| CLS | Unexpected layout movement | ≤ 0.1 / > 0.25 | Set width/height, reserve space |
| TTFB | Navigation → first byte | ≤ 800ms / — | Edge cache / CDN, cut server work |
| FCP | First DOM content painted | ≤ 1.8s / — | Inline critical CSS, preconnect |
Chapter 04 — Measure This Page
These two numbers are read from this page session by a real
PerformanceObserver — not a simulation. Scroll and
interact and watch them settle.
Chapter 05 — Deep Dive
This is where the basic tutorials stop. Here's what actually decides your score at scale.
Lab tools like Lighthouse run on a simulated device and network — repeatable, great for debugging, but a fiction. Field data (the Chrome UX Report, or RUM) is the 75th-percentile of real users on real phones and flaky networks, and it's what Google ranks on. A green Lighthouse score with a red field score is common: your laptop is not your users.
First Input Delay only measured the delay before the first interaction's handler started — not how long the handler ran, and only once. Most pages passed FID trivially while still feeling sluggish. INP measures the full latency, from input to next paint, across all interactions, and reports the worst. It's a far harder and more honest bar.
CLS isn't just "things moved". Each shift score is
impact fraction (how much of the viewport the unstable
element covers) times distance fraction (how far it
moved, relative to the viewport). Shifts are grouped into session
windows and CLS is the worst window's sum. Shifts within 500ms of
a user input are excluded — that's the hadRecentInput
flag the live checker honours.
TTFB isn't a Core Web Vital, but a slow one caps every other metric — paint can't begin until bytes arrive. It's a chain: redirects, DNS, TLS, server think-time, then first byte. Edge caching and CDNs attack the network legs; cutting server work on the critical path attacks think-time. A 1s TTFB makes a green LCP nearly impossible.
navigation PerformanceEntry's
responseStart — the same source DevTools uses.
Vitals are not vanity — they move real outcomes:
| Surface | Why it matters |
|---|---|
| Google ranking | Core Web Vitals are a confirmed ranking signal via the page experience system. |
| Conversion | Studies repeatedly tie faster LCP and lower CLS to higher conversion and lower bounce. |
| Ad revenue | Layout shift from late-loading ads both spikes CLS and triggers accidental clicks. |
| Retention | Sluggish INP makes an app feel broken even when nothing is technically wrong. |
Chapter 06 — Dharma & The Page
Karma is the principle that every action has a consequence. Each performance choice you make is an action whose fruit the visitor eventually tastes — a preloaded hero, a yielded task, a reserved box. None of it is for show; it is service rendered before anyone arrives.
// Every paint is a darshan — the first true sight you grant. showHeroFast(); // good LCP → seva, service to the visitor // Every interaction deserves an answer without delay. yieldToMain(); // low INP → responsiveness as dharma // Never move the ground under their feet. reserveSpace(img); // width/height set → sthirata, steadiness
A fast LCP is darshan offered without delay. A low INP is answering the user's call the moment it comes. A stable layout is sthirata — never moving the ground beneath their feet. And measuring your own vitals honestly, refusing the comfort of flattering lab numbers, is svadhyaya: the self-study that makes the service real.
"Do the work well and do not cling to the score; serve the visitor's time, and the ranking follows." — the Gita, interpreted for performance engineers 🙏
Chapter 07 — Test Yourself
Three questions. No cheating. Your karma is watching.
The Enlightenment
कर्म करो, फल की चिंता मत करो