Frontend Performance Vocabulary

LCP (Largest Contentful Paint) — thresholds

LCP measures the time until the largest visible content element (image, heading, or block of text) appears in the viewport.

Google's Core Web Vitals thresholds:

LCP	Rating
Under 2.5s	Good
2.5s – 4.0s	Needs Improvement
Over 4.0s	Poor

4.1 seconds = Poor — above the 4-second threshold. Research shows that conversion rates drop significantly for every additional second of LCP beyond 2.5 seconds.

Professional phrasing:

• "LCP is [X]s — in the 'Good/Needs Improvement/Poor' range."
• "We need to reduce LCP from [X]s to under 2.5s to meet Core Web Vitals targets."
• "LCP is dominated by the hero image — we should lazy-load or preload it."

Describing bundle optimisation professionally

The model answer includes:

1. Relative improvement: 77% reduction — the most impactful framing (1.38/1.8 × 100)
2. Absolute values: 1.8 MB → 420 KB — concrete and verifiable
3. Technique explanation: code splitting and tree shaking — brief, accurate
4. User impact: "improve Time to Interactive on slow connections" — connects the engineering metric to user experience

Key bundle performance vocabulary:

• Code splitting: dividing the bundle into chunks loaded on demand, not all at once
• Tree shaking: removing exported functions/modules that are never imported (dead code elimination)
• Lazy loading: deferring the load of non-critical resources until they're needed
• Time to Interactive (TTI): when the page becomes fully interactive

Bundle size vocabulary:

• "The initial bundle is [X] KB — we should target under [Y] KB."
• "Code splitting reduced the initial load from [X] to [Y]."

CLS (Cumulative Layout Shift) — what it measures and why it matters

CLS measures visual stability — how much the page layout shifts after content starts loading.

Thresholds:

CLS	Rating
Under 0.1	Good
0.1 – 0.25	Needs Improvement
Over 0.25	Poor

0.31 = Poor. Common causes:

• Images and iframes without explicit width/height — browser reserves no space until they load
• Late-injected ads or banners that push content down
• Fonts causing text reflow (FOUT — Flash of Unstyled Text)

Plain English explanation for non-technical stakeholders: "The page moves around as it loads — users click a button and a second later it jumps to a different position. This causes misclicks and frustration."

CLS vocabulary:

• "Our CLS is [X] — we need to reduce it below 0.1."
• "Adding explicit image dimensions eliminated the CLS from the hero image."
• "Font loading is contributing to layout shift — we should use font-display: swap."

TTFB (Time to First Byte) — what it measures

TTFB is the time from the browser making a request to receiving the first byte of the HTML response. It measures:

• Network latency (the round trip time to the server)
• Server processing time (how long the server takes to generate the response)

Breakdown of a 980ms TTFB: A typical network RTT to a nearby server is 20–50ms. If the full TTFB is 980ms, approximately 930ms is server-side processing — application code, database queries, or external API calls.

Good TTFB target: Under 200ms for server-rendered pages. Under 100ms is excellent. Over 600ms is poor.

TTFB improvement approaches:

• Add caching at the application layer (Redis, in-memory)
• Use a CDN for static and edge-cached content
• Optimise slow database queries in the critical path
• Add edge functions to generate responses closer to users

Vocabulary:

• "TTFB of [X]ms suggests slow server-side processing."
• "After adding Redis caching, TTFB dropped from 900ms to 80ms."

Presenting Lighthouse improvements in a sprint review

The professional presentation connects the score change to:

1. Category shift: from 'Poor' to 'Good' — the human significance of the number
2. Contributing changes: LCP improvement, JS reduction, CLS fix — the engineering work that produced the result
3. Real user validation: CrUX (Chrome User Experience Report) — lab scores don't always reflect real-user experience

Lighthouse score ranges:

Score	Rating
0–49	Poor
50–89	Needs Improvement
90–100	Good

Important caveat about Lighthouse: It is a lab tool run in controlled conditions. Real user metrics (CrUX, RUM) are what Google uses for ranking. Always validate Lighthouse improvements against real-user data.

Vocabulary:

• "Lighthouse score improved from [X] to [Y] — [category change]."
• "Lab data shows [improvement] — we're monitoring field data to confirm."