How Hint Support Is Detected Without Guessing

Code that uses client hints has to handle clients that do not send them. Deciding which clients those are by parsing the user agent reintroduces the problem hints were meant to solve.

The presence of a hint is its own signal

If a request carries hint headers, the client supports them. If it does not, the client either lacks support or has been configured or delegated out of sending them.

Both cases route to the same fallback, so distinguishing them is unnecessary. Absence is a sufficient answer for the decision the code has to make.

This keeps the logic to one branch. Any attempt to explain the absence adds complexity without changing the outcome.

Inferring support from the string is circular

Deciding which browsers support hints by parsing the user agent means maintaining a version table and getting it wrong for every client not in it.

It also produces false positives. A supporting browser may not send a hint because of policy, delegation or transport, and the table says it should have.

Trusting the table over the observed request is the error. The request is the ground truth for this particular question.

Script-side detection is a capability check

In script, the presence of the relevant object and method answers the question directly. If the interface exists, the browser implements it.

The method's resolution still may not return every requested field, so a support check and a data check are separate steps.

Conflating them produces code that assumes a supporting browser will answer fully. That assumption is not part of the contract.

Fallback should be capability-based, not identity-based

The natural fallback for missing hints is testing what the runtime can actually do, which usually answers the underlying question better than any identity would have.

Falling back to user agent parsing is defensible only where the decision must happen server-side before any script runs. Even then it should be coarse.

Where the fallback path is exercised by a large share of traffic, it deserves the same attention as the primary path rather than being treated as an edge case.

Instrumenting the two paths separately

Logging which path served each request shows how much traffic actually receives hints. That proportion is frequently lower than teams expect.

The gap comes from first visits, cleared site data, embedded contexts and non-browser clients. Each is ordinary rather than exceptional.

Measuring it converts an assumption into a number, which is usually enough to change how much effort the fallback path deserves.