Loading Performance and Core Web Vitals

What architecture decisions move each metric

Figure 1. Where each metric is decided on one product page load

How to read this: the path from browser to origin decides TTFB and the start of LCP; the browser box is where CLS and INP happen; the muted third-party box is outside your control but inside your metrics.

Figure 2. The hero image on its way to becoming the LCP element

How to read this: the four parts of LCP appear in order: waiting for the first byte, the gap before the image request starts, the download, and the time to paint.

Web.dev's LCP optimisation guide splits LCP into exactly those four parts: time to first byte, resource load delay, resource load duration and element render delay. It gives rough proportions (about 40 percent, under 10, about 40, under 10) and warns against turning them into absolute time targets. Use them to find the largest part first.

Figure 3. Reading a bad field LCP

How to read this: choose the branch by measurement, not habit. Shrinking image bytes does nothing if the time goes on waiting for the server.

Resource priority and the critical path

The critical path is the chain of requests the browser must finish before it can paint the main content. Keep it short and make the LCP resource discoverable in the initial HTML: an <img> in the markup is found by the browser's early scan, while an image whose URL only arrives after a JavaScript bundle runs starts late. Web.dev recommends fetchpriority="high" on the likely LCP image (a hint that browsers may override), never lazy-loading it, and keeping high priority for only a few images.

<img src="/img/boot-1200.jpg" srcset="/img/boot-640.jpg 640w, /img/boot-1200.jpg 1200w"
     sizes="(min-width: 900px) 600px, 100vw"
     width="1200" height="900" alt="Brown leather boot, side view"
     fetchpriority="high">
<img src="/img/boot-sole-640.jpg" width="640" height="480" alt="Boot sole detail" loading="lazy">
<script defer src="/js/product.js"></script>
<script async src="https://tags.example.com/loader.js"></script>

The hero has width and height (reserves space), fetchpriority="high" and no loading="lazy". defer downloads in parallel and runs after parsing, in document order; async runs as soon as the script arrives, in no guaranteed order, which suits independent scripts (MDN: script element).

Server response time, caching and CDN

TTFB is the floor under LCP. The decisions are architectural: whether HTML can be served from a cache near the user, how many redirects precede the page, and how much work the origin does before the first byte. Web.dev also notes that unique query-string parameters (analytics ones, say) can make a CDN treat identical content as different, so the cached copy is not used. The browser side is HTTP Caching for the Front End; the server side is caching basics and CDN and object storage. Which rendering strategy produces the HTML changes TTFB and image discovery; see Rendering Strategies.

Image sizing, formats and fonts

Images are often the LCP element and the largest download: serve the size the slot needs (srcset, sizes), a modern format with a fallback, and compress. For fonts, web.dev's font guide says font-display: optional has a short block period and no swap, so a late font is skipped and cannot shift the layout, while swap shows fallback text at once and swaps later. It also notes size-adjust in @font-face can bring a fallback font closer to the web font's size, reducing CLS at the swap.

Layout stability: reserve space

Every CLS fix says "tell the browser how big this will be before it arrives". Web.dev's CLS guide recommends width and height or aspect-ratio for images and video, min-height or aspect-ratio for ad and embed slots, placeholders for late content, and animating transform rather than layout properties.

.gallery { aspect-ratio: 4 / 3; }      /* hero space exists before the image loads */
.reviews { min-height: 320px; }        /* illustrative: reserve the widget's expected size */
.promo-slot { min-height: 56px; }      /* illustrative: a banner gets a slot, filled or empty */
.drawer { transform: translateX(100%); transition: transform 200ms; } /* transform, not left/top */

Main-thread work, long tasks and third parties

The main thread runs your JavaScript and the browser's style, layout and paint work. Long tasks delay input handling (INP's first phase), delay painting the LCP element after its resource has loaded, and raise TBT. Web.dev's INP guide recommends yielding so input can be handled between chunks of work (it names setTimeout), avoiding forced layout, and keeping the DOM small. The Event Loop and the Main Thread explains why a task cannot be interrupted.

Third-party scripts (tags, reviews, chat, A/B tests) share that thread and network. Treat each as a design decision with an owner, a loading strategy, a reserved slot if it renders UI, and a way to switch it off.

A performance budget is a design artefact

A performance budget is a set of agreed limits on what affects speed. Web.dev's budget guide names three kinds (quantity-based limits on bytes and counts, milestone timings, rule-based scores) and advises combining quantity limits with user-centric metrics, setting them per page type, and enforcing them in the build and after launch. When a change breaks the budget, you optimise something, remove something, or do not add it.

Every figure in this table is illustrative; set yours from your own field data.

Quantity budgets warn early in CI; metric budgets are the truth but need field data. Use both.

Measuring in the browser

The browser exposes data through the Performance Timeline: register a PerformanceObserver for an entry type and it calls you as entries are recorded (MDN). Use type with buffered: true to also receive entries recorded before the observer existed; entryTypes cannot be combined with buffered. The relevant types are "largest-contentful-paint", "layout-shift" and "event" (plus "first-input"). Support differs by browser and evolves, so test PerformanceObserver.supportedEntryTypes at runtime; MDN marks LayoutShift as limited availability.

// Minimal LCP observer: the last entry received is the current candidate.
if (typeof PerformanceObserver !== "undefined" &&
    PerformanceObserver.supportedEntryTypes.includes("largest-contentful-paint")) {
  let lcp = null;
  new PerformanceObserver((list) => {
    const entries = list.getEntries();
    lcp = entries[entries.length - 1];
  }).observe({ type: "largest-contentful-paint", buffered: true });

  addEventListener("visibilitychange", () => {
    if (document.visibilityState === "hidden" && lcp) {
      console.log("LCP (ms):", lcp.startTime, "element:", lcp.element, "url:", lcp.url);
    }
  });
}

This teaches the API but is incomplete. Web.dev's LCP page lists what a correct version must handle: stopping at the first tap, scroll or key press, bfcache restores (not reported by the API, though LCP should be measured), and prerendered pages (measure from activationStart). CLS and INP are harder: summing layout-shift entries that lack hadRecentInput is not CLS, because CLS uses session windows, and INP needs Event Timing entries grouped by interactionId. Use the web-vitals library (npm install web-vitals), which implements these rules: call onLCP, onINP, onCLS or onTTFB with a callback, as in the pipeline code below. Each callback gets a metric object with name, value, rating ("good", "needs-improvement" or "poor"), delta, id (unique per page view and metric, for de-duplication), entries and navigationType. At the time of writing the README documents version 5; onCLS is Chromium only, while onFCP, onINP, onLCP and onTTFB work in Chromium, Firefox and Safari. A web-vitals/attribution build adds an attribution property that breaks LCP and INP into the parts described above, to find causes.

A small real-user monitoring pipeline

Collecting numbers is easy. The design questions are what to send, how much, where, and how to turn it into a percentile.

Figure 4. A real-user monitoring pipeline for the product page

How to read this: dashed arrows are fire-and-forget. The page never waits for the collector, and the collector never waits for the aggregator.

1. Collect. Record name, value, rating, id and navigationType, plus the dimensions you will slice by: page template (/product/:slug, not the raw URL), device class, release. Send no personal data.
2. Sample. Decide once per page view, so a visit reports a coherent set. A low rate saves cost; a high rate gives rare segments enough data.
3. Send with navigator.sendBeacon. It queues a small POST that the browser delivers without delaying unload. MDN says the reliable moment is when visibilityState becomes "hidden"; unload is unreliable and defeats the bfcache. Queued data is limited to 64 KiB (MDN).
4. Aggregate by percentile. Store counts in value buckets (histograms) per template and day, and compute p75 from merged buckets. Never average percentiles.
5. Alert when p75 passes the "good" threshold, per template and device class.

import { onCLS, onINP, onLCP, onTTFB } from "web-vitals";

const SAMPLE_RATE = 0.1; // illustrative: report one page view in ten

if (Math.random() < SAMPLE_RATE) {
  const queue = [];

  const enqueue = ({ name, value, rating, id, navigationType }) => {
    queue.push({ name, value, rating, id, navigationType, template: "/product/:slug" });
  };

  const flush = () => {
    if (queue.length === 0) return;
    navigator.sendBeacon("/rum", JSON.stringify(queue.splice(0)));
  };

  onLCP(enqueue);
  onINP(enqueue);
  onCLS(enqueue);
  onTTFB(enqueue);

  document.addEventListener("visibilitychange", () => {
    if (document.visibilityState === "hidden") flush();
  });
}

JSON.stringify gives a string, so the server parses the text body as JSON. The README's batching example flushes on the same event. Check in the field that the final INP and CLS values arrive, and deduplicate by id on the server.

A tiny percentile example with illustrative LCP values in seconds for five visits: 1.5, 1.8, 2.0, 2.6, 3.9. By the nearest-rank method p75 is the value at rank ceil(0.75 x 5) = 4, which is 2.6 s and misses the 2.5 s target; the mean, 2.36 s, looks like a pass. Percentile tools differ in method, so state yours. For histograms and alerting on user-visible symptoms, see observability and SLOs: the Core Web Vitals targets act as front-end service level objectives.

Talking about performance with product teams

Performance is a product decision with a cost, so use the product's terms.

• Speak in visits, not milliseconds. "Three in four product-page visits show the main photo within 2.5 seconds" is understood by everyone.
• Make trade-offs explicit. A new widget costs bytes, main-thread time and layout space; ask it to fit the budget, or for something else to leave. A promo banner needs a reserved slot; a tracking tag needs an owner and a switch.
• Do not promise a ranking or revenue result. Say what you will measure and show the numbers.

In practice: speeding up an online store's product page

The situation

An online store has a React single-page application, owned by a team of eight. Field data shows product-page LCP at p75 of 3.6 s and CLS of 0.18 (both illustrative); INP is good. Lighthouse in CI looks healthy, because the CI machine is fast and the lab run never receives the marketing team's A/B tests.

Starting architecture

Figure 5. Starting architecture: the browser builds the page after the JavaScript arrives

How to read this: the hero image's URL is in the JSON from the API, so the browser cannot request it until the bundle has run and the API has answered.

The HTML is an empty shell, so image discovery is late (a large resource load delay), and the reviews widget is injected with no reserved slot, pushing "Add to basket" down.

Options considered

The decision

Rollout and verification

1. Ship the RUM pipeline (Figure 4) first, tagged by template and release, for a baseline.
2. Serve the server-rendered route to a small share of traffic and compare p75 between groups; watch TTFB.
3. Add budget checks and a Lighthouse run to CI, and review the LCP attribution parts weekly.

The 2 a.m. failure

At 02:00 an A/B test published through the tag manager injects a promo banner above the product title for some visitors. CI stays green because the lab run never receives the experiment. The RUM alert on CLS p75 for the product template crosses the "good" threshold within hours. First checks: filter by release and device, read the sources of the layout-shift entries to see which element moved, and check the tag manager's change log. Mitigation: use the tag's kill switch, then relaunch with a reserved slot. Follow-up: add budget review to the tag release process and a lab test with experiments enabled.

Architect's notes

• Fix the measurement first: metrics, percentile, device segments and page templates shape what you collect.
• Make the LCP element a conscious choice per template: what it is, where it is discovered, who owns it.
• Reserve space by rule: any late-arriving element gets a slot of known size.
• Budget and own third parties, and give each a switch.
• Defer micro-tuning until field data says where the time goes.

Common mistakes

• Trusting Lighthouse alone. One simulated visit is not your audience.
• Reporting averages. They hide the slow tail; use p75 and histograms.
• Lazy-loading the hero image, which adds load delay to LCP.
• Images without dimensions, so layout shifts when they arrive.
• Sending data on unload. Use visibilitychange with sendBeacon.
• Treating TBT as INP, or averaging percentiles instead of merging counts.

Key takeaways

• Three Core Web Vitals at the time of writing: LCP, INP and CLS; INP replaced FID in 2024.
• Judged at p75 of page loads, by device class: good is LCP 2.5 s or less, INP 200 ms or less, CLS 0.1 or less.
• LCP has four parts: first byte, load delay, load duration, render delay. Find the largest first.
• TTFB, FCP and TBT are diagnostics; TBT is lab, INP needs field data.
• Lab finds causes, field shows truth.
• Most wins are architectural: discoverable, prioritised hero image; cacheable HTML; reserved space; less main-thread work; owned third parties.
• A budget is a decision rule: quantity limits warn early, metric targets are the truth.
• Use web-vitals, send on visibilitychange with sendBeacon, aggregate counts into percentiles.

Practice exercises

Exercise 1 — Starter (30 min): In Chrome DevTools, find the LCP element of a page you know and guess which of the four LCP parts is largest. Check with a Lighthouse run.

Exercise 2 — Intermediate (2 hours): Add web-vitals to a small page and log the metrics. Throttle network and CPU, add an image without width and height, and observe LCP and CLS. Fix it and repeat.

Exercise 3 — Intermediate (2 hours): Write a one-page performance budget for a page type you own, marking which lines CI enforces and which need field data, with an owner for each.

Exercise 4 — Advanced (half day): Build the Figure 4 pipeline locally: a page that sends sampled metrics by sendBeacon to a small endpoint that stores histogram buckets, and a script that prints p75 per template.

Related reading

In this course:

• Frontend Requirements: Users, Devices and Networks — turning wishes into testable requirements and a budget.
• The Critical Rendering Path — how bytes become pixels, and what blocks what.
• The Event Loop and the Main Thread — how work is scheduled on the one main thread.
• HTTP Caching for the Front End — which responses the browser keeps, and for how long.
• Rendering Strategies: CSR, SSR, SSG, ISR and Streaming — where and when HTML is produced.

Elsewhere on the site:

• System Design: Observability and SLOs — percentiles, histograms, SLIs and user-visible alerting.
• System Design: Caching Basics — the server side of caching behind a fast first byte.
• System Design: CDN and Object Storage — edge caching for HTML and images.
• How a Browser Actually Works — the processes and threads inside a browser, and the path of a navigation.
• Frontend System Design: The Big Picture — the course overview.

Official documentation

• web.dev: Web Vitals — the Core Web Vitals, the 75th-percentile guidance and the INP and FID history.
• web.dev: Lab and field data differences — why Lighthouse and CrUX disagree.
• web.dev: Optimize Largest Contentful Paint — the four LCP parts and their fixes.
• MDN: PerformanceObserver.observe() — type, buffered and entry types.
• GitHub: GoogleChrome/web-vitals — the library, metric objects and the attribution build.
• MDN: Navigator.sendBeacon() — beacons and the visibilitychange pattern.