A browser fetches a page's stylesheets, scripts and images in a different order from the one they appear in the HTML source. What is a request priority, and what does the browser do with it?
answer
- download order is not source order
- limited pipe, many requests
- type first, then where it sits
- only matters under contention
- reordering, never extra bandwidth
basics
~20 sA request priority is the browser's internal ranking of how urgently it thinks each resource is needed. Bandwidth and connections are limited, so the browser issues and services top-ranked requests first — download order follows that ranking, not markup order.
solid answer
~50 sEvery request a page makes gets an internal priority from the browser, derived mostly from what kind of resource it is and where it sits in the page. That ranking decides two things: which queued requests actually go out first when more are pending than the browser will run at once, and on a multiplexed connection, which responses the browser asks the server to favour when they compete for the same bandwidth. So a stylesheet in the `<head>` beats a decorative image far down the page even if the image tag was parsed first. The important consequence for a developer is that priority only *reorders* work — it never creates bandwidth. Promoting one request necessarily pushes something else back, which is why priority is a tool for the two or three resources that genuinely gate the first paint, not a page-wide setting.
go deeper
Be able to say that the browser ranks every request and fetches by that ranking rather than by source order, and give the obvious example: a render-blocking stylesheet outranks a decorative image.
Explain the two inputs the default ranking uses — resource type and position in the page — and be precise that priority reorders requests rather than adding bandwidth, so a promotion always demotes something else.
Show that you know priority only pays off under contention, and that you test on a throttled connection rather than trusting a fast local load. Be ready to say when you would leave the browser's defaults alone.
Frame it as a scarce budget: a page has room for two or three deliberate priority decisions before the signal goes flat. Own the question of how a team keeps those decisions correct as the page changes.
## The problem priority solves A typical page asks for dozens of files: HTML, one or more stylesheets, several scripts, fonts, images, plus whatever third-party tags are on the page. They cannot all arrive at once. The connection has a finite throughput, and the browser will only keep so many requests in flight at a time. Something has to decide which bytes travel first. That decision is the **request priority**: a ranking the browser assigns to each resource, expressing how urgently that resource is needed to show the user something useful. The user never sees it and you rarely set it, but it is running on every page load. ## Why markup order is not fetch order It is tempting to think of the browser as reading the HTML top to bottom and downloading each referenced file as it goes. Two things break that model. First, the browser scans ahead. While the main parser is blocked — waiting on a synchronous script, for example — a lightweight scanner keeps reading the raw markup looking for URLs it can start early. So requests are often *discovered* out of order relative to where the parser has actually got to. Second, once discovered, requests are ranked, not queued first-in-first-out. Two inputs dominate the ranking: - **Resource type.** A stylesheet that blocks rendering is worth more than a picture. Fonts and blocking scripts sit high; images and asynchronously loaded scripts sit low, because nothing waits on them to produce a first paint. - **Position and context.** Where the reference appears in the document, and — for images — whether the element turns out to be in the part of the page the user can see without scrolling. The upshot is that a `<link rel="stylesheet">` in the head outranks an `<img>` earlier in the byte stream, and an offscreen image stays low no matter how early it was written. ```html <head> <link rel="stylesheet" href="/app.css"> <!-- ranked at the top: nothing paints without it --> <script src="/analytics.js" async></script> <!-- ranked low: nothing waits on it --> </head> <body> <img src="/hero.jpg" alt=""> <!-- images start low, even in view --> </body> ``` ## Where priority actually bites Priority only matters under **contention** — when more requests want the pipe than can have it. On a fast, idle connection with six requests, ranking changes almost nothing; everything finishes quickly regardless. On a phone on a congested network requesting sixty things, ranking is the difference between the hero image arriving in one second or four. This is why performance work on priority pays off mostly for real users on mediocre networks, and often looks like a no-op on a developer machine with fibre and a warm cache. The mechanism is real; the conditions that expose it are not present locally. Priority operates at two levels. Locally, the browser decides which of the requests it has queued to actually open next. On a connection that multiplexes many responses over one link, the browser can also signal relative urgency to the server so the server interleaves the response bytes in a helpful order rather than round-robin. ## What priority is not Three clarifications save a lot of confused debugging. **It is not bandwidth.** Marking a request urgent does not make the file smaller or the network faster. It moves that request in front of others; those others move back by exactly as much. On an uncontended connection you may see no change at all. **It is not discovery.** A ranking can only apply to a request the browser knows it has to make. A resource the browser has not found yet — because it is referenced from inside a stylesheet or created by script — cannot be prioritised, only ranked once it finally appears. Late discovery is a different problem with a different fix. **It is not a guarantee.** Priority is an input to the browser's scheduler and, over the network, a hint to the server. Neither is obliged to honour it exactly, and engines differ in the details of how they rank. ## Where your control comes in The browser's defaults are good on average and wrong in specific, predictable cases — most often a genuinely important image that the default rules treat as ordinary, or a nice-to-have request that the defaults treat as urgent. Browsers expose an explicit way to override the ranking for a request, and the strategy question is which handful of requests deserve it. The discipline is deliberately narrow: identify the one or two resources the first meaningful paint actually waits on, make sure they are discovered early, and consider explicitly demoting the loud, non-critical requests competing with them. A page where every request is marked urgent has communicated nothing — the ranking is flat again, and you have thrown away the browser's own reasonable defaults in the process.
- If priority only reorders requests, when does changing it produce no measurable improvement at all?When there is no contention. On a fast, idle connection with few requests, everything the page needs is in flight almost immediately, so moving one request ahead of another changes finish times by milliseconds. That is why priority work often looks pointless on a developer machine and matters on a mid-range phone on a busy network — you have to test under constrained conditions to see it.
- Two images are both offscreen, but one is the first thing the user will see after a short scroll. Does priority help there?Barely. Both stay low by default and both are competing with everything above them, so reordering two low-ranked requests against each other rarely changes the user's experience. The lever for offscreen content is deciding whether to request it at all yet, not how it is ranked once requested.
- Does the browser ever change a request's priority after it has been issued?Yes. The initial ranking is made from static context — resource type and position — before layout has happened. Once the browser knows the geometry of the page it can revise, most notably raising images it now knows are visible without scrolling. The catch is that the revision necessarily arrives after layout, which for a critical image can be too late to matter.
saying these in an interview costs you the question
- Thinks the browser downloads strictly in HTML source order
- Believes raising priority makes a request download faster in absolute terms
- Assumes priority applies to resources the browser has not discovered yet
- Treats priority as a guarantee the server must obey
- Says priority is irrelevant because HTTP/2 loads everything in parallel