Summary

  • The W3C's first public Resource Hints draft, dated 21 October 2014, described preconnect as a clue about an origin that would be needed later. It could start name resolution, a TCP handshake and, for a secure connection, TLS negotiation before the complete resource URL was known.
  • Later Working Drafts placed preconnect alongside dns-prefetch, prefetch and prerender. The browser could attempt a full connection, do part of the work or skip the hint when local resources made speculation unwise.

The page knows that its next image will come from a particular server. Which image? That depends on a choice the visitor has not made yet. The network cannot fetch an unnamed file, but it can prepare to speak to the place that will supply it. This is the small opening that made preconnect useful. An origin can be known before a full URL, like the restaurant where the meeting will happen even though nobody has chosen dinner.

The W3C First Public Working Draft of 21 October 2014 framed preconnect as a hint from a page author or server to the user agent. It named DNS lookup, a TCP handshake and optional TLS negotiation as the work that could be moved earlier. Its companion in that first draft was preload, which concerned a resource to fetch. The difference was already visible: preconnect made a connection to an origin; it did not bring back an image, script or document just because a page had expressed a hunch.

The later 4 May 2017 Working Draft grouped four relationships: dns-prefetch, preconnect, prefetch and prerender. A DNS prefetch asks the browser to resolve a name early. A preconnect asks it to prepare a connection to an origin, potentially going through more of the handshake. A prefetch names a resource that might be needed in a future navigation and asks for an early fetch. A prerender can go further into preparing a future document. Confusing them turns a simple clue about where into an expensive guess about what.

The 27 June 2019 Working Draft gave the preconnect use case a clean shape: the full resource URL may not be known until the page is constructed, while the origin often is. Starting connection setup in that gap can remove a wait when the URL finally appears. Imagine an image gallery that knows its image host but waits for the visitor to choose a photograph. The host can be greeted early; the photograph still waits for the choice.

The browser was never obliged to greet every suggested host. The 5 October 2020 Working Draft described a full handshake, a partial handshake or no attempt, depending on resources and circumstances. It left the number of connections per origin to the user agent. Device capacity, network conditions, protocol and existing limits all matter. A page that proposes a dozen reservations does not gain the right to occupy a dozen tables. The browser decides whether the restaurant can afford the chairs.

That discretion has a practical reason. Early work spends time and resources now in hope of saving a wait later. Preparing a connection to an origin the page never uses can waste effort; preparing too many can compete with the work needed for the page the visitor is looking at. The 2020 text also says outstanding preconnect work must not delay the document's load event. A useful hint gets the browser ready without holding the current page hostage to a speculative future.

The W3C publication history places the first public draft in October 2014 and records the subsequent Working Drafts. The document family changed: the early pairing of preconnect and preload became a set that distinguished name lookup, connection, future-resource fetch and future-document preparation. These were published as drafts, while the enduring idea is easy to grasp. The page knows the neighborhood. The browser decides whether to walk over now. Dinner has yet to be ordered.