skip to content

A page's main visual is applied as a CSS background-image from an external stylesheet, and it arrives late enough to delay the page's largest paint. Why does marking that request urgent not fix it on its own, and what actually shortens the delay?

level: seniorimportance: should knowfreq 44%

answer

  1. two delays, not one
  2. the scanner reads markup only
  3. the request does not exist yet
  4. stylesheet, then match, then fetch
  5. fix discovery first, rank second

basics

~20 s

Priority ranks requests the browser already knows about; it cannot rank one that has not been discovered. A CSS background image is invisible to the preload scanner and is requested only after the stylesheet downloads, parses, and an element matches — so the fix is shortening that discovery chain, with priority as the follow-up.

solid answer

~50 s

There are two separate delays and they need different fixes. Priority addresses *queueing*: given a set of known requests, which goes first. This image's problem is *discovery*: it is not in the markup, so the scanner that runs ahead of the parser never sees it. The request is only created after the stylesheet has been fetched and parsed and layout has matched an element to the rule — a serial chain of three round trips before the image is even asked for. Raising the priority of a request that does not exist yet changes nothing. The real fix is to shorten the chain: put the visual in the markup as an `<img>` so the scanner finds it in the first bytes of HTML, or declare it in the head so it is requested while the CSS is still downloading. Once it is discovered early, a priority signal is worth adding so it does not sit behind the rest of the page's work.

code

html · 8 lines
html
<!-- Late: the URL lives in CSS, so the preload scanner never sees it.
     Request order is HTML -> stylesheet -> style resolution -> image. -->
<link rel="stylesheet" href="/app.css">
<div class="hero"><!-- .hero { background-image: url(/hero.jpg) } --></div>

<!-- Early: the URL is in the markup, found in the first bytes of HTML,
     requested while the stylesheet is still downloading. -->
<img class="hero" src="/hero.jpg" width="2000" height="1000" alt="Product on a desk">

go deeper

for a junior

Know that the browser can only fetch a URL it has found, and that URLs written inside a stylesheet are found later than URLs written in the HTML.

for a middle

Explain the preload scanner and the serial chain behind a CSS background image — stylesheet fetch, parse, rule match, then the request — and why no ranking applies during that window.

for a senior

Separate discovery from queueing out loud, name which fix addresses which, and say how you would verify on a throttled, cold-cache load rather than a fast local one.

for a principal

Push upstream of the individual fix: decide whether the team's component conventions keep producing late-discovered critical media, and what convention or check would stop the pattern recurring.

## Two different clocks When a resource arrives late, ask which of two delays you are looking at. **Discovery delay** — how long between the navigation starting and the browser *deciding to request* the file at all. Nothing can be prioritised during this window, because from the browser's point of view the request does not exist. **Queueing and transfer delay** — from the moment the request exists to the moment its bytes are in. Priority operates here, and only here. Developers reach for priority reflexively because it is the visible knob, but a resource that is discovered a second late cannot be rescued by moving it two places up a queue it has not joined. ## Why a CSS background image is discovered so late Browsers run a **preload scanner**: a lightweight pass over the raw HTML bytes that finds URLs and starts fetching them even while the main parser is blocked. It is one of the biggest wins in modern loading — but it only reads *markup*. A URL that exists only inside a stylesheet is invisible to it. So the chain for `.hero { background-image: url(hero.jpg) }` is strictly serial: 1. Fetch and parse the HTML far enough to find the stylesheet link. 2. Fetch the stylesheet — one round trip, plus a connection setup if it is on another origin. 3. Parse the CSS and build style rules. 4. Match a rule to an element and lay it out, establishing that the background actually applies to a box on screen. 5. *Only now* issue the image request. That is three dependent network steps before the image starts. Each is subject to its own queueing, and on a slow connection each may be hundreds of milliseconds. The image then still has to download. The same shape catches fonts. A font declared with `@font-face` in a stylesheet is not requested when the CSS is parsed — it is requested when the browser determines that some element about to be painted actually needs that face. Stylesheet, then style resolution, then the font. Fonts are ranked high once requested, which disguises the fact that the request itself started late. ## What actually fixes it In rough order of preference: **Move the resource into the markup.** If the visual is content — and the page's largest painted element usually is — express it as an `<img>` rather than a decorative background. The scanner finds it in the first packets of HTML, before the stylesheet has even arrived. This is nearly always the biggest single improvement, and it comes with responsive-source and alternative-text benefits as a side effect. **If it must stay a background, declare it early in the document head** so the request is issued from the markup pass rather than after style resolution. That collapses steps 2 through 5 above into a request that starts alongside the CSS instead of after it. **Shorten the chain rather than reordering it.** A stylesheet on a third origin adds connection setup before the CSS even downloads; a stylesheet that imports another stylesheet which contains the rule adds a further serial hop. Chains like that dominate the timeline and no priority signal touches them. **Then, and only then, consider priority.** Once the request is being issued early, it is competing with everything else the page discovered early — and now the ranking genuinely decides who waits. This is where an explicit signal earns its place. ## How to tell which delay you have Open a throttled load and look at when the request *starts*, not only how long it takes. - A request that starts late and transfers quickly is a discovery problem. Trace what had to complete first; you will usually find a stylesheet or a script in front of it. - A request that starts early and sits with a long queueing period before any bytes move is a contention problem, which is priority's actual domain. - A request that starts early and transfers slowly is a size or delivery problem — the wrong format, no compression, a far-away origin — and neither discovery nor priority is the lever. The request-chain view is the fastest way to see this: it draws the serial dependency, which is exactly the thing you are trying to shorten. ## The judgment to bring to an interview The answer an interviewer is listening for is that you separate *when a request is made* from *how it is ranked*, and that you know which tool addresses which. A candidate who says "mark it urgent" has one tool; a candidate who says "it is not requested until the CSS has been parsed and matched, so first get it into the markup where the scanner sees it, then rank it" has the model. The corollary is worth saying out loud too: after you make the change, verify on a throttled connection with an empty cache, because on a warm local load the stylesheet is instant and the entire chain you just fixed is invisible.

  • How would you confirm from a waterfall that you are looking at a discovery problem rather than contention?
    Look at the request's start time relative to navigation, not its duration. A discovery problem shows a long gap before the request appears at all, with a visible predecessor — usually the stylesheet — finishing just before it. Contention shows an early start followed by a long wait before bytes move. The request-chain view makes the serial dependency explicit.
  • Does the same late-discovery problem affect fonts, and does their high ranking save them?
    It affects them, and the high ranking does not save them. A font in an @font-face rule is requested only once style resolution shows a painted element needs that face, which is after the stylesheet has arrived and been parsed. Ranking applies from that late moment onward, so the font is fetched promptly but started late — the delay is upstream of priority entirely.
  • When would you leave the visual as a CSS background rather than converting it to an img element?
    When it genuinely is decoration rather than content — a texture, a gradient overlay, a pattern that carries no information — or when the design swaps it per breakpoint in ways markup would make clumsy. Decoration should not be the largest painted element in the first place, so the late-discovery cost is acceptable there.
  • After the resource is discovered early, what is a reasonable expectation for what a priority signal adds?
    A useful but smaller second-order win. Discovery typically buys you a round trip or more; ranking buys you a place in a queue against other early-discovered requests. It is worth doing on the one resource the largest paint depends on, and it becomes measurable exactly when the connection is busy — which is why you evaluate it under throttling.

saying these in an interview costs you the question

  • Thinks a priority hint can speed up a request the browser has not made yet
  • Assumes the preload scanner finds URLs inside stylesheets
  • Believes CSS background images are requested as soon as the CSS is parsed
  • Says fonts are fine because they are ranked high, ignoring when they are requested
  • Verifies the fix only on a fast local load with a warm cache

context

resolving links…