"The site feels slow" is one of the least useful sentences in software. Performance work only gets done when you replace feelings with numbers — and then watch those numbers over time. This guide covers the metrics that matter, how to read the two very different kinds of data about them, where the time usually goes, and how to set up a monitoring loop so that speed stops being an opinion and becomes a property the team owns.
The metrics that actually matter
Google's Core Web Vitals give you a shared language: Largest Contentful Paint for loading, Interaction to Next Paint for responsiveness, and Cumulative Layout Shift for visual stability. These map closely to how a real person experiences your page — did the main thing appear quickly, did the page respond when I tapped it, did things jump around while I was reading.
The thresholds are worth committing to memory, because they are what the field data is graded against: LCP at or under 2.5 seconds, INP at or under 200 milliseconds, CLS at or under 0.1. And they are measured at the 75th percentile of real visits, not the average — which means the quarter of your users having the worst time are the ones who decide whether you pass.
Note that INP replaced First Input Delay in March 2024. If your monitoring or your internal dashboards still report FID, they are measuring something Google no longer uses. INP is a harder test: it looks at the latency of every interaction across the visit, not just the first one, so slow menus and sluggish filters now count against you where they used to hide.
Why it matters beyond the ranking
Core Web Vitals are a search ranking signal, and that is usually what gets the budget approved. But the business case is stronger than the SEO case. Slow pages convert worse — every additional second of load time costs measurable sales, sign-ups and form completions, and the effect is steepest on mobile where most traffic lives. Slow interactions make a product feel untrustworthy. A page that shifts under a reader's thumb causes mis-taps, and a mis-tap on a checkout page is a lost order. Performance is a user experience property first; the ranking is a consequence.
Lab data vs field data
Lab tools like Lighthouse give you a controlled, repeatable score: same device profile, same throttling, same result twice in a row. That makes them excellent for diagnosis and useless for knowing how bad the problem actually is.
Field data — the Chrome User Experience Report, or your own real-user monitoring — tells you what is happening on the messy devices and networks your customers actually use. It is noisy, it lags by weeks, and it is the only thing that reflects reality.
You need both, and you need to keep their jobs separate. Field data decides what to work on. Lab data tells you why it is slow and whether your fix worked. Teams that skip the field half end up optimising a page that was already fast for everyone except the people on a four-year-old Android on a train.
Where the time usually goes
After enough audits the same handful of causes come up again and again:
- Images that were never sized for the web. A 3000px hero scaled down in CSS still downloads every one of those pixels. Modern formats and correct intrinsic dimensions usually reclaim more than any JavaScript work will.
- Render-blocking resources in the head. Every stylesheet and synchronous script there is a gate the first paint has to wait behind.
- Fonts with no fallback strategy. A web font that blocks text rendering turns a fast page into a blank one for as long as the download takes.
- Layout shift from elements with no reserved space. Images without width and height, ads, and late-injected banners all push content around after the reader has started reading. This is the cheapest vital to fix and the most commonly ignored.
- Third-party tags nobody owns. Analytics, chat widgets, heatmaps and pixels accumulate over years, and each one runs on your main thread. They are almost always the largest single win, and almost always the hardest politically.
- Too much JavaScript. A bundle that is fine on a laptop takes seconds to download, parse and run on a mid-range phone, and every long task it creates shows up in INP.
- Slow servers and no caching. Time to first byte sets the floor under every other metric. A slow database query on the page template, or a CDN that is not caching, delays everything downstream.
The fixes, in the order that pays
For LCP: find the largest element above the fold — usually a hero image or a heading waiting on a font — and make it arrive faster. Serve the image in a modern format at the size it is displayed, preload it, and do not lazy-load it. Preload the font the heading needs and use a swap strategy so text renders immediately. Get the server response time down with caching at the CDN. Remove anything render-blocking that the first paint does not need.
For INP: find the long tasks. Break up heavy JavaScript, defer what is not needed for interaction, move work off the main thread, and make sure event handlers do their visual update first and their heavy work after. Audit third-party scripts and remove the ones nobody can name an owner for.
For CLS: give every image, video, embed and ad slot explicit dimensions. Load fonts so they do not reflow text. Never insert content above what the user is already reading unless they asked for it.
A practical monitoring toolchain
- Lighthouse and PageSpeed Insights for lab audits, run on the pages that matter rather than the homepage only
- Search Console's Core Web Vitals report for the field view Google actually uses, grouped by page type
- Real-user monitoring for field vitals, segmented by device class, connection and country
- Performance budgets in CI, so a regression fails the build instead of being discovered a quarter later
- Alerting when a key vital crosses a threshold, pointed at a person rather than a channel
- A monthly review of third-party scripts, with an owner named for each or the script removed
Setting a performance budget
A budget is a set of limits a page must stay within: total JavaScript under a certain size, LCP under a certain time on a throttled mobile profile, no more than a fixed number of third-party requests. The numbers matter less than the existence of the line, because the line is what turns "this made the page a bit slower" into a failed check someone has to answer for. Set the budget from where the site is today plus a small margin, tighten it as fixes land, and enforce it in the build with Lighthouse CI or an equivalent. A budget nobody enforces is a wish.
What to do first if everything is red
Start with the pages that earn money or generate leads, not the homepage. Fix images and layout shift first — they are usually a day of work and move two of the three vitals. Then remove or defer third-party scripts, which is usually the largest INP win. Then tackle the JavaScript bundle and the server response time, which take longer. Re-run the field data after each step; it lags, so be patient, and resist optimising the lab score for its own sake.
Make it somebody's job
The reason performance decays is rarely ignorance. It is that speed is everyone's concern and nobody's responsibility, so it loses every prioritisation conversation to a feature with a named owner. A budget enforced in CI works because it moves the argument from after the fact to before the merge, where it is cheap.
Give one person ownership of the numbers — not of doing all the work, but of watching the field data, raising regressions and keeping the budget honest. Put the vitals on a dashboard the whole team sees. Review them in the same meeting where features are prioritised, so the trade-off is visible when it is being made.
Frequently asked questions
What is a good Core Web Vitals score?
Passing means LCP at or under 2.5 seconds, INP at or under 200 milliseconds and CLS at or under 0.1, each measured at the 75th percentile of real visits. Search Console reports whether each group of pages passes. A high Lighthouse score is encouraging but is lab data; the field numbers are what count.
How often should we check performance?
Continuously. A performance budget in CI checks every change, real-user monitoring watches production all the time, and a person reviews the field data monthly. A one-off audit finds problems; the loop stops them coming back.
Why is Lighthouse fast but real users slow?
Lighthouse runs on one simulated device and network. Real users are on a spread of phones, connections and locations, and the 75th percentile of that spread is far slower than the lab. Field data from Search Console or real-user monitoring shows the gap; lab data helps explain and fix it.
Performance is a feature, and like any feature it needs owners and a feedback loop. We help teams put that loop in place so speed stops being an afterthought.