Performance is a feature, and a quietly decisive one — it shapes whether people stay, whether they convert, and how the site feels to use. But "make it faster" is not actionable until you know what is slow, and that requires understanding the path between a request leaving the browser and something useful appearing on screen. The good news is that this path is well understood and measurable, and there is now a shared vocabulary — the Core Web Vitals — for talking about it. This is a practical tour of where the time goes and how to get it back.
What has to happen before you see anything
Recall the render pipeline: the browser parses HTML into the DOM, parses CSS into the CSSOM, combines them into a render tree, lays out where everything goes, and paints. The time-to-first-useful-paint is dominated by whatever blocks that pipeline.
Two blockers are worth knowing cold. CSS is render-blocking: the browser will not paint content until it has processed the stylesheets, because it does not want to flash unstyled text and then restyle it. And a plain script in the document head is parser-blocking: the browser pauses building the DOM while it fetches and executes the script. The practical implications are direct — keep critical CSS small and delivered early, and load scripts with async or defer (or at the end of the body) so they do not hold up the first paint.
Send less, sooner
Almost every performance technique reduces to one of two moves: transfer fewer bytes (compression, minification, image optimisation, code splitting) or transfer the important bytes earlier (prioritising critical CSS, preloading key assets, using a CDN to shorten the distance). Hold those two levers in mind and most advice sorts itself.
The Core Web Vitals
To make "fast" measurable, Google defines a small set of user-centred metrics called the Core Web Vitals. Each has a published "good" threshold, measured at the 75th percentile of real page loads:
| Metric | Measures | "Good" threshold |
|---|---|---|
| Largest Contentful Paint (LCP) | Loading: when the largest visible element has rendered | 2.5 seconds or less |
| Interaction to Next Paint (INP) | Interactivity: responsiveness across all interactions on the page | 200 milliseconds or less |
| Cumulative Layout Shift (CLS) | Visual stability: how much content unexpectedly moves | 0.1 or less |
A note on that middle row: INP became a Core Web Vital in March 2024, replacing the older First Input Delay (FID). The change matters because FID only measured the delay before the first interaction was processed, whereas INP looks at responsiveness across a page's whole lifetime — a better proxy for how snappy a page actually feels.
Loading: improving LCP
LCP asks a simple question: how long until the biggest thing in the viewport — often a hero image or a headline block — is drawn? The usual culprits are a slow server response, render-blocking resources delaying the paint, and large images that take too long to download. The fixes track the "send less, sooner" principle: compress and correctly size images, serve them in efficient formats, preload the LCP image, trim render-blocking CSS, and put a CDN in front so bytes travel a shorter distance.
Interactivity: improving INP
INP measures the lag between a user action — a tap, a click, a keypress — and the next frame the browser can paint in response. When it is poor, the cause is almost always the main thread being busy: long-running JavaScript blocks the single thread the browser uses for both scripting and rendering, so input sits in a queue. The remedies are to do less work on the main thread (break up long tasks, defer non-urgent work, ship less JavaScript) and to avoid layout thrashing. Interactivity problems are ultimately main-thread scheduling problems.
Visual stability: improving CLS
CLS captures a specific frustration: you go to tap a button and the page jumps because an image or ad loaded above it and pushed everything down. It is measured as how much visible content shifts unexpectedly. The fixes are concrete and cheap: always reserve space for images and embeds by specifying their dimensions, avoid inserting content above existing content, and be careful with web fonts that reflow text when they swap in.
A short, high-leverage checklist
Checklist
0/6
Practical takeaway
Web performance is not a bag of tricks so much as a single idea applied repeatedly: understand the path from request to paint, then remove whatever blocks it and shrink whatever crosses it. Measure with the Core Web Vitals so "fast" becomes three concrete numbers — LCP for loading, INP for responsiveness, CLS for stability — and let those numbers point you at the specific stage that needs work. Start by measuring real page loads rather than guessing; the bottleneck is often not where intuition says it is, and the render pipeline (covered in what happens when you type a URL) tells you where to look.
Sources & Further Reading
- 01Web Vitals — web.dev (Google)Definitions and 'good' thresholds for the Core Web Vitals.
- 02Interaction to Next Paint (INP) — web.dev (Google)The interactivity metric that replaced FID as a Core Web Vital in March 2024.
- 03Critical rendering path — MDN Web DocsHow render-blocking resources delay the first paint.
- 04Web performance — MDN Web DocsA broad, practical reference on measuring and improving performance.
Editorial note — A practical explainer. The Core Web Vitals thresholds cited (LCP 2.5s, INP 200ms, CLS 0.1) and the March 2024 INP-for-FID change are Google's published definitions, linked in the sources; no site-specific measurements or benchmark results are claimed.
