A team marks about a dozen of a page's requests as high priority. The page gets no faster and one metric drifts slightly worse. Why does promoting everything fail, and what would you do instead?

## Priority is a ranking, not a resource The single sentence that explains the failure: **promoting a request does not create bandwidth, it borrows bandwidth from another request.** A page's connection carries what it carries. Ranking decides the order in which that fixed capacity is spent. So consider what "everything is urgent" actually produces. Twelve requests all sitting at the top rank must still be served in *some* order, decided by whatever tiebreaks remain — discovery order, connection availability, response size. That order is close to what you would have had anyway, minus the browser's own judgment. A flat ranking carries no information, exactly like a bug tracker where every ticket is P0. ## The second failure: throwing away good defaults The first failure is a no-op. The second is an actual regression, and it is why a metric can move the wrong way. The default model demotes things on purpose. Offscreen images, `async` scripts, background data fetches and next-navigation prefetches are ranked low *because nothing visible waits on them*. That demotion is doing useful work: it keeps the pipe clear for the handful of resources that gate the first paint. When a team sweeps through and marks everything urgent, those deliberate demotions vanish. A tracking script and a footer illustration now sit alongside the hero image and the critical stylesheet. On a fast connection you will not notice. On a mid-range phone on a busy network you will, and it will show up in whichever metric depends on the resource that got crowded out. ## How to spend the budget properly Treat priority signals as a budget of two or three per page, and spend them like this. **Find the one resource the first meaningful paint waits on.** Usually one image or one font, occasionally one data fetch. Not "the important resources" — *the* resource. If you cannot name a single one, you do not yet understand the page's critical path well enough to be tuning its ranking. **Check it is discovered early before you rank it.** Ranking a late-discovered request is wasted effort; the delay is upstream of the queue. Fix discovery first. **Then look for demotion candidates, which are usually more numerous and less contentious.** Good candidates: an above-the-fold image that is decoration rather than content; a script-issued fetch for something below the fold; an analytics or experimentation request that ranks respectably by type but is not needed for the first paint; a carousel's second through tenth slides. Demoting these does not require you to decide which of your important resources is *most* important — it just widens the pipe for all of them. **Do not restate what the defaults already get right.** Marking a render-blocking stylesheet urgent moves nothing, because it is already top-ranked and there is nothing above it to overtake. The line costs you nothing at runtime and something in review time — a future reader must work out whether it is load-bearing before touching it. ## Verifying, and the trap of local testing The reason bad priority changes survive is that they are invisible on a developer machine. Fast connection, warm cache, few competing requests — no contention, so no reordering effect in either direction. Both the intended win and the accidental regression are hidden. So evaluate under throttling, with a cold cache, and preferably on field data rather than a single lab run. Two checks are worth making explicitly: - Did the resource you promoted actually start transferring sooner? - Did anything else you care about start later? This is the check teams skip, and it is where the regression lives. ## Governance, because this decays Priority annotations rot faster than most performance work. The image someone marked urgent in March is below the fold after the April redesign; the fetch that gated the first render was moved to the server. Nobody notices, because nothing breaks — the page just quietly gets slower under load. Two cheap habits help. Keep the total count small enough that a reviewer can hold it in their head, and treat every added signal as requiring a one-line justification of *what it is beating*. "This image is the largest thing on screen and must beat the below-fold gallery" is a claim someone can later check and delete. "High priority — important" is not. The underlying principle generalises beyond this one attribute: any signal whose value comes from being scarce loses all of it when applied broadly. A page where everything is urgent has communicated exactly as much as a page where nothing is.