Problem you solve: “The site feels slow” stays an opinion until you have numbers aligned with official thresholds and field data.
What you ship in ~15 minutes: a PageSpeed Insights report (lab + field), read LCP / INP / CLS, and write down three follow-up actions.
How you know it works: you have URL, test date, and repeatable metrics (same URL, same tool → before/after comparisons).
Core Web Vitals today (2024+)
Google’s current Core Web Vitals (see web.dev/vitals):
| Metric | What it measures | “Good” (commonly cited Google threshold) |
|---|---|---|
| LCP | Largest Contentful Paint — when the main visible content renders | ≤ 2.5 s |
| INP | Interaction to Next Paint — responsiveness to input (replaced FID as a CWV) | ≤ 200 ms |
| CLS | Cumulative Layout Shift — visual stability | ≤ 0.1 |
Do not mix lab (Lighthouse simulates throttled CPU/network) with field (real users, e.g. CrUX inside PSI).
Step 1 — PageSpeed Insights
- Open PageSpeed Insights.
- Paste a public production URL (
localhostwon’t work here — use Chrome Lighthouse locally, below). - Choose Mobile and run the test.
What to read first:
- Core Web Vitals assessment (field data when CrUX has enough samples; otherwise you’ll see limited-data notices).
- Lighthouse Opportunities and Diagnostics: prioritized hints (images, JS, fonts, LCP element).
Save a PDF/screenshot: you’ll need it for regression checks after deploys.
Step 2 — Field data (CrUX) in the report
PSI shows Origin or URL field metrics when available. If you see Insufficient real-user data, it does not mean the site is fast — it only means CrUX doesn’t have enough samples for that URL/origin in the window.
Then:
- still use lab Lighthouse as a technical checklist;
- add RUM in production (below) or wait until canonical URLs accumulate traffic.
Project reference: Chrome UX Report.
Step 3 — Lighthouse locally (Chrome DevTools)
For localhost or VPN-only staging:
- Chrome → F12 → Lighthouse (or Performance for manual profiling).
- Navigation mode + Mobile device preset.
- Run; for INP, also record a Performance profile while clicking real UI (lab INP is not a substitute for field INP on SPAs).
Step 4 — Three high-leverage fixes (after the first report)
Typical order when Lighthouse flags classic issues:
- LCP: optimize the LCP image/block (responsive sizes,
fetchpriority="high"where appropriate, CDN, avoid lazy-loading the hero). - JS: cut bundle weight and third parties (analytics, chat, A/B) — often the biggest contributor to long tasks / poor INP.
- CLS: explicit dimensions for media/embeds; avoid injecting banners above content post-paint.
Re-validate by re-running PSI or Lighthouse and comparing the same headline metrics.
Optional advanced tools
- Search Console → Core Web Vitals report for URL-group trends (requires a verified property).
- RUM (e.g. analytics collecting
web-vitalsin the browser): the reliable way to see field INP on SPAs.
Library: web-vitals.
What not to do
- Do not claim revenue % per 100 ms latency without your funnel model and data — it varies wildly by industry.
- Do not chase a Lighthouse score if field CrUX is already green on LCP/INP/CLS for the URLs that matter.
Summary
- PSI on a real URL → read LCP, INP, CLS (field + lab).
- Lighthouse locally for staging/
localhost. - Ship 1–3 targeted fixes and re-measure with the same procedure.
The business “cost of a slow site” for your product is argued only after these numbers and after tying metrics to funnel data (e.g. conversion drop on pages with high INP) — not with recycled retailer anecdotes.
