Start with a task, not a score
List the journeys that visitors need to complete: compare a service, request a quote, create an account or find an answer. For each journey, write its starting page, essential interaction and successful end state. A list of slow URLs becomes more useful when each issue names the task it interrupts.
The web.dev guidance explains that loading, responsiveness and visual stability describe different aspects of experience; one metric cannot capture them all. Use that distinction to choose evidence for the problem. Do not treat a better aggregate score as proof that a previously difficult task is now usable.
Record reach, severity and uncertainty
For each issue, record the affected journey, observed symptom, device or language segment, evidence date and responsible owner. Add an estimate of reach only when its source and denominator are known. Page views are not automatically the number of people who tried the affected interaction.
Describe severity in practical terms: delayed reading, repeated input, lost progress or inability to finish. Keep confidence separate from severity. A reproducible failure affecting a small group may deserve action before a widely reported but weakly understood delay. Missing segment data should appear as unknown, not zero.
Make the ordering explainable
Review the list with the people responsible for the product and delivery. Put confirmed task failures first, then weigh recurring delays against affected reach, implementation effort and change risk. This is a proposed working method, not an official search ranking formula or a universal numerical score.
Give each selected item a reason and a next action. Where the cause is uncertain, schedule a bounded investigation rather than an oversized repair. Record dependencies: two tickets may require the same shared component change, while a superficially easy fix may interfere with an essential third-party service.
Illustrative example: quote flow versus decoration
Imagine a fictional service site with two issues. A decorative animation stutters on the home page, while the quote form repeatedly freezes during a required interaction on a tested mobile device. The team first reproduces and investigates the quote problem because it blocks completion, then schedules the visual issue separately.
That choice does not claim a measured revenue gain or imply that every form issue outranks every home-page issue. The ticket states the tested device, exact interaction, visible result and evidence needed to close it. If subsequent investigation shows the form works and the symptom came from a test fault, the team revises the priority.
Close the loop with a task-level check
Before implementation, agree on an acceptance test that includes finishing the affected journey and preserving its data. After the change, repeat the recorded conditions and check nearby steps for regressions. A responsive submit button is not sufficient if the confirmation never arrives or the submitted information is wrong.
Keep the original evidence, release identifier and follow-up observation together. Review the queue when new evidence changes reach or severity; do not leave priorities fixed indefinitely. Use an audit to collect candidates, then connect each candidate to a real journey and a verifiable outcome before committing development time.