Part 12 · 8 chapters · ~60 min

Performance, Measured

Every earlier part explained a mechanism; this one is how to know which mechanism is costing you, for which users, and whether a fix held. The metrics and what each stands for, LCP in four phases and INP in three, where layout shift comes from, field versus lab and the APIs under both, how to read a Performance trace lane by lane, budgets that stop a win decaying, and one investigation worked end to end.

118

What to measure: the metrics and what each one stands for

the question

"The page feels slow. Which number do we look at, and what is it actually measuring?"

Each performance metric is a proxy for one user experience: is anything happening, is the main thing visible, can I use it, did it jump around. The Core Web Vitals are three of these, chosen because they are measurable in the field across all pages; the rest are diagnostics that explain them.

MetricMeasuresGood / poor (p75)Field?Stands for
TTFBNavigation start to first byte of the response< 800 ms / > 1800 msYesServer and network; the floor under everything else
FCPFirst text or image painted< 1.8 s / > 3 sYes"Something is happening"
LCPRender time of the largest image or text block in the viewport< 2.5 s / > 4 sYes (CWV)"The main thing is here"
CLSSum of unexpected layout shift scores in the worst 5 s window< 0.1 / > 0.25Yes (CWV)"It did not jump under me"
INPWorst interaction latency, input to next paint< 200 ms / > 500 msYes (CWV)"It responds when I touch it"
TBTSum of long-task time over 50 ms between FCP and TTI< 200 ms / > 600 msLab onlyA proxy for input delay
Long Animation FramesFrames over 50 ms with script attributionDiagnosticYesWhy INP is bad: which script
Frame rate / dropped framesCompositor frames missed during scroll and animation60 fps targetLab mostlySmoothness
what the definitions hide
  1. LCP's candidate changes as the page loads: text, then a hero image, then a bigger image. Only the final candidate counts, and it stops being updated at first input. An LCP element that is a background image counts; a video poster counts; a low-entropy image (a huge near-blank placeholder) is excluded since 2023.
  2. CLS counts only unexpected shifts: a shift within 500 ms of a user input is excused. It is a windowed sum (sessions of up to 5 s with 1 s gaps), so a slow drip of small shifts can score worse than one early jump.
  3. INP is a percentile of interactions, not the average: the worst one, or p98 for pages with over 50. Hover and scroll are not interactions; clicks, taps and key presses are. A page with one slow autocomplete has a poor INP regardless of everything else.
  4. p75: Google judges a page by the 75th percentile of its field distribution. A quarter of users can be worse and the page still passes; the median is not the target.
119

LCP in four phases

A slow LCP is one of four different problems, and the fix for each lives in a different place. The web-vitals attribution build and the Performance panel both break LCP into these phases; reading them is the first step of every LCP investigation.

the phases
  1. Time to first byte. Owned by infrastructure: DNS, connection, CDN, origin compute. Fixes are caching the HTML at the edge, streaming the response early (flush the head before the data query finishes), preconnect hints, HTTP/3, a faster origin. Nothing in the page's JavaScript affects this phase.
  2. Resource load delay. The gap between TTFB and the start of the LCP resource's fetch. In a healthy page this is near zero because the preload scanner found the image in the HTML. It is large when the image is a CSS background, inserted by JavaScript, marked lazy, or rendered by a client-side component after hydration. The fix is discoverability: an <img> in the HTML with fetchpriority="high", or a preload link.
  3. Resource load time. The fetch itself. Owned by bytes and priority: right-sized via srcset, modern format, served from a warm CDN on a preconnected origin, and high priority so it is not queued behind a dozen scripts.
  4. Element render delay. The resource arrived but the element was not painted: the main thread was busy (a long task from the bundle), render-blocking CSS was still loading, or the element was hidden until a framework mounted it. The fix is less blocking work before paint: defer scripts, inline critical CSS, server-render the hero.
text LCP
  1. When the LCP element is a heading or paragraph, phases 2 and 3 are about the web font: font-display: swap or optional so the text paints in a fallback, with a metric-matched fallback so the swap does not shift; preload the font file.
  2. Render delay for text is render-blocking CSS and script before first paint.
the lens
Performance panel → record a load → click the LCP marker in the Timings track → the summary shows the element and a phase breakdown. In the field, onLCP(cb, { reportAllChanges }) from web-vitals/attribution gives attribution.timeToFirstByte, resourceLoadDelay, resourceLoadDuration, elementRenderDelay, and the element selector. Send those to analytics, not just the LCP number.
THE FOUR PHASES OF LCP
where a 4.2 s LCP actually went
swipe the figure sideways, or tap expand for full screen
1/6
the number
LCP is the render time of the largest image or text block in the viewport. 4.2 s here. The number alone says "slow". The phases say why.
120

INP in three phases

Interaction to Next Paint replaced First Input Delay because FID only measured the delay before a handler ran, and most slow interactions are slow inside and after the handler. INP measures to the next frame that shows the result, which is what the user perceives.

the phases
  1. Input delay. From the input event to the handler starting. Caused by whatever is already on the main thread: a long task, a previous interaction's work, a third-party script's timer. Fix: break up long tasks (scheduler.yield(), setTimeout chunks, isInputPending), move work to workers, defer third parties, avoid timers that fire during interaction.
  2. Processing duration. The handlers themselves, all of them for this event, plus any synchronous rendering they trigger (a framework's synchronous re-render) and forced layouts they cause. Fix: do less; update the visible state and yield before the rest; avoid layout reads between DOM writes; batch state updates; use a framework's transition or deferred-value APIs for the non-urgent part.
  3. Presentation delay. After the last handler returns: style recalc, layout, paint, compositing of the frame. Caused by large invalidation scopes (changing a class on the root), many nodes, expensive paint. Fix: contain and content-visibility, smaller DOM, cheaper styles on the changed path, compositor-only animations.
worked numbers
the shape of a fast handler:

  on input:
    1. change what the user must see this frame (pressed state, count, the typed character)    < 16 ms
    2. await scheduler.yield()   (or setTimeout 0; or requestAnimationFrame + setTimeout for the frame after paint)
    3. do the rest: filter the list, recompute, send analytics, re-render the table

  the user sees step 1 immediately. INP measures to the end of step 1's frame. step 3 still happens.

in React: startTransition / useDeferredValue do step 2 for you. in a keystroke filter over 10k rows, that is the whole fix.
finding the bad interaction
  1. Field: onINP(cb) from web-vitals/attribution reports interactionTarget (a selector), interactionType, and the three phase durations, plus the Long Animation Frame that contained it with its script attribution. Aggregate by target: the top three targets are the work.
  2. Lab: Performance panel, Interactions track: each interaction as a bar, colour-coded, with the phases on hover; click it and the main thread below shows exactly what ran.
  3. Common culprits: keystroke handlers that filter synchronously; click handlers that re-render whole lists; third-party scripts with 50 ms timers; forced layout in a scroll or resize handler; hydration finishing during the first tap.
AN INTERACTION, DECOMPOSED
input delay, processing, presentation delay
swipe the figure sideways, or tap expand for full screen
1/6
380 ms
The user taps "Add to cart". INP for this interaction is 380 ms: tap to the frame that shows the cart count change. Poor is over 200 ms. The three phases say which part.
121

CLS: finding the shift

the causes, in frequency order
  1. Images and embeds without dimensions. The box is zero height until bytes arrive, then everything below moves. Fix: width and height attributes, or aspect-ratio, on every img, video, iframe and ad slot.
  2. Content injected above existing content. Banners, cookie notices, "app install" bars, late-loading headers. Fix: reserve the space, or overlay instead of insert, or insert below the fold.
  3. Web fonts swapping. A fallback font with different metrics renders, then the web font arrives and every line reflows. Fix: metric-matched fallback via size-adjust / ascent-override; preload the font; font-display: optional for non-critical fonts.
  4. Dynamic content without placeholders. A recommendations widget that pops in; a comment count; a price that arrives after the product. Fix: skeletons with the final dimensions.
  5. Animations of layout properties. Animating height, top, margin moves neighbours every frame; each frame is a shift. Fix: transform.
  6. Late-arriving CSS. Content renders unstyled, then styled. Fix: critical CSS inline, no render-blocking stylesheet arriving late.
finding it
  1. Field: onCLS(cb) with attribution gives largestShiftTarget, largestShiftTime, and the sources. Group by target.
  2. Lab: Performance panel → Layout Shifts track; click a shift to see the elements that moved, their before and after rects, and the score. Rendering → Layout Shift Regions paints them blue live.
  3. The 500 ms rule: shifts within half a second of a click or tap are excluded. An accordion opening is fine. A shift 600 ms after a click, because the content it opened loaded slowly, is counted.
122

Field versus lab, and the Performance APIs underneath

Two sources of truth that disagree by design. Lab tools answer "why is this slow" for one scenario. Field data answers "how slow is it, for whom" across every scenario. The job is to use each for its question.

field
  1. CrUX. Chrome's public dataset: per origin and per URL, 28-day rolling p75 for CWV, split by device and connection. Through PageSpeed Insights, the CrUX API, BigQuery, and Search Console. Chrome users only, opted-in, no logged-in-only pages with low traffic.
  2. Your own RUM. The web-vitals library (attribution build) sending to your analytics with the page, the element, the phases, device memory, connection type, and whether the view was a bfcache restore or a prerender activation. The only way to see your own segments: logged-in users, a specific flow, a specific country.
  3. Sampling and percentiles. Report distributions, not averages: p50, p75, p95. Averages hide the tail that the metric is about.
lab
  1. Lighthouse. One run, simulated throttling by default (fast run, modelled slowdown), a score, and audits with pointers. Reproducible enough for CI with several runs averaged.
  2. The Performance panel. The trace: every task, every frame, every request, with the Web Vitals lane, Interactions lane, Layout Shifts lane, and an insights sidebar that reads the trace for you (LCP phases, render-blocking requests, third parties, forced reflows).
  3. WebPageTest. Real devices and real networks, filmstrips, waterfalls, repeat view, scripting for logged-in flows. The best lab tool for a specific question about a specific condition.
the APIs the tools are built on
  1. PerformanceObserver with entry types: navigation (the full navigation timing), resource (every fetch with timing and size), paint (FP, FCP), largest-contentful-paint, layout-shift, event and first-input (interaction timing), longtask, long-animation-frame (with script attribution: which function, from which URL, how long), element (opt-in per element).
  2. User Timing: performance.mark and measure for your own milestones ("search results rendered"), visible in the Performance panel and reportable to the field. The way to measure the thing your product actually cares about.
  3. Server Timing: a response header the server adds (Server-Timing: db;dur=53, cache;desc="miss") that surfaces in the Network panel and in resource entries. Backend timing in the browser's view.
  4. performance.now(): monotonic, sub-millisecond (coarsened unless cross-origin isolated).
FIELD VERSUS LAB
two different questions, two different tools
swipe the figure sideways, or tap expand for full screen
1/6
lab
Lab: Lighthouse on your laptop, throttled to simulate a mid phone on 4G. One run, one URL, cold cache, no login, no interaction beyond load. It produces a trace you can read line by line. It cannot see your users.
123

Reading a Performance trace

The Performance panel is the one tool that shows everything this course has described, in time order, for one page load or interaction. Reading it is a skill: knowing which lane answers which question and what the colours mean.

the lanes, top to bottom
  1. Overview: CPU usage over time, screenshots filmstrip, network bars. Find the region to zoom into.
  2. Timings: the vital markers (FCP, LCP, DCL, L) and your User Timing marks. Click LCP for the element and phases.
  3. Interactions: each interaction as a bar; hover for phases; whisker lines show input delay and presentation delay.
  4. Layout Shifts: each shift; click for the moved elements.
  5. Network: every request as a bar: light part is waiting, dark is download; left line is queued time. Render-blocking resources are marked. Priority on hover.
  6. Frames: each frame with its duration; red for dropped; partially presented in yellow.
  7. Main: the flame chart of the main thread. Yellow is script (Evaluate Script, function calls by name), purple is rendering (Recalculate Style, Layout, Pre-Paint), green is painting (Paint, Composite Layers), grey is tasks, blue is parse HTML. Red triangles mark long tasks and forced reflows.
  8. Other threads: compositor, raster, workers, the network thread. A worker's work appears in its own lane.
  9. Insights sidebar: the panel's own reading: LCP by phase, LCP request discovery, render-blocking requests, forced reflows with stacks, third-party summary, DOM size, font display, CLS culprits.
the questions and where they are answered
  1. Why is LCP late? Timings → LCP marker → phases. Then Network for the resource, Main for what blocked rendering around that time.
  2. Why is this click slow? Interactions → the bar → Main underneath it: the handler's frames, then any purple and green after it.
  3. What is this long task? Click it; the Bottom-Up tab groups time by function; Call Tree shows the stack top-down; the source link opens the file. Source maps make this readable for production bundles.
  4. Is there a forced reflow? Red triangle on a Layout inside a script frame; the Summary tab shows the stack that forced it.
  5. Is the animation on the compositor? Frames lane steady at 60 with the Main lane idle means yes. Purple and green every frame means no.
  6. Who is this third party? Insights → Third parties, or the Bottom-Up tab grouped by domain.
capture settings that matter
CPU throttling 4× to approximate a mid-range phone; network throttling to the field's p75 connection; "Disable JavaScript samples" off so you get function names; "Enable advanced paint instrumentation" only when debugging paint (it slows everything). Record with the device and conditions of the users you are trying to help, not your laptop.
124

Budgets, regressions, and keeping a win

Performance work decays. Every feature adds bytes and tasks, and no single addition is the one that made it slow. A budget turns the aggregate into a line that a pull request cannot cross without someone deciding to cross it.

what to budget
  1. Bytes on the critical path: JavaScript and CSS needed before first paint and first interaction, compressed. Checked by the bundler's output (size-limit, bundlesize, webpack-bundle-analyzer in CI).
  2. Total page weight per route, by resource type.
  3. Lab metrics under a fixed device and network profile: LCP, TBT, CLS, via Lighthouse CI with assertions, several runs, median.
  4. Request counts and render-blocking requests: a new blocking stylesheet or sync script is a regression even at 2 KB.
  5. Custom marks: "time to first search result" measured via User Timing in an end-to-end test against the staging build.
how to run it
  1. Fail the PR, with the number, the delta, and the trace or bundle diff attached. A failure a developer can act on in five minutes gets fixed; one that needs a meeting gets overridden.
  2. Allow raising the budget in the same PR with a reason in the diff. The point is visibility, not prohibition.
  3. Track history (Lighthouse CI server, or a dashboard from the CI artefacts) so a slow drift is visible even when no single PR failed.
  4. Close the loop with field data monthly: the budget guards the lab proxy; the field number is the outcome. If they diverge, the lab profile is wrong and needs updating to match the p75 user.
  5. Own third parties: every tag goes through a review that records its cost, its loading strategy (after interaction, in a worker via Partytown, or not at all), and an owner who can remove it.
worked numbers
a starting budget for a content or commerce site, mid-range mobile profile:

  critical JS       ≤ 150 KB compressed
  critical CSS      ≤ 50 KB compressed (critical inline ≤ 14 KB)
  page weight       ≤ 1 MB on first view
  LCP              ≤ 2.5 s   TBT ≤ 200 ms   CLS ≤ 0.1
  render-blocking   no new ones
  third-party JS    ≤ 100 KB, none before interaction-ready

adjust to your field p75 device. the numbers matter less than the existence of a line.
A PERFORMANCE BUDGET IN CI
the only way a win survives
swipe the figure sideways, or tap expand for full screen
1/6
the win
Week 0: a team ships an LCP fix. 3.4 s to 2.1 s. Celebration.
125

An investigation, end to end

A worked example that uses everything above, in the order a real one goes.

the report
  1. Search Console says the product detail page template has poor INP on mobile (p75: 410 ms) and needs-improvement LCP (2.9 s). Desktop is fine. The RUM dashboard agrees and adds: INP is worst on Android mid-range devices; the top interaction target is button.add-to-cart; the top LCP element is img.hero; LCP load delay averages 900 ms.
reproduce
  1. Performance panel, CPU 4×, network Fast 3G, a real product URL, logged in as a user with a cart. Record load, then tap add-to-cart, then stop.
  2. LCP marker: element is the hero img; phases: TTFB 600 ms, load delay 950 ms, load time 700 ms, render delay 200 ms. Load delay confirmed. Network lane: the hero image request starts 950 ms after the HTML arrives, with Low priority. The image is inserted by the product gallery component after hydration.
  3. Interactions lane: add-to-cart 430 ms: input delay 120 ms (a long task from recommendations.js running at the moment of the tap), processing 260 ms (the handler dispatches to the store; the whole page re-renders synchronously; a forced reflow in a sticky-header hook that reads getBoundingClientRect after the DOM update), presentation 50 ms.
fix
  1. LCP: server-render the hero img with srcset and sizes, fetchpriority="high", width and height; the gallery component hydrates around it. Load delay goes to ~0; expected LCP ≈ 1.6 s in the same profile.
  2. INP input delay: load recommendations after the first interaction or on idle (requestIdleCallback with a timeout), and chunk its processing with scheduler.yield().
  3. INP processing: the handler updates the cart badge and button state, then startTransition for the store update that re-renders the rest; the sticky-header hook moves its layout read into a ResizeObserver so it no longer forces a reflow inside the update.
  4. Verify in lab: re-record; INP 90 ms, LCP 1.5 s in the same profile.
  5. Guard: add a budget assertion for the template (TBT ≤ 200 ms, LCP ≤ 2.5 s under the profile) and a size-limit on the critical bundle.
  6. Verify in field: after 28 days, CrUX p75 INP 180 ms, LCP 2.2 s. The RUM dashboard shows the change the day it shipped.
go to the lab
  1. Route /perf/lcp-phases: four variants of a hero with the LCP phases dominated by each cause. Record each; match the phase to the cause before reading the source.
  2. Route /perf/inp-phases: a product page with an add-to-cart that has all three problems. Fix them one at a time with the provided toggles; watch the Interactions bar shrink.
  3. Route /perf/cls-hunt: five shift sources. Use the Layout Shifts lane to attribute each.
  4. Route /perf/rum: a page wired to web-vitals attribution that logs to a table. Interact, navigate back (bfcache), and read what was reported for each.