How do you explain frontend performance metrics like TTI, FCP, and CLS to non technical stakeholders?

Translate metrics to user-visible experiences. FCP = 'first time anything appears.' LCP = 'main content appears.' TTI = 'page becomes usable.' INP = 'how snappy clicks feel.' CLS = 'how much things jump around as the page loads.' Tie each to a business outcome (conversion, bounce, NPS), show before/after screenshots or filmstrips, and quantify in dollars when possible. Avoid jargon; lead with the user story.

7 min read·~5 min to think through

Non-technical stakeholders (PMs, execs, designers) don't care about milliseconds — they care about whether users complete the task. Translate metrics into stories about the user's experience.

The metrics, in plain English

Metric	Plain English	Why it matters
FCP	First time the user sees anything on screen.	"Is this site loading or is it broken?"
LCP	The main thing on the page (hero image, headline) appears.	"When does the user feel the page is here?"
TTI	The page is ready for interaction (clicks, typing respond).	"Can I actually use the page yet?"
INP	How quickly UI responds after a tap/click/type.	"Does this feel snappy?"
CLS	How much stuff jumps around as the page loads.	"I tapped the right button — wait, it moved."
TTFB	How fast the server starts sending HTML.	Mostly backend; floor for everything above.

Useful analogies

FCP = the moment the curtain rises in a theater. The show hasn't started yet, but you know something's happening.
LCP = the lead actor walks on stage. Now the audience knows it's the right show.
TTI / INP = when the actor responds to you yelling something at them. Live theater, not a recording.
CLS = the stage scenery moves while you're sitting down — you trip.

Tie to business

Always pair the metric with a business outcome:

"We're at LCP 3.2s on mobile. Google's recommended threshold is 2.5s. Sites that move LCP from 3s → 2s see ~8% lift in conversion (Akamai, BBC studies). For our traffic that's roughly $X/month."
"Our CLS is 0.18 on the product page. That means a customer might tap 'Add to cart' but accidentally tap 'Save for later' because the buttons shifted. Users learn to wait, which means longer time-to-purchase and higher abandon."
"INP is 280ms — the recommended threshold is 200ms. That's the lag between tapping a filter and seeing results. Users on slow phones blame the app, not their device."

Visuals beat tables

Show, don't tell:

Filmstrip from WebPageTest: side-by-side screenshots at 200ms intervals showing the page filling in. "Here's our site, here's a competitor." Instantly persuasive.
Before/after recording after a fix.
Layout shift overlay: DevTools → Rendering → Layout Shift Regions highlights every shift.
Heatmap: where are the LCP elements across our top 20 pages?

Frame it as a budget

Stakeholders understand budgets:

"We have a 2.5-second LCP budget. Today we're 800ms over. The hero image is 600ms of that; the third-party tag manager is 300ms; the React bundle is 200ms. We can claw back 800ms by [list of fixes]. Each fix has a cost in eng-days and a benefit in projected conversion lift."

This converts perf from a vague "the site feels slow" into a prioritized roadmap with ROI.

Avoid

Jargon (TTFB, FID, CRP) without immediate translation.
Tiny precision (3.247s vs 3.198s) — they'll glaze over.
Lighthouse scores in isolation (the score is a ranking, not a user experience).
Lab metrics without real-user (RUM) data — execs trust real users, not synthetic tests.

Template you can reuse

What: "Our checkout page takes ~4s to become usable on a typical mobile phone." Why it matters: "53% of users abandon a page that takes >3s. We're losing roughly N orders/week." What we'll do: "Three changes: split the bundle (cuts ~800ms), preload the hero image (cuts ~300ms), defer the analytics script (cuts ~400ms)." What success looks like: "LCP under 2.5s on the 75th percentile of real users, measured in [tool]."

If you give stakeholders a number that maps to dollars, a visual that shows the user experience, and a plan with an ROI, you'll get buy-in for the work.

Follow-up questions

•What's the difference between lab and field (RUM) metrics?
•How do you turn LCP improvements into a dollar-value estimate?
•Which metric should you fix first if everything's bad?
•What's INP and why did it replace FID?

Common mistakes

•Leading with the metric name instead of the user experience.
•Showing Lighthouse scores instead of filmstrips.
•Quoting lab numbers (perfect WiFi, M1 Mac) — execs don't experience the page that way.
•Asking for engineering time without an ROI estimate.
•Conflating LCP and TTI — they measure different things.
•Ignoring the variance — 75th and 95th percentile matter more than median.

Performance considerations

•The biggest 'perf' win is often just clearer communication with stakeholders. Without it, the work gets deprioritized; with it, perf becomes a recurring investment line item. Cite peer-reviewed studies (Google, Akamai, BBC, Pinterest) when projecting business impact.

Edge cases

•B2B internal tools often skip user-visible perf because the audience is captive — but INP still matters for daily usability.
•Single-page apps must instrument route transitions, not just initial load.
•International audiences see vastly different metrics — geo-distributed RUM is critical.
•PWAs and repeat-visitor caching produce wildly different first-visit vs repeat-visit numbers — show both.
•Synthetic tools (Lighthouse) don't capture interactivity well — INP needs RUM.

Real-world examples

•Pinterest publicly shared that cutting wait time by 40% drove +15% sign-ups.
•BBC found 10% of users left for every additional second of load time.
•Vodafone's case study: LCP improvements +8% sales.

Senior engineer discussion

Senior engineers are translators. They keep the conversation in user language and tie metric movements to business KPIs. They also defend against the opposite failure mode — chasing Lighthouse scores instead of real user metrics. The goal is faster product, not better-looking dashboards.