Développer des sites qui se chargent rapidement partout peut s'avérer difficile. La multitude de fonctionnalités des appareils et la qualité des réseaux auxquels ils se connectent peuvent donner l'impression d'une tâche insurmontable. Bien que nous puissions exploiter les fonctionnalités du navigateur pour améliorer les performances de chargement, comment savoir de quoi l'appareil de l'utilisateur est capable ou quelle est la qualité de sa connexion réseau ? La solution : les conseils client.
Les indications client sont un ensemble d'en-têtes de requête HTTP activables qui nous permettent d'en savoir plus sur ces aspects de l'appareil de l'utilisateur et du réseau auquel il est connecté. En exploitant ces informations côté serveur, nous pouvons modifier la façon dont nous diffusons le contenu en fonction des conditions de l'appareil et/ou du réseau. Cela peut nous aider à créer des expériences utilisateur plus inclusives.
Tout est une question de négociation de contenu
Les indications du client sont une autre méthode de négociation de contenu, qui consiste à modifier les réponses de contenu en fonction des en-têtes de requête du navigateur.
Un exemple de négociation de contenu implique l'en-tête de requête Accept. Il décrit les types de contenu que le navigateur comprend, que le serveur peut utiliser pour négocier la réponse. Pour les requêtes d'images, le contenu de l'en-tête Accept de Chrome est le suivant :
Accept: image/webp,image/apng,image/*,*/*;q=0.8
Bien que tous les navigateurs soient compatibles avec les formats d'image tels que JPEG, PNG et GIF, l'en-tête Accept indique dans ce cas que le navigateur est également compatible avec WebP et APNG. Grâce à ces informations, nous pouvons négocier les meilleurs types d'images pour chaque navigateur :
<?php
// Check Accept for an "image/webp" substring.
$webp = stristr($_SERVER["HTTP_ACCEPT"], "image/webp") !== false ? true : false;
// Set the image URL based on the browser's WebP support status.
$imageFile = $webp ? "whats-up.webp" : "whats-up.jpg";
?>
<img src="<?php echo($imageFile); ?>" alt="I'm an image!">
Comme Accept, les indications client sont un autre moyen de négocier le contenu, mais dans le contexte des capacités de l'appareil et des conditions du réseau. Grâce aux indications du client, nous pouvons prendre des décisions de performances côté serveur en fonction de l'expérience individuelle d'un utilisateur, par exemple décider si des ressources non critiques doivent être diffusées auprès des utilisateurs dont les conditions réseau sont médiocres. Dans ce guide, nous allons décrire tous les indices disponibles et certaines façons de les utiliser pour rendre la diffusion de contenu plus adaptée aux utilisateurs.
Activation
Contrairement à l'en-tête Accept, les indications du client n'apparaissent pas comme par magie (à l'exception de Save-Data, que nous aborderons plus tard). Afin de limiter au maximum les en-têtes de requête, vous devez choisir les indications client que vous souhaitez recevoir en envoyant un en-tête Accept-CH lorsqu'un utilisateur demande une ressource :
Accept-CH: Viewport-Width, Downlink
La valeur de Accept-CH est une liste d'éléments séparés par une virgule d'indications demandées que le site utilisera pour déterminer les résultats de la requête de ressource suivante. Lorsque le client lit cet en-tête, il reçoit l'instruction suivante : "Ce site souhaite obtenir les indications client Viewport-Width et Downlink." Ne vous préoccupez pas des indications spécifiques elles-mêmes.
Nous y reviendrons dans un instant.
Vous pouvez définir ces en-têtes d'activation dans n'importe quel langage de backend. Par exemple, vous pouvez utiliser la fonction header de PHP.
Vous pouvez même définir ces en-têtes d'activation avec l'attribut http-equiv sur une balise <meta> :
<meta http-equiv="Accept-CH" content="Viewport-Width, Downlink" />
Tous les indices client !
Les indications client décrivent l'une des deux choses suivantes : l'appareil que vos utilisateurs utilisent et le réseau qu'ils utilisent pour accéder à votre site. Passons brièvement en revue toutes les indications disponibles.
Recommandations concernant les appareils
Certains indices client décrivent les caractéristiques de l'appareil de l'utilisateur, généralement celles de l'écran. Certaines d'entre elles peuvent vous aider à choisir la ressource multimédia optimale pour l'écran d'un utilisateur donné, mais elles ne sont pas toutes nécessairement axées sur les contenus multimédias.
Avant d'entrer dans le vif du sujet, il peut être utile de connaître quelques termes clés utilisés pour décrire les écrans et la résolution des contenus multimédias :
Taille intrinsèque : dimensions réelles d'une ressource multimédia. Par exemple, si vous ouvrez une image dans Photoshop, les dimensions affichées dans la boîte de dialogue de taille de l'image décrivent sa taille intrinsèque.
Taille intrinsèque corrigée en fonction de la densité : dimensions d'une ressource multimédia après correction de la densité de pixels. Il s'agit de la taille intrinsèque de l'image divisée par un ratio de pixels de l'appareil. Prenons l'exemple de ce balisage :
<img
src="whats-up-1x.png"
srcset="whats-up-2x.png 2x, whats-up-1x.png 1x"
alt="I'm that image you wanted."
/>
Supposons que la taille intrinsèque de l'image 1x dans ce cas soit de 320 x 240 et que la taille intrinsèque de l'image 2x soit de 640 x 480. Si ce balisage est analysé par un client installé sur un appareil dont le ratio de pixels de l'écran est de 2 (par exemple, un écran Retina), l'image 2x est demandée. La taille intrinsèque corrigée en fonction de la densité de l'image 2x est de 320 x 240, car 640 x 480 divisé par 2 est égal à 320 x 240.
Taille extrinsèque : taille d'une ressource multimédia après l'application du CSS et d'autres facteurs de mise en page (tels que les attributs width et height). Imaginons que vous ayez un élément <img> qui charge une image dont la taille intrinsèque corrigée en fonction de la densité est de 320 x 240, mais qui possède également des propriétés CSS width et height avec des valeurs de 256px et 192px, respectivement. Dans cet exemple, la taille extrinsèque de cet élément <img> devient 256 x 192.
width: 256px; et height: 192px; transforme une image de taille intrinsèque 320 x 240 en une image de taille extrinsèque 256 x 192.Maintenant que nous avons vu un peu de terminologie, examinons la liste des indications du client spécifiques à l'appareil qui sont à votre disposition.
Viewport-Width
Viewport-Width est la largeur de la fenêtre d'affichage de l'utilisateur en pixels CSS :
Viewport-Width: 320
Cet indice peut être utilisé avec d'autres indices spécifiques à l'écran pour proposer différents traitements (par exemple, des recadrages) d'une image optimisés pour des tailles d'écran spécifiques (par exemple, la direction artistique) ou pour omettre les ressources inutiles pour la largeur d'écran actuelle.
DPR
DPR, abréviation de "device pixel ratio" (rapport de pixels de l'appareil), indique le rapport entre les pixels physiques et les pixels CSS de l'écran de l'utilisateur :
DPR: 2
Cette indication est utile pour sélectionner des sources d'images qui correspondent à la densité de pixels d'un écran (comme le font les descripteurs x dans l'attribut srcset).
Largeur
L'indice Width apparaît sur les requêtes de ressources d'image déclenchées par les balises <img> ou <source> à l'aide de l'attribut sizes.
sizes indique au navigateur la taille extrinsèque de la ressource. Width utilise cette taille extrinsèque pour demander une image avec une taille intrinsèque optimale pour la mise en page actuelle.
Par exemple, supposons qu'un utilisateur demande une page avec un écran de 320 pixels CSS de large et un DPR de 2. L'appareil charge un document avec un élément <img> contenant une valeur d'attribut sizes de 85vw (c'est-à-dire 85 % de la largeur de la fenêtre d'affichage pour toutes les tailles d'écran). Si l'indice Width a été activé, le client l'envoie
Width au serveur avec la requête pour le src de <img> :
Width: 544
Dans ce cas, le client indique au serveur qu'une largeur intrinsèque optimale pour l'image demandée serait de 85 % de la largeur de la fenêtre d'affichage (272 pixels) multipliée par le DPR de l'écran (2), ce qui équivaut à 544 pixels.
Cette indication est particulièrement efficace, car elle prend en compte non seulement la largeur de l'écran corrigée en fonction de la densité, mais elle rapproche également cette information essentielle de la taille extrinsèque de l'image dans la mise en page. Cela permet aux serveurs de négocier des réponses d'image optimales pour l'écran et la mise en page.
Content-DPR
Vous savez déjà que les écrans ont un rapport de pixels de l'appareil, mais les ressources ont également leurs propres rapports de pixels. Dans les cas d'utilisation les plus simples de sélection de ressources, les ratios de pixels entre les appareils et les ressources peuvent être identiques. Mais attention… Lorsque les en-têtes DPR et Width sont tous deux utilisés, la taille extrinsèque d'une ressource peut produire des scénarios dans lesquels les deux diffèrent. C'est là que l'indice Content-DPR entre en jeu.
Contrairement aux autres indications du client, Content-DPR n'est pas un en-tête de requête à utiliser par les serveurs, mais plutôt un en-tête de réponse que les serveurs doivent envoyer chaque fois que les indications DPR et Width sont utilisées pour sélectionner une ressource. La valeur de Content-DPR doit être le résultat de cette équation :
Content-DPR = [Taille de la ressource d'image sélectionnée] / ([Width] / [DPR])
Lorsqu'un en-tête de requête Content-DPR est envoyé, le navigateur sait comment redimensionner l'image donnée en fonction du format de pixel de l'appareil et de la mise en page. Sans cela, les images risquent de ne pas s'adapter correctement.
Device-Memory
Techniquement, Device-Memory fait partie de l'API Device Memory et révèle la quantité approximative de mémoire de l'appareil actuel en Gio :
Device-Memory: 2
Un cas d'utilisation possible de cet indice serait de réduire la quantité de code JavaScript envoyée aux navigateurs sur les appareils disposant d'une mémoire limitée, car le code JavaScript est le type de contenu le plus gourmand en ressources que les navigateurs chargent généralement. Vous pouvez également envoyer des images avec un DPR inférieur, car elles utilisent moins de mémoire pour le décodage.
Conseils réseau
L'API Network Information fournit une autre catégorie d'indications client qui décrivent les performances de la connexion réseau de l'utilisateur. À mon avis, ce sont les conseils les plus utiles. Grâce à eux, nous pouvons adapter les expériences aux utilisateurs en modifiant la façon dont nous fournissons les ressources aux clients sur des connexions lentes.
Texte en temps réel
L'indice RTT fournit le temps aller-retour approximatif, en millisecondes, sur la couche d'application. Contrairement au RTT de la couche de transport, l'indice RTT inclut le temps de traitement du serveur.
RTT: 125
Cet indice est utile en raison du rôle que joue la latence dans les performances de chargement.
L'indice RTT nous permet de prendre des décisions en fonction de la réactivité du réseau, ce qui peut accélérer la diffusion d'une expérience complète (par exemple, en omettant certaines requêtes).
Liaison descendante
Bien que la latence soit importante pour les performances de chargement, la bande passante l'est également. L'indice Downlink, exprimé en mégabits par seconde (Mbit/s), révèle la vitesse de téléchargement approximative de la connexion de l'utilisateur :
Downlink: 2.5
En conjonction avec RTT, Downlink peut être utile pour modifier la façon dont le contenu est diffusé auprès des utilisateurs en fonction de la qualité d'une connexion réseau.
ECT
L'indice ECT signifie Effective Connection Type (type de connexion effectif). Sa valeur est l'un des types de connexion d'une liste énumérée, chacun décrivant une connexion dans des plages spécifiées de valeurs RTT et Downlink.
Cet en-tête n'explique pas quel est le type de connexion réel. Par exemple, il n'indique pas si votre passerelle est une antenne-relais ou un point d'accès Wi-Fi. Il analyse plutôt la latence et la bande passante de la connexion actuelle, et détermine le profil réseau auquel elle ressemble le plus. Par exemple, si vous vous connectez via le Wi-Fi à un réseau lent, ECT peut être renseigné avec la valeur 2g, qui est l'approximation la plus proche de la connexion effective :
ECT: 2g
Les valeurs valides pour ECT sont 4g, 3g, 2g et slow-2g. Cette indication peut servir de point de départ pour évaluer la qualité de la connexion, puis être affinée à l'aide des indications RTT et Downlink.
Save-Data
Save-Data n'est pas tant un indice décrivant les conditions du réseau qu'une préférence utilisateur indiquant que les pages doivent envoyer moins de données.
Je préfère classer Save-Data comme un indice réseau, car de nombreuses choses que vous feriez avec sont similaires à d'autres indices réseau. Les utilisateurs peuvent également l'activer dans les environnements à latence élevée ou à faible bande passante. Lorsqu'il est présent, cet indice se présente toujours comme suit :
Save-Data: on
Chez Google, nous avons déjà parlé de ce que vous pouvez faire avec Save-Data.
L'impact sur les performances peut être considérable. C'est un signal par lequel les utilisateurs vous demandent littéralement de leur envoyer moins de messages. Si vous écoutez et agissez sur ce signal, les utilisateurs l'apprécieront.
Vue panoramique
C'est à vous de décider ce que vous faites des indications client. Comme ils offrent de nombreuses informations, vous avez beaucoup d'options. Pour vous donner quelques idées, voyons ce que les indications du client peuvent faire pour Sconnie Timber, une entreprise fictive de bois d'œuvre située dans une zone rurale du Midwest supérieur. Comme c'est souvent le cas dans les zones reculées, les connexions réseau peuvent être fragiles. C'est là qu'une technologie comme les indications client peut vraiment faire la différence pour les utilisateurs.
Images responsives
Tous les cas d'utilisation d'images responsives, à l'exception des plus simples, peuvent devenir complexes. Que se passe-t-il si vous avez plusieurs traitements et variantes des mêmes images pour différentes tailles d'écran et différents formats ? Ce balisage devient très vite très complexe.
Il est facile de se tromper, et d'oublier ou de mal comprendre des concepts importants (comme sizes).
Bien que <picture> et srcset soient indéniablement des outils formidables, leur développement et leur maintenance peuvent prendre du temps pour les cas d'utilisation complexes. Nous pouvons automatiser la génération du balisage, mais cela est également difficile, car les fonctionnalités fournies par <picture> et srcset sont suffisamment complexes pour que leur automatisation soit effectuée de manière à conserver la flexibilité qu'elles offrent.
Les indications du client peuvent simplifier ce processus. La négociation des réponses d'image avec les indices client peut ressembler à ceci :
- Si cela s'applique à votre workflow, sélectionnez d'abord un traitement d'image (c'est-à-dire une image dirigée par un artiste) en cochant l'indice
Viewport-Width. - Sélectionnez une résolution d'image en vérifiant les indications
WidthetDPR, puis en choisissant une source adaptée à la taille de la mise en page de l'image et à la densité de l'écran (comme les descripteursxetwfonctionnent danssrcset). - Sélectionnez le format de fichier le plus optimal compatible avec le navigateur (ce que
Acceptnous aide à faire dans la plupart des navigateurs).
Pour mon client fictif, une entreprise de bois d'œuvre, j'ai développé une routine de sélection d'images responsive naïve en PHP qui utilise les indices client. Cela signifie qu'au lieu d'envoyer ce balisage à tous les utilisateurs :
<picture>
<source
srcset="
company-photo-256w.webp 256w,
company-photo-512w.webp 512w,
company-photo-768w.webp 768w,
company-photo-1024w.webp 1024w,
company-photo-1280w.webp 1280w
"
type="image/webp"
/>
<img
srcset="
company-photo-256w.jpg 256w,
company-photo-512w.jpg 512w,
company-photo-768w.jpg 768w,
company-photo-1024w.jpg 1024w,
company-photo-1280w.jpg 1280w
"
src="company-photo-256w.jpg"
sizes="(min-width: 560px) 251px, 88.43vw"
alt="The Sconnie Timber Staff!"
/>
</picture>
J'ai pu la réduire à la liste suivante en fonction de la compatibilité de chaque navigateur :
<img
src="/image/sizes:true/company-photo.jpg"
sizes="(min-width: 560px) 251px, 88.43vw"
alt="SAY CHEESY PICKLES."
/>
Dans cet exemple, l'URL /image est un script PHP suivi de paramètres réécrits par mod_rewrite. Il utilise un nom de fichier d'image et des paramètres supplémentaires pour aider un script de backend à choisir la meilleure image dans les conditions données.
Je sens que votre première question est : "Mais ne s'agit-il pas simplement de réimplémenter <picture> et srcset sur le backend ?"
D'une certaine manière, oui, mais avec une distinction importante : lorsqu'une application utilise des indications client pour créer des réponses multimédias, la plupart (voire la totalité) du travail est beaucoup plus facile à automatiser, ce qui peut inclure un service (tel qu'un CDN) qui peut le faire en votre nom. En revanche, avec les solutions HTML, un nouveau balisage doit être écrit pour chaque cas d'utilisation. Oui, vous pouvez automatiser la génération de balisage. Toutefois, si votre conception ou vos exigences changent, il est fort probable que vous deviez revoir votre stratégie d'automatisation à l'avenir.
Les indications client permettent de commencer avec une image haute résolution sans perte, qui peut ensuite être redimensionnée de manière dynamique pour être optimale pour n'importe quelle combinaison d'écran et de mise en page. Contrairement à srcset, qui nécessite d'énumérer une liste fixe d'images candidates parmi lesquelles le navigateur peut choisir, cette approche peut être plus flexible. Alors que srcset vous oblige à proposer aux navigateurs un ensemble grossier de variantes (par exemple, 256w, 512w, 768w et 1024w), une solution basée sur les indices client peut diffuser toutes les largeurs, sans une énorme quantité de balisage.
Bien sûr, vous n'avez pas besoin d'écrire vous-même la logique de sélection d'images. Cloudinary utilise les indications du client pour créer des réponses d'image lorsque vous utilisez le paramètre w_auto. Il a constaté que les utilisateurs médians téléchargeaient 42 % d'octets en moins lorsqu'ils utilisaient des navigateurs compatibles avec les indications du client.
Mais attention ! Les modifications apportées à la version classique de Chrome 67 ont supprimé la compatibilité avec les indications client interorigines. Heureusement, ces restrictions n'affectent pas les versions mobiles de Chrome et seront complètement levées pour toutes les plates-formes une fois que le travail sur la Feature Policy sera terminé.
Aider les utilisateurs sur des réseaux lents
Les performances adaptatives consistent à ajuster la façon dont nous fournissons les ressources en fonction des informations que les indications client mettent à notre disposition, en particulier les informations concernant l'état actuel de la connexion réseau de l'utilisateur.
En ce qui concerne le site de Sconnie Timber, nous prenons des mesures pour alléger la charge lorsque les réseaux sont lents, en examinant les en-têtes Save-Data, ECT, RTT et Downlink dans notre code de backend. Une fois cette opération terminée, nous générons un score de qualité du réseau que nous pouvons utiliser pour déterminer si nous devons intervenir pour améliorer l'expérience utilisateur. Ce score de réseau est compris entre 0 et 1, où 0 correspond à la pire qualité de réseau possible et 1 à la meilleure.
Nous vérifions d'abord si Save-Data est présent. Si tel est le cas, le score est défini sur 0, car nous supposons que l'utilisateur souhaite que nous fassions tout le nécessaire pour rendre l'expérience plus légère et plus rapide.
Toutefois, si Save-Data est absent, nous passons à l'étape suivante et évaluons les valeurs des indices ECT, RTT et Downlink pour calculer un score qui décrit la qualité de la connexion réseau. Le code source de génération du score du réseau est disponible sur GitHub. En conclusion, si nous utilisons les indications liées au réseau d'une certaine manière, nous pouvons améliorer l'expérience des utilisateurs sur des réseaux lents.
Lorsque les sites s'adaptent aux informations fournies par les indications client, nous n'avons pas besoin d'adopter une approche du type "tout ou rien". Nous pouvons décider intelligemment des ressources à envoyer. Nous pouvons modifier notre logique de sélection d'images responsives pour envoyer des images de qualité inférieure pour un affichage donné afin d'accélérer le chargement lorsque la qualité du réseau est médiocre.
Dans cet exemple, nous pouvons voir l'impact des indications du client sur l'amélioration des performances des sites sur les réseaux plus lents. Vous trouverez ci-dessous une cascade WebPagetest d'un site sur un réseau lent qui ne s'adapte pas aux indices client :
Voici maintenant une cascade pour le même site sur la même connexion lente, mais cette fois, le site utilise des indications du client pour éliminer les ressources de page non critiques :
Les indications du client ont permis de réduire le temps de chargement de la page de plus de 45 secondes à moins d'un dixième de ce temps. Les avantages des indications du client dans ce scénario sont indéniables et peuvent être d'une grande utilité pour les utilisateurs qui recherchent des informations critiques sur des réseaux lents.
De plus, il est possible d'utiliser des indications client sans interrompre l'expérience pour les navigateurs qui ne les acceptent pas. Par exemple, si nous voulons ajuster la diffusion des ressources en utilisant la valeur de l'indice ECT tout en offrant une expérience complète aux navigateurs non compatibles, nous pouvons définir une valeur par défaut comme suit :
// Set the ECT value to "4g" by default.
$ect = isset($_SERVER["HTTP_ECT"]) ? $_SERVER["HTTP_ECT"] : "4g";
Ici, "4g" représente la connexion réseau de la plus haute qualité décrite par l'en-tête ECT. Si nous initialisons $ect sur "4g", les navigateurs qui ne sont pas compatibles avec les indications du client ne seront pas affectés. Activer FTW !
Attention aux caches !
Chaque fois que vous modifiez une réponse en fonction d'un en-tête HTTP, vous devez savoir comment les caches géreront les futures récupérations de cette ressource. L'en-tête Vary est indispensable ici, car il associe les entrées de cache à la valeur des en-têtes de requête qui lui sont fournis. En d'autres termes, si vous modifiez une réponse en fonction d'un en-tête de requête HTTP donné, vous devez presque toujours inclure cet en-tête de requête dans Vary, comme suit :
Vary: DPR, Width
Il existe toutefois une mise en garde importante : vous ne devez jamais Vary des réponses pouvant être mises en cache sur un en-tête qui change fréquemment (comme Cookie), car ces ressources deviennent alors impossibles à mettre en cache. Sachant cela, vous voudrez peut-être éviter d'utiliser Vary sur les en-têtes d'indications client tels que RTT ou Downlink, car il s'agit de facteurs de connexion qui peuvent changer assez souvent. Si vous souhaitez modifier les réponses sur ces en-têtes, envisagez de ne saisir que l'en-tête ECT, ce qui minimisera les échecs de cache.
Bien sûr, cela ne s'applique que si vous mettez en cache une réponse.
Par exemple, vous ne mettrez pas en cache les éléments HTML si leur contenu est dynamique, car cela peut nuire à l'expérience utilisateur lors des visites répétées. Dans ce cas, n'hésitez pas à modifier ces réponses en fonction de ce que vous jugez nécessaire, sans vous soucier de Vary.
Hints client dans les service workers
La négociation de contenu n'est plus réservée aux serveurs. Comme les service workers agissent en tant que proxys entre les clients et les serveurs, vous pouvez contrôler la manière dont les ressources sont diffusées via JavaScript. Cela inclut les hints client. Dans l'événement fetch du service worker, vous pouvez utiliser la méthode request.headers.get de l'objet event pour lire les en-têtes de requête d'une ressource, comme suit :
self.addEventListener('fetch', (event) => {
let dpr = event.request.headers.get('DPR');
let viewportWidth = event.request.headers.get('Viewport-Width');
let width = event.request.headers.get('Width');
event.respondWith(
(async function () {
// Do what you will with these hints!
})(),
);
});
Tout en-tête d'indications du client que vous activez peut être lu de cette manière. Toutefois, ce n'est pas le seul moyen d'obtenir certaines de ces informations. Les indications spécifiques au réseau peuvent être lues dans les propriétés JavaScript équivalentes de l'objet navigator :
| Hint client | Équivalent JS |
|---|---|
| ECT | `navigator.connection.effectiveType` |
| `RTT` | `navigator.connection.rtt` |
| `Save-Data` | `navigator.connection.saveData` |
| `Downlink` | `navigator.connection.downlink` |
| `Device-Memory` | `navigator.deviceMemory` |
Comme ces API ne sont pas disponibles partout, vous devez vérifier les fonctionnalités à l'aide de l'opérateur in :
if ('connection' in navigator) {
// Work with netinfo API properties in JavaScript!
}
À partir de là, vous pouvez utiliser une logique semblable à celle que vous utiliseriez sur le serveur, sauf que vous n'avez pas besoin d'un serveur pour négocier le contenu avec les indices client. Les service workers ont à eux seuls le pouvoir de rendre les expériences plus rapides et plus résilientes, car ils peuvent diffuser du contenu lorsque l'utilisateur est hors connexion.
Conclusion
Grâce aux indications du client, nous pouvons accélérer les expériences des utilisateurs de manière entièrement progressive. Nous pouvons diffuser des contenus multimédias en fonction des capacités de l'appareil de l'utilisateur, ce qui facilite la diffusion d'images responsives par rapport à l'utilisation de <picture> et srcset, en particulier pour les cas d'utilisation complexes. Cela nous permet non seulement de réduire le temps et les efforts consacrés au développement, mais aussi d'optimiser les ressources (en particulier les images) de manière à cibler les écrans des utilisateurs plus précisément que ne le permettent
Plus important encore, nous pouvons détecter les mauvaises connexions réseau et combler les lacunes pour les utilisateurs en modifiant ce que nous envoyons et la manière dont nous l'envoyons. Cela peut grandement faciliter l'accès aux sites pour les utilisateurs sur des réseaux instables. En les combinant avec des service workers, nous pouvons créer des sites incroyablement rapides et disponibles hors connexion.
Bien que les indications client ne soient disponibles que dans Chrome et les navigateurs basés sur Chromium, il est possible de les utiliser de manière à ne pas encombrer les navigateurs qui ne les prennent pas en charge. Envisagez d'utiliser les indications du client pour créer des expériences véritablement inclusives et adaptables, qui tiennent compte des capacités de l'appareil de chaque utilisateur et des réseaux auxquels il se connecte. Nous espérons que d'autres fournisseurs de navigateurs en verront l'intérêt et manifesteront leur intention de les implémenter.
Ressources
- Images responsives automatiques avec les indications du client
- Client Hints and Responsive Images—What Changed in Chrome 67
- Prenez un (client) hint ! (Slides)
- Fournir des applications rapides et légères avec
Save-Data
Merci à Ilya Grigorik, Eric Portis, Jeff Posnick, Yoav Weiss et Estelle Weyl pour leurs précieux commentaires et modifications sur cet article.