Need help with http-client-hints?
Click the “chat” button below for chat support from the developer who created it, or find similar developers for support.

About the developer

igrigorik
402 Stars 20 Forks 181 Commits 1 Opened issues

Services available

!
?

Need anything else?

Contributors list

Development of this specification has moved to the HTTPWG repository. For latest drafts and issue discussions, head to:

  • https://github.com/httpwg/http-extensions#client-hints
  • https://httpwg.github.io/http-extensions/client-hints.html

HTTP Client Hints Explainer

This specification defines a set of HTTP request header fields, colloquially known as Client Hints, that are intended to be used as input to proactive content negotiation; just as the

Accept
header allows clients to indicate what formats they prefer, Client Hints allow clients to indicate a list of device and agent specific preferences.

Available hints

Current list includes

DPR
(device pixel ratio),
Width
(resource width),
Viewport-Width
(layout viewport width), and
Downlink
(maximum downlink speed) request headers, and
Content-DPR
response header that is used to confirm the DPR of selected image resources - see full definitions in latest spec.

Note: have a proposal for another hint? Open an issue, document your use case.

Opt-in hint delivery

To reduce request overhead the hints are sent based on opt-in basis: the server advertises supported hints, the user agent sends the appropriate hint request headers for subsequent requests - see Advertising Support for Client Hints.

Note that this means that the user agent will not send hints on the very first request. However, if the site provides correct opt-in information in the response, hints will be delivered by all subsequent requests. Also, the user agent may remember site opt-in across browsing sessions, enabling hint delivery of all subsequent requests.

Use cases

Responsive Design + Server Side Components (RESS)

The application may want to deliver alternate set of optimized resources based on advertised hints. For example, it may use the device pixel ratio (

DPR
), or the layout viewport width (
Viewport-Width
) to respond with optimized HTML markup, CSS, or script resources - see Responsive Design + Server Side Components (RESS).

Note: Applications that use this approach must also serve appropriate

Vary
and
Cache-Control
response headers to ensure correct delivery of optimized assets.

element

Delivering DPR-aware images

DPR
hint automates device-pixel-ratio-based selection and enables delivery of optimal image variant without any changes in markup. For example, given the following HTML markup:
I'm a DPR-aware image!

The client and server can negotiate the appropriate resolution of

img.jpg
via HTTP negotiation:
GET /img.jpg HTTP/1.1
User-Agent: Awesome Browser
Accept: image/webp, image/jpg
DPR: 2.0
HTTP/1.1 200 OK
Server: Awesome Server
Content-Type: image/jpg
Content-Length: 124523
Vary: DPR
Content-DPR: 2.0

(image data)

In the above example, the user agent advertises its device pixel ratio via

DPR
request header on the image request. Given this information, the server is able to select and respond with the optimal resource variant for the client. For full details refer to the latest spec.

Note: when server side DPR-selection is used the server must confirm the DPR of the selected resource via

Content-DPR
response header to allow the user agent to compute the correct intrinsic size of the image.

Delivering DPR and resource width aware images

If the image resource width is known at request time, the user agent can communicate it to the server to enable selection of an optimized resource. For example, given the following HTML markup:

I'm a DPR and width aware image!

The client and server can negotiate an optimized asset based on

DPR
and
Width
request hints:
GET /img.jpg HTTP/1.1
User-Agent: Awesome Browser
Accept: image/webp, image/jpg
DPR: 2.0
Width: 320
HTTP/1.1 200 OK
Server: Awesome Server
Content-Type: image/jpg
Content-Length: 124523
Vary: Width
Content-DPR: 2.0

(image data)

In the above example, the user agent advertises its device pixel ratio and image resource width via respective

DPR
and
Width
headers on the image request. Given this information, the server is able to select and respond with the optimal resource variant for the client:
  • The server can scale the asset to requested width, or return the closest available match to help reduce number of transfered bytes.
  • The server can factor in the device pixel ratio of the device in its selection algorithm.

Note that the width of the image may not be available at request time, in which case the user agent would omit the

Width
hint. Also, the exact logic as to which asset is selected is deferred to the server, which can optimize its selection based on available resources, cache hit rates, and other criteria.

element

Client Hints can be used alongside picture element to automate resolution switching, simplify art-direction, and automate delivery of variable-sized images.

Device-pixel-ratio-based selection

DPR header automates device-pixel-ratio-based selection by eliminating the need to write

x
descriptors for
img
and
picture
elements:

  
  A rad wolf.



A rad wolf.


A rad wolf.





  
  
  The president giving an award.




  
  
  The president giving an award.

Note that the second example with art direction-based selection illustrates that hints do not eliminate the need for the

picture
element. Rather, Client Hints is able to simplify and automate certain parts of the negotiation, allowing the developer to focus on art direction, which by definition requires developer/designer input.
Device-pixel-ratio and viewport-based selection

The combination of

DPR
and
Width
hints also simplifies delivery of variable sized images when viewport-based selection is used. The developer specifies the resource width of the image in
vw
units (which are relative to viewport width) via
sizes
attribute and the user agent handles the rest:
The rad wolf


The rad wolf
  • Device pixel ratio is communicated via the
    DPR
    request header
  • The
    vw
    size is converted to physical
    px
    size based on client's layout viewport size and the resulting value is communicated via the
    Width
    request header
  • The server computes the optimal image variant based on communicated
    DPR
    and
    Width
    values and responds with the optimal image variant.

HTTP negotiation flow for the example above:

> GET /wolf.jpg HTTP/1.1
> DPR: 2.0
> Width: 800

< 200 OK < Content-DPR: 2.0 < Vary: Width < ...

In situations where multiple layout breakpoints impact the image's dimensions the workflow is similar to that of the previous example:

Kettlebell Swing


Kettlebell Swing

The combination of the

DPR
and
Width
hints allows the server to deliver 'pixel perfect' images that match the device resolution and exact display size. However, the server is not required to do so: it can round or bin the advertised values based on own logic and serve the closest matching resource - just as
srcset
picks the nearest resource based on the provided parameters in the markup.
Resource selection

When request hints are used the resource selection algorithm logic is shared between the user agent and the server: the user agent may apply own selection rules based on specified markup and defer other decisions to the server by communicating the appropriate

DPR
and
Width
values within the image request. With that, a few considerations to keep in mind:
  • The device pixel ratio and the resource width may change after the initial image request was sent to the server - e.g. layout change, desktop zoom, etc. When this occurs, and if resource selection is done via
    sizes
    or
    srcset
    attributes, the decision to initiate a new request is deferred to the user agent: it may send a new request advertising new hint values, or it may choose to reuse and rescale the existing asset. Note that this is the default behavior of the user agent - i.e. the user agent is not required to initiate a new request and use of hints does not modify this behavior.
  • For cases where an environment change (layout, zoom, etc.) must trigger a new asset download, you should use art-direction with
    source
    and appropriate media queries.

Use of Client Hints does not incur additional or unnecessary requests. However, as an extra optimization, the server should advertise the Key caching header to improve cache efficiency.

Maximum downlink speed

The application may want to deliver an alternate set of resources (e.g. - alternate image asset, stylesheet, HTML document, media stream, and so on) based on the maximum downlink (

Downlink
) speed of the client, as defined by the
downlinkMax
attribute
in the W3C Network Information API.

Hands-on example

A hands-on example courtesy of resrc.it:

# Request 100 CSS px wide asset with DPR of 1.0
$> curl -s http://app.resrc.it/http://www.resrc.it/img/demo/preferred.jpg \
  -o /dev/null -w "Image bytes: %{size_download}\n" \
  -H "DPR: 1.0" -H "Width: 100"
Image bytes: 9998

Request 100 CSS px wide asset with DPR of 1.5

$> curl -s http://app.resrc.it/http://www.resrc.it/img/demo/preferred.jpg
-o /dev/null -w "Image bytes: %{size_download}\n"
-H "DPR: 1.5" -H "Width: 150" Image bytes: 17667

Request 200 CSS px wide asset with DPR of 1.0

$> curl -s http://app.resrc.it/http://www.resrc.it/img/demo/preferred.jpg
-o /dev/null -w "Image bytes: %{size_download}\n"
-H "DPR: 1.0" -H "Width: 200" Image bytes: 28535

ReSRC.it servers automate the delivery of optimal image assets based on advertised

DPR
and
Width
hint values and append the correct caching header (
Vary: DPR, Width
), which allows the asset to be cached on the client and by any Vary-capable intermediaries.

Implementation status

Feedback

Please feel free to open a new issue, or send a pull request!

We use cookies. If you continue to browse the site, you agree to the use of cookies. For more information on our use of cookies please see our Privacy Policy.