Performance problems look different when you factor in traffic

When we started looking at performance, we did what most people do:

we focused on the worst-performing pages.

If a page had bad Core Web Vitals, it went to the top of the list.
Once we started looking at real user performance data alongside traffic, that approach stopped making sense.

What we noticed:

• Some pages were very slow, but barely anyone visited them

• Other pages looked "okay" from a Core Web Vitals perspective, but had a lot of traffic

• Small regressions on those high-traffic pages affected far more users than the truly slow ones

In other words, the slowest page wasn't always the biggest problem.

Performance issues turned out to be more about impact than extremes. A page that's slightly slower but used by thousands of users can matter more than a page that's very slow and rarely visited.

In practice, this meant that pages with decent performance but a lot of traffic surfaced as higher priority than very slow pages that almost nobody visited:

Once we started weighting Core Web Vitals by usage, our prioritization changed. We began scoring pages based on a mix of performance metrics and actual traffic, instead of looking at performance in isolation. That pushed us away from fixating on the worst scores and toward fixing issues that affected the most people.

We've been collecting real user Core Web Vitals alongside analytics in Betterlytics, and seeing performance and traffic together made this pattern obvious.

Curious how others prioritize performance work:
Do you still start with the worst-performing pages, or do you factor in usage and impact as well?