Frontend performance describes how quickly and smoothly a web application loads, renders, and responds to a user's actions. It is not just about raw speed measured in the lab; it shapes user satisfaction, accessibility, search ranking, conversion rates, and the overall perception of product quality. Because users typically judge a site by how fast it feels rather than how long every byte took to download, the discipline cares about perceived performance: how soon the interface becomes useful, how stable it remains while loading, and how snappily it reacts to clicks, taps, and scrolls. This mindset leads naturally to progressive enhancement, where a useful core experience arrives first and richer behavior layers on as device and network conditions allow.
The modern measurement vocabulary centers on Core Web Vitals, a small set of signals Google treats as proxies for user experience. Largest Contentful Paint (LCP) marks when the largest visible element finishes rendering, giving a number for perceived load; a good LCP is 2.5 seconds or faster. Interaction to Next Paint (INP) measures how responsive the page feels by timing the delay between an interaction and the next visual update, replacing First Input Delay in 2024; a good INP is 200 milliseconds or less. Cumulative Layout Shift (CLS) sums unexpected movement of page elements during the lifetime of the page, capturing visual instability; a good score is 0.1 or lower.
Underneath these vitals sit several supporting metrics that explain them. Time to First Byte (TTFB) measures the round trip from request to first byte of the response and exposes network plus server-side latency. First Contentful Paint (FCP) records the first time any text, image, or non-white canvas appears, often used as an early signal that something is happening. Total Blocking Time (TBT) quantifies the total time the main thread was blocked by long tasks during load and correlates strongly with INP in lab conditions. Speed Index and the perceptual speed index add visual completeness into the picture. Together, these metrics form a shared language for performance that any team can monitor and improve.
The most powerful performance habit is treating performance as a product feature rather than a one-time cleanup project. This means setting performance budgets for bundle size, key metrics, and script weight early, and enforcing them during development rather than only auditing at the end. Shipping less code, less media, and deferring anything not immediately needed is the simplest general lever, and it tends to move every metric at once.