Vocabulary for Web Performance Optimization: LCP, CLS, TTFB, and Beyond
Master the English vocabulary of web performance — Core Web Vitals, LCP, CLS, TTFB, hydration, bundle splitting, and the terms every frontend engineer needs to know.
Web performance is no longer just a nice-to-have — it directly affects search ranking, conversion rates, and user experience. If you work in frontend engineering, full-stack development, or technical SEO, you need to know this vocabulary fluently.
The challenge is that web performance terminology mixes acronyms (LCP, CLS, TTFB), borrowed concepts (hydration, bundling), and measurement vocabulary (percentiles, budgets, waterfalls) that can be confusing even for native English speakers.
This guide explains the essential vocabulary precisely, with the context you need to use these terms correctly in technical discussions, audit reports, and performance review meetings.
Core Web Vitals
Google’s Core Web Vitals are the official set of metrics measuring user experience quality. They are the foundation of performance vocabulary.
1. LCP — Largest Contentful Paint
Pronunciation: /el siː piː/ (spell it out)
LCP measures how long it takes for the largest visible content element to render on the screen — typically a hero image, a large heading, or a video thumbnail. It represents the moment when the page feels “loaded” to the user.
Good threshold: Under 2.5 seconds Needs improvement: 2.5 - 4.0 seconds Poor: Over 4.0 seconds
What affects LCP:
- Server response time
- Render-blocking resources (CSS, JavaScript)
- Resource load time (large images, web fonts)
- Client-side rendering
Usage: “Our LCP is at 3.8 seconds on mobile — just outside the ‘good’ threshold. The culprit is the hero image, which is a 2MB WebP that isn’t preloaded.”
2. CLS — Cumulative Layout Shift
Pronunciation: /siː el es/
CLS measures visual stability — how much the page layout unexpectedly shifts during loading. When an image loads and pushes text down, or an ad pops in and moves a button you were about to click, that is layout shift.
CLS is scored from 0 to any value — 0 means perfect stability, higher values mean more shift.
Good threshold: Below 0.1 Needs improvement: 0.1 - 0.25 Poor: Above 0.25
Common CLS causes:
- Images without explicit
widthandheightattributes - Web fonts that cause text to reflow when they load (FOUT/FOIT)
- Dynamically injected content (ads, banners, cookie notices)
- Web components that take time to initialise
Usage: “The CLS score jumped from 0.05 to 0.31 after we added the cookie consent banner — it loads after the initial render and shifts the entire header down.”
Related terms:
- Layout shift — a single instance of unexpected movement
- FOUT (Flash of Unstyled Text) — when text appears briefly in a fallback font before the web font loads
- FOIT (Flash of Invisible Text) — when text is hidden while waiting for the web font
3. INP — Interaction to Next Paint
Pronunciation: /aɪ en piː/
INP replaced FID (First Input Delay) as a Core Web Vital in March 2024. It measures the responsiveness of a page to user interactions throughout the entire page lifecycle — not just the first click, but all clicks, taps, and key presses.
Good threshold: Below 200 milliseconds Needs improvement: 200ms - 500ms Poor: Over 500ms
Usage: “Our INP on the search results page is 420ms — users are experiencing noticeable lag when typing in the search box. The main thread is being blocked by a large synchronous analytics script.”
4. FCP — First Contentful Paint
Pronunciation: /ef siː piː/
The time from navigation start to when the first piece of content appears on screen — any text, image, or non-white canvas element. FCP tells you when the page first stops feeling blank.
Not a Core Web Vital, but an important diagnostic metric.
Good threshold: Below 1.8 seconds
5. TTFB — Time to First Byte
Pronunciation: /tiː tiː ef biː/ (spell it out)
The time from a request being made to the first byte of response being received by the browser. TTFB reflects server performance, network latency, and CDN effectiveness.
Good threshold: Below 800 milliseconds
Usage: “Our TTFB from US locations is 120ms, but from Southeast Asia it’s over 900ms — we don’t have an edge node in that region.”
What affects TTFB:
- Server processing time (database queries, application logic)
- Network latency (physical distance)
- CDN coverage
- DNS resolution time
Rendering and JavaScript Terms
6. Hydration
Pronunciation: /haɪˈdreɪʃən/
In server-side rendered (SSR) or statically generated frameworks (Next.js, Nuxt, Astro), hydration is the process of attaching JavaScript event handlers to already-rendered HTML, making it interactive.
During hydration, the page looks rendered but is not yet interactive — a user who clicks a button before hydration completes may see no response.
Usage: “The page is rendering in 1.2 seconds but users are reporting a 3-second delay before buttons work — the hydration is taking longer than the initial render.”
Related terms:
- Partial hydration — hydrating only the interactive components, leaving static content un-hydrated (Astro’s islands architecture)
- Progressive hydration — hydrating components in priority order as the user needs them
- Hydration mismatch — when the server-rendered HTML differs from what React (or another framework) expects, causing a full re-render
7. Bundle Splitting / Code Splitting
Dividing a JavaScript bundle into smaller chunks that are loaded on demand, rather than sending all JavaScript at once. This reduces the amount of JavaScript the browser needs to parse and execute before the page is interactive.
Usage: “We implemented route-level code splitting — each page now loads only the JavaScript it needs. The main bundle dropped from 1.2MB to 380KB.”
Related terms:
- Chunk — one of the smaller pieces produced by bundle splitting
- Dynamic import — the JavaScript mechanism (
import()) used to load a chunk on demand - Tree shaking — removing unused code from a bundle
- Dead code elimination — synonym for tree shaking
8. Critical Rendering Path
The sequence of steps the browser takes to render a page: HTML parsing → DOM construction → CSS parsing → CSSOM construction → render tree → layout → paint. Resources that block this path are render-blocking.
Usage: “That third-party analytics script is render-blocking — it’s sitting in the <head> without defer or async, holding up the entire critical rendering path.”
Related terms:
- Render-blocking resource — CSS or synchronous JavaScript that pauses rendering
asyncattribute — loads script without blocking; executes when readydeferattribute — loads script without blocking; executes after HTML parsing
9. Lazy Loading
Loading resources (images, JavaScript modules, iframes) only when they are needed — typically when they enter or approach the browser viewport. Reduces initial page load time.
Usage: “We added loading="lazy" to all below-the-fold images — it reduced the initial resource count from 45 requests to 12.”
10. Preloading / Prefetching
- Preload (
<link rel="preload">) — tell the browser to download a resource early because it will definitely be needed soon. Used for fonts, hero images, critical scripts. - Prefetch (
<link rel="prefetch">) — tell the browser to download a resource in the background because it might be needed for the next navigation. - Preconnect (
<link rel="preconnect">) — establish a connection to an origin early, before a resource from that origin is requested.
Usage: “We added a preload hint for the hero image — LCP improved by 400ms because the browser starts fetching it during HTML parsing rather than waiting for the CSS to be processed.”
Measurement and Tooling Vocabulary
11. Performance Budget
A set of limits on performance metrics or resource sizes that a team commits to not exceeding. Examples:
- “LCP must stay below 2.5 seconds”
- “Total JavaScript below the fold must not exceed 200KB”
- “No single third-party script may block rendering”
Usage: “Our performance budget is set in the CI pipeline — a PR that increases the bundle size by more than 5KB requires a performance review before merging.”
12. Waterfall (Network Waterfall)
A visual representation of all network requests made during page load — showing when each request starts, how long it takes, and how it relates to others. Available in browser DevTools and tools like WebPageTest.
Usage: “Looking at the waterfall, the font loads are cascading — the browser doesn’t discover the font until after the CSS is parsed, which is too late.”
13. Percentile (p50, p75, p95, p99)
Performance metrics are measured at percentiles, not just averages. The p75 LCP means that 75% of real-user page loads have an LCP at or below that value.
Google recommends measuring Core Web Vitals at the 75th percentile.
Usage: “Our p75 LCP is 2.1 seconds, which is in the ‘good’ range. But the p95 is 5.8 seconds — there’s a long tail of very slow loads we need to investigate.”
14. Field Data vs Lab Data
- Field data (also: Real User Monitoring / RUM) — performance measured from actual users’ devices in the real world. Reflects true user experience.
- Lab data — performance measured in a controlled, simulated environment (Lighthouse, WebPageTest). Reproducible but may not reflect real conditions.
Usage: “Lighthouse gives us a lab score of 92, but our field data from the CrUX report shows we’re in the ‘needs improvement’ range for LCP — real users on slower connections are experiencing something different.”
15. CrUX — Chrome User Experience Report
Pronunciation: /kruːks/ (like “crux”)
A public dataset of real-world performance data collected from Chrome users who have opted in to sharing. Used by Google’s PageSpeed Insights and Search Console to assess Core Web Vitals in field data.
Usage: “Our CrUX data shows 78% of page loads achieve ‘good’ LCP. We need to get that above 90% to be confident in our standing.”
Key Takeaways
- LCP (Largest Contentful Paint) measures perceived load speed — target under 2.5 seconds.
- CLS (Cumulative Layout Shift) measures visual stability — target below 0.1.
- INP (Interaction to Next Paint) measures responsiveness — target under 200ms.
- TTFB measures server and network speed — target under 800ms.
- Hydration is the attachment of JavaScript to server-rendered HTML — slow hydration means a page that looks ready but is not interactive.
- Bundle splitting and lazy loading reduce the initial JavaScript and resource cost.
- Always measure performance at real-user percentiles (p75), not just lab averages.
- Field data (CrUX, RUM) tells you what users actually experience; lab data is for diagnosis and regression testing.
Web performance vocabulary is the shared language between engineering, product, and SEO teams. Mastering it lets you participate fully in performance discussions and write clear audit reports.