Made by Dhawal Made by Dhawal

Core Web Vitals for Architects: Stop Optimizing Wrong

Lab scores lie. Field data tells the truth. A 20-year architect's intro to Core Web Vitals — LCP, CLS, INP, TTFB, FCP — and how to measure before you optimize.

23 July 2026 · 7 min · Performance

I've spent more than twenty years building frontends, and in that time I've watched performance work follow the same cycle at almost every company: a metric turns red, a "perf sprint" happens, the metric turns green, everyone moves on — and six months later it's red again.

The problem is rarely that engineers don't know how to optimize. The problem is that most teams treat Core Web Vitals as a checklist of tricks instead of what they actually are: symptoms of architectural decisions made months or years earlier.

Your LCP isn't slow because you forgot a preload tag. It's slow because of how you decided to render, where you decided to host, and what you decided to ship. That's what this series is about.

What Core Web Vitals actually measure

Google's Core Web Vitals are three field metrics that describe the user's experience of your page:

  • LCP (Largest Contentful Paint) — how long until the main content is visible. Loading.
  • CLS (Cumulative Layout Shift) — how much the page jumps around. Visual stability.
  • INP (Interaction to Next Paint) — how quickly the page responds when the user does something. Responsiveness.

Two other metrics show up constantly in this conversation — TTFB (Time to First Byte) and FCP (First Contentful Paint).  They're diagnostic metrics: causes, not outcomes. TTFB feeds FCP, FCP feeds LCP. When your LCP is bad, the first question is always "where in that chain did the time go?" — which is exactly why this series covers all five.

The lie your Lighthouse score is telling you

Here's the distinction that changes how you approach all of this: lab data vs. field data.

Lab data (Lighthouse, WebPageTest) is a simulation — one synthetic device, one network profile, one cold load, usually run from a CI machine or your own laptop. It's reproducible and great for debugging.

Field data (CrUX, your own RUM) is what real users actually experienced — thousands of devices, networks, and cache states, aggregated at the 75th percentile.

Google's ranking signal uses field data. Your users live in field data. And yet most teams celebrate a Lighthouse 100 while their CrUX report shows a failing LCP for real users on mid-range Android phones in the field.

If you take one thing from this intro: a Lighthouse score is a debugging tool, not a goal. Optimizing lab scores without field data is like tuning a race car in a garage and never taking it to the track.

Does this actually affect ranking (and revenue)?

Yes — but with proportion. Core Web Vitals are a ranking factor, mostly acting as a tiebreaker among pages with comparable content relevance. If your content is weak, a green CWV report won't save you.

The stronger business case is conversion. The industry is full of case studies tying loading and responsiveness improvements to measurable revenue lifts, and my own experience matches: performance work is user-experience work with a number attached. Rank is the bonus, not the reason.

Measure first, optimize second

Before the first optimization in this series, get measurement in place. In order of effort:

  1. CrUX — Google's free field data for your origin, in PageSpeed Insights and Search Console. Zero setup, 28-day trailing window, origin/URL level only.
  2. The web-vitals library — a small script that reports real-user LCP, CLS, and INP to your analytics. An afternoon of work.
  3. Full RUM with attribution — the attribution build of web-vitals (or a commercial RUM product) tells you which element was the LCP, which interaction was slow, which script blocked the main thread. This is the difference between guessing and knowing.

Every post in this series will assume you can answer the question "what does the field data say?" — because without it, you're optimizing folklore.

What's coming in this series

  • LCP — the four phases of loading, and where your time actually goes
  • CLS — the math behind layout shift, and designing layouts that can't shift
  • FCP — the critical rendering path, and the third-party scripts silently killing it
  • TTFB — CDNs, caching, redirects, and the cost of server-side rendering
  • INP — the main thread as a battlefield, and why this metric is the hardest of the five
  • Conclusion — how the metrics interact, and how to keep wins from regressing

One post per week. Real traces, real regressions, real trade-offs — no "10 tips to speed up your site."

Let's start with the metric everyone asks about first: LCP.

Next up: Series 1, Post 1 — What LCP Really Measures (and How the LCP Element Is Chosen)