Client Hints That Describe the Network and Display

Client hints are usually discussed as a replacement for the user agent string, but the family is broader. Several hints describe the display and connection rather than the browser.

Display hints support asset selection

Viewport width and device pixel ratio let a server select an image size before sending anything, rather than delivering a large asset the client immediately scales down.

The saving is real on constrained connections. Sending the right resolution once beats sending a larger file and discarding most of its detail.

Markup-based responsive images solve the same problem client-side. The hints exist for cases where the decision must happen at the server or an intermediate cache.

Network hints describe conditions, not capability

Hints describing connection quality report an estimate of current conditions rather than the underlying technology. Conditions change; the technology label does not describe them well.

This distinction matters because a nominally fast connection can perform poorly and a slow one can perform adequately. Reporting an estimate is more honest than reporting a category.

Estimates are also noisy. Treating them as a hint that shifts a decision at the margin is appropriate; treating them as a measurement is not.

Preference hints carry user choices

Some hints convey stated preferences such as reduced data usage or a colour scheme. These are user choices rather than device facts.

Because they are choices, the correct response is to honour them rather than to weigh them. A stated preference for less data is not a signal to be optimised against.

Serving a lighter page in response is straightforward and visible to the user. This is one of the few hints whose effect a user can perceive directly.

The same request mechanism governs all of them

These hints use the same request header, the same origin scoping and the same delegation rules as the browser identity hints. One mechanism covers the family.

That consistency is a practical benefit. A team that has implemented one hint correctly has implemented the machinery for all of them.

It also means the same failure modes apply, including the first-request gap and the absence of hints in embedded third-party contexts.

Deciding whether to use them at all

Each hint should be judged against what the site would do differently with it. A hint requested without a corresponding behaviour is data collected for no reason.

Display and network hints usually pass that test cleanly, because the resulting behaviour is a concrete change in what gets sent.

Identity hints pass it less often. Much of what sites historically inferred from browser identity is better answered by testing whether a capability exists.