Summary

  • W3C’s 2013 Resource Priorities draft proposed lazyload and postpone as ways to influence download order. Its 2014 Working Group Note said the specification had been abandoned.
  • A later WICG Priority Hints report was retired after its relevant work moved into HTML and Fetch. Today’s fetchpriority offers high, low, or auto relative to resources with the same destination; Fetch keeps a separate browser-controlled internal priority.

The browser’s queue has a familiar social problem. Everybody who wrote the page thinks their resource is important. The hero image is genuinely central to the first screen. The animation below the fold can wait. Yet network capacity, device memory and competing requests all arrive at once, and markup order is an unreliable seating plan. A publisher knows the editorial hierarchy of the page. A browser knows the conditions under which the page actually loads. For years, standards authors tried to make these two kinds of knowledge speak to each other.

The W3C First Public Working Draft of 29 October 2013 called its proposal Resource Priorities. It described programmatic hints about download priority, including lazyload and postpone. The former asked a user agent to treat a resource as lower priority under contention; the latter concerned delaying work until an element entered or approached the viewport. The draft also explored a CSS property. Its introduction argued that the order in the document might be a poor guide to perceived page value. That is the moment the queue became an editorial question: the first file on the page need not be the first file the reader needs.

The proposal had a short life in that form. The 23 October 2014 Working Group Note announces, unusually plainly, that the Web Performance Working Group had abandoned it and would no longer maintain it. It directs readers toward resource hints. The Note retained discussion of lazyload, while the earlier postpone section had disappeared. This is a useful historical dead end, not a hidden implementation manual for the present web. The old attributes and today’s priority attribute have different documents and different contracts.

A separate document trail later gave the browser a narrower note. The WICG Priority Hints report of 22 February 2023 describes a signal of relative priority for the browser to consider when fetching. Its own page now calls the report obsolete because the relevant material was merged into the HTML and Fetch standards. The report’s retirement therefore tells a different story from the W3C Note’s abandonment. One project stopped; another moved its operative text into the core specifications. The public records establish that distinction. They do not establish a straight inheritance line from the 2013 proposal to the present attribute.

The HTML Living Standard gives fetchpriority three values: high, low, and auto. Each describes a priority relative to other resources with the same destination. A missing or invalid value becomes auto. This small phrase about destination matters. A page author cannot turn every request into a universal first-class passenger by writing high; the signal is scoped. The attribute is a way to tell the browser that one known resource deserves different attention among its peers.

The Fetch Living Standard exposes the line of authority underneath. A request has a priority of high, low, or auto, with auto as the ordinary default. It also has a distinct internal priority, which may be an implementation-defined object. The page can send a note. The browser keeps machinery that is not reducible to that note. That division makes practical sense when a device is busy, the network changes, or several earnest publishers all mark their own resources urgent.

Imagine a news page that gives its lead image a high hint while placing decorative images lower in the same image queue. The author supplies context the browser cannot read from pixels it has yet to fetch. The browser can weigh that context against its own schedule. The standards say how the signal is expressed; the five records here do not measure whether a particular site became faster or which browser honored a particular hint on a particular day. The durable invention is more modest and more useful: a channel for urgency that leaves the queue in the browser’s hands.