Field data vs lab data
This tool calls Google’s PageSpeed Insights API and shows two different kinds of numbers. Keep them apart, because they answer different questions.
- Field data comes from the Chrome UX Report: real Chrome users visiting the page over the last 28 days, reported at the 75th percentile. This is what Google’s Core Web Vitals assessment uses.
- Lab data comes from one Lighthouse run on a simulated device. It’s repeatable and shows what to fix, but it isn’t what your visitors experienced.
The three Core Web Vitals
- Largest Contentful Paint (LCP): when the biggest image or text block appears. Good is 2.5 seconds or less.
- Interaction to Next Paint (INP): how quickly the page responds to taps, clicks and key presses. Good is 200 ms or less. It needs real users, so the lab shows Total Blocking Time as a stand-in.
- Cumulative Layout Shift (CLS): how much content jumps around while loading. Good is 0.1 or less.
The performance score (0–100) is a weighted mix of lab metrics. 90 or more is good; 50–89 needs work.
What usually fixes a slow page
- The LCP image. Serve it at the right size in WebP or AVIF, don’t lazy-load it, and consider
fetchpriority="high". - Render-blocking CSS and scripts. Defer non-critical JavaScript and inline only the CSS needed for the first screen.
- Third-party scripts. Chat widgets, tag managers and A/B testing tools are common causes of poor INP. Load them late, or drop the ones you don’t use.
- Layout shift. Set width and height on images and reserve space for ads and embeds. The image alt checker lists images missing dimensions.
- Server response. A slow Time to First Byte delays everything. Caching and a CDN usually fix it.
The “What to fix first” list in your results is Lighthouse’s own estimate of time saved per fix, sorted largest first. Fix one thing, re-test on mobile, and repeat.