Page speed

Measure two ways. A lab tool such as Lighthouse loads the page once on a simulated device and reports seconds. Field data comes from real visits, through the Chrome User Experience Report or your own RUM, and is reported at the 75th percentile. Name the metric, for example 'LCP 2.3 s at p75', not 'the page loads in 2 seconds'.

The browser exposes the pieces through the Performance API: `navigation` entries carry `responseStart` and `loadEventEnd`, and `paint` entries carry first paint and first contentful paint. The `load` event alone is a poor summary, because it waits for images far below the fold that nobody has scrolled to.

A recipe blog on shared hosting tests at TTFB 1.4 s, FCP 2.6 s, and LCP 4.8 s on mobile, with onload at 9 s because of an auto-playing video embed. The owner reads 'nine seconds' and panics. Visitors actually see the photo and ingredient list at about 4.8 s.

Moving to a host with full-page caching drops TTFB to 300 ms and LCP to 2.4 s. Onload stays near 8 s because of the video. By the measures that matter, the page got twice as fast while the old headline number barely moved.

Page speed is the general experience. Core Web Vitals is Google's specific set of three measures with pass thresholds: LCP, INP, and CLS. A page can load quickly and still fail on layout shift, so 'fast' in conversation covers more than a Vitals pass and less than a full audit.

Quoting the onload time as the speed. Testing once from a wired laptop. Mixing lab and field numbers in one chart. Averaging instead of using a percentile. Testing only the homepage. Treating a Lighthouse 95 as proof that real visitors on cheap phones are fast.

Pick three URLs: the homepage, your top landing page, and a contact or checkout page. Record TTFB, LCP, and INP for each, from field data if you have it and PageSpeed Insights if not. Fix the slowest metric on the slowest page first, and re-test after a week of traffic.