A page can feel quick on a developer's laptop and painfully slow on a mid-range phone. That gap is why we start performance work with a measurement from the people using the site.
Start with a specific journey
Pick a page and an action: opening a product page, searching a catalog, or completing checkout. Record the device, connection, geography, and whether the visitor is signed in. “The site is slow” is hard to fix; “product images arrive four seconds after the title on mobile” gives the team somewhere to look.
Google's Core Web Vitals cover loading, responsiveness, and visual stability. Use field data where it exists. Lighthouse is useful for finding a cause, but its controlled run cannot tell you how every customer experiences the page.
Trace the delay backwards
For a slow first render, inspect the network waterfall. Is the server late to respond? Is a large hero image blocking the largest visible element? Is a font or script delaying paint? For a slow interaction, record what happens after the click. A fast API is little comfort when a large JavaScript task freezes the browser.
Fix one bottleneck, deploy it, and compare the same journey again. A smaller image might improve loading while an aggressive lazy-loading rule makes the first screen worse. Measurement catches that tradeoff.
Keep the result visible
Track the important journeys over time and review them after releases. Performance decays when new widgets, analytics, and images arrive without anyone checking the cost. A budget is useful only if someone owns it and the team knows what to do when it is exceeded.
Further reading: Core Web Vitals workflows.
